From 98e758d91f608e3d2a6619306a2995909946d27b Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 29 Jul 2026 17:37:17 -0400 Subject: [PATCH 01/28] Create SSH-key-management.mdx --- .../organizations/SSH-key-management.mdx | 201 ++++++++++++++++++ 1 file changed, 201 insertions(+) create mode 100644 accounts-billing/organizations/SSH-key-management.mdx diff --git a/accounts-billing/organizations/SSH-key-management.mdx b/accounts-billing/organizations/SSH-key-management.mdx new file mode 100644 index 000000000..1a91bb287 --- /dev/null +++ b/accounts-billing/organizations/SSH-key-management.mdx @@ -0,0 +1,201 @@ +--- +title: "SSH key management" +sidebarTitle: "SSH key management" +description: "Centrally manage SSH public keys for your organization so members can securely connect to Pods." +--- + +Organization-level SSH key management lets org admins store and manage SSH public keys in one place. When a member launches a Pod, org-managed keys are automatically injected into it — no per-member SSH setup required. + +This is useful for teams that need consistent, auditable SSH access across all Pods, and makes it easy to revoke access org-wide when a member leaves. + +--- + +## Roles and permissions + +SSH key management is controlled by org roles. + + + +| Action | Owner/Admin | Member | Billing | Read-only | +|---|---|---|---|---| +| Add an org SSH key | ✅ | ❌ | ❌ | ❌ | +| Delete an org SSH key | ✅ | ❌ | ❌ | ❌ | +| Rename/manage org keys | ✅ | ❌ | ❌ | ❌ | +| Use org keys to connect to Pods | ✅ | ✅ | ❌ | ❌ | + + +Members can still add personal SSH keys to their own account in addition to org-managed keys. See [Personal vs. org keys](#personal-vs-org-keys) for how these interact. + + +--- + +## Adding an SSH key + +### Step 1: Generate a key pair + +If you don't already have an SSH key pair, generate one on your local machine. Runpod only stores the **public key** — never paste your private key anywhere. + + + + ```bash + ssh-keygen -t ed25519 -C "your-name@yourorg.com" + ``` + + When prompted, accept the default file location (`~/.ssh/id_ed25519`) or specify a custom path. To view your public key: + + ```bash + cat ~/.ssh/id_ed25519.pub + ``` + + + ```powershell + ssh-keygen -t ed25519 -C "your-name@yourorg.com" + ``` + + When prompted, accept the default file location. To view your public key: + + ```powershell + Get-Content "$env:USERPROFILE\.ssh\id_ed25519.pub" + ``` + + If `ssh-keygen` is not available, install [OpenSSH for Windows](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse) or use [PuTTYgen](https://www.puttygen.com/). + + + +Your public key will look like: + +``` +ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your-name@yourorg.com +``` + +### Step 2: Add the public key to your org + + + +1. Open the [Runpod console](https://console.runpod.io) and navigate to **Settings → Organization → SSH Keys**. +2. Click **Add SSH key**. +3. Paste your public key into the field. +4. Give the key a name (for example, `alice-macbook` or `ci-deploy-key`) so it's easy to identify later. +5. Click **Save**. + +The key is now available to all Pods launched by members of your org. + +--- + +## Managing keys + +To view, rename, or delete org SSH keys: + + + +1. Navigate to **Settings → Organization → SSH Keys**. +2. Find the key you want to manage. +3. To rename it, click the key name and edit it inline. +4. To delete it, click the three-dot menu next to the key and select **Delete**. + + +Deleting an org SSH key immediately revokes access for all org members using that key. Members connected to a running Pod via that key will be disconnected. New Pods will not have the key injected. + + + + +--- + +## Key scope and membership + +**New Pods** launched after a key is added automatically have all current org SSH keys injected at startup. + +**Existing running Pods** do not receive newly added keys unless they are restarted. + + + +### Personal vs. org keys + +Members can maintain personal SSH keys in their individual account settings in addition to org keys. Both sets of keys are injected into Pods the member launches. Either key can be used to connect. + +If a member is removed from the org, their org key access is revoked, but their personal keys are unaffected. + +--- + +## Connecting to a Pod + +Once an org SSH key is set up, any member whose private key matches an org public key can connect to a Pod. + +### Find the connection details + +1. Open the [Pods page](https://console.runpod.io/pods) and expand the Pod you want to connect to. +2. Click **Connect** to view the SSH connection string. + +### Basic SSH + +```bash +ssh root@ -p -i ~/.ssh/id_ed25519 +``` + +Replace `` and `` with the values shown in the console. + +### SSH over exposed TCP + +If the Pod exposes SSH over a TCP proxy (common for Secure Cloud Pods): + +```bash +ssh root@ -p -i ~/.ssh/id_ed25519 +``` + +The proxy host and port are shown in the **Connect** dialog in the console. + + +To avoid specifying the identity file every time, add an entry to your `~/.ssh/config`: + +``` +Host runpod-mypod + HostName + Port + User root + IdentityFile ~/.ssh/id_ed25519 +``` + +Then connect with: `ssh runpod-mypod` + + +--- + +## Troubleshooting + +**Permission denied (publickey)** + +- Confirm that the private key on your machine matches a public key stored in org settings. +- Verify the key was added before the Pod was launched. Org keys are only injected at Pod startup — restart the Pod if you added the key after it was created. +- Check that you're using the correct private key file with `-i ~/.ssh/id_ed25519`. + +**Connected to wrong Pod / unexpected behavior** + +- Double-check the IP and port from the console. These change each time a Pod is restarted. + +**Key not propagated to Pod** + +- Org SSH keys are injected at Pod creation time. If you added the key to org settings after the Pod launched, you must restart the Pod for the key to take effect. + +**Member cannot connect after joining the org** + +- The member needs to provide the private key for one of the org's public keys. Verify they have the corresponding private key for a key stored in org settings. + +**Access not revoked after removing a member** + +- Removing a member from the org revokes their org key access. However, if the member had a personal SSH key added to a Pod before joining the org, that key remains on the Pod. Audit Pod-level keys if you need to ensure full revocation. + + + +--- + +## Security notes + +**Only store public keys.** Never paste a private key into Runpod. Your private key should remain only on the machine you use to connect. + +**Use strong key types.** Ed25519 (`-t ed25519`) is recommended. RSA keys should be at least 4096 bits (`-t rsa -b 4096`). Avoid DSA and ECDSA with short curves. + +**Rotate keys regularly.** If a key may be compromised, delete it from org settings immediately and generate a new key pair. Affected members will need to add their new public key. + +**Offboarding members.** When a member leaves the org, remove their key from org settings to revoke SSH access. If they shared a key with others, replace it with a fresh key pair distributed only to current members. + +**Audit keys periodically.** Review your org's SSH keys in **Settings → Organization → SSH Keys** and remove any keys that are no longer in active use. From 01398070fd5aa4cdef3503e9d91f88d3b9cb206e Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 29 Jul 2026 17:38:26 -0400 Subject: [PATCH 02/28] Create overview --- accounts-billing/organizations/overview | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 accounts-billing/organizations/overview diff --git a/accounts-billing/organizations/overview b/accounts-billing/organizations/overview new file mode 100644 index 000000000..12ad2b447 --- /dev/null +++ b/accounts-billing/organizations/overview @@ -0,0 +1,21 @@ +--- +title: "Organizations" +sidebarTitle: "Overview" +description: "Manage teams, access, and resources across your Runpod organization." +--- + +Organizations let you collaborate with your team on Runpod. Members share access to resources, and admins control who can do what through roles and permissions. + +## What you can manage + +**Roles and permissions** — assign roles to org members to control access to pods, endpoints, billing, and org settings. See [Roles and permissions](/organizations/roles-and-permissions). + +**SSH key management** — store SSH public keys at the org level so all members can securely connect to Pods without individual key setup. See [SSH key management](/organizations/ssh-key-management). + +**Resource tagging** — create and apply key/value tags to Pods, Endpoints, Network Volumes, and Clusters to organize resources by team, project, or environment. See [Resource tagging](/organizations/resource-tagging). + +## Managing your organization + +To manage your organization's members and settings, navigate to **Settings → Organization** in the [Runpod console](https://console.runpod.io). + + From d7d1572c470f854e1ae65170619884a5aef9453a Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Fri, 31 Jul 2026 10:22:52 -0400 Subject: [PATCH 03/28] Create resource-tagging.mdx --- .../organizations/resource-tagging.mdx | 77 +++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 accounts-billing/organizations/resource-tagging.mdx diff --git a/accounts-billing/organizations/resource-tagging.mdx b/accounts-billing/organizations/resource-tagging.mdx new file mode 100644 index 000000000..205fac50c --- /dev/null +++ b/accounts-billing/organizations/resource-tagging.mdx @@ -0,0 +1,77 @@ +--- +title: "Resource tags" +description: "Organize, filter, and track usage of Runpod resources across your organization with tags." +tag: "NEW" +--- + +Resource tags are key-value labels you create and apply to your Runpod resources to organize, filter, and track usage across your organization. By tagging resources, you can group them in ways that reflect how your teams, projects, and environments are structured. + +A tag key can be any string except one that begins with the reserved `runpod:` prefix. The tag value is optional and can be left blank. + +Tags are shared across your organization rather than defined per user. Once a tag exists, anyone working in your organization can apply it to supported resources, so the same set of labels stays consistent no matter who created a given resource. + +## Supported resources + +You can apply resource tags to the following resource types: + +| Resource type | Description | +|--------------|-------------|Expand commentComment on line R18 +| Pods | Tag individual Pods to organize compute resources. | +| Serverless endpoints | Tag endpoints to group related Serverless workloads. | +| Network volumes | Tag network volumes to track persistent storage. | +| Instant Clusters | Tag Instant Clusters to organize cluster workloads. | + + +Resource tags and cost centers serve different purposes. Tags help you organize and filter resources, while [cost centers](/accounts-billing/cost-centers) track and attribute billing across your organization. You can use both together. + + +## Why use resource tags + +Tags give you a flexible way to categorize resources so you can find and understand them later. Common uses include: + +- Tracking usage for a specific team, project, or initiative. +- Separating environments, such as production versus staging. +- Organizing resources by team or project. +- Quickly filtering resources to find what you need. + +## Create a tag + +To create a tag, open the resource tags management area in the Runpod console, give it a name, and save it. The new tag then becomes available across your organization for anyone to apply. + + +Because tags are shared across your organization, a tag you create is immediately available for anyone in your organization to apply. Consider agreeing on your tags as a team so everyone uses the same set. + + +## Attach a tag to a resource + +You can apply a tag when you create a supported resource, or add one later from the resource's management view. Attaching an existing tag associates that resource with the tag without changing any other resources. + +## Filter resources by tag + +You can filter or search a resource list by tag to see every resource that shares that tag across your organization. This makes it easy to review all the resources associated with a given team, project, or environment in one place. + +## Update a tag + +You can update a tag to change its name (key) and any associated value. Because tags are shared across your organization, updating a tag changes it for every resource that carries it. + +## Detach a tag from a resource + +You can remove a tag from a single resource without deleting the tag itself. Detaching a tag affects only that resource; the tag remains available and stays applied to any other resources that use it. + +## Delete a tag + + +Deleting a tag removes it entirely from your organization, including from every resource it is applied to. This affects all resources carrying the tag, not just one. + + +## Best practices + +A few habits help keep your tags useful and consistent as your organization grows. + +**Establish consistent naming conventions.** Agree on a naming scheme that reflects your teams, projects, and environments before you create tags. Predictable names make tags easier to apply correctly and to filter on later. + +**Tag resources at creation time.** Apply the appropriate tags when you create a resource rather than after the fact. This keeps your resources organized from the start and reduces cleanup work later. + +**Use tags to separate environments.** Apply distinct tags to production, staging, and other environments so you can quickly distinguish them and avoid acting on the wrong resources. + +**Periodically review and prune unused tags.** Revisit your tags from time to time and remove any that are no longer in use. Keeping the tag list current makes it easier for everyone in your organization to find and apply the right tags. From 51f8484b4b5fb3bc42d885e4d529d04b01bfd80f Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Fri, 31 Jul 2026 10:27:15 -0400 Subject: [PATCH 04/28] Create roles-and-permissions.mdx --- .../organizations/roles-and-permissions.mdx | 107 ++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100644 accounts-billing/organizations/roles-and-permissions.mdx diff --git a/accounts-billing/organizations/roles-and-permissions.mdx b/accounts-billing/organizations/roles-and-permissions.mdx new file mode 100644 index 000000000..d0030f447 --- /dev/null +++ b/accounts-billing/organizations/roles-and-permissions.mdx @@ -0,0 +1,107 @@ +--- +title: "Roles and permissions" +sidebarTitle: "Roles and permissions" +description: "Understand Runpod's built-in team roles and use them to control what team members can do with Pods, Serverless endpoints, network volumes, and billing." +--- + +Runpod team accounts use built-in roles to control what each member can access and do. Assigning roles lets an admin delegate work without granting full account control. This page is for admins who manage a team account. To create or convert a team and invite members, see [Manage accounts](/accounts-billing/manage-accounts). If you received an invitation and want to join, see [Join a team](/accounts-billing/manage-accounts#join-a-team). + +## Why use roles + +Roles let you apply least privilege by granting each member the minimum role they need for their work. Use the Billing role to separate billing access from technical operations, so finance staff can manage payment methods and invoices without touching compute resources. Use the Dev role to let developers create and manage compute without exposing billing or account settings. Reserve the Admin role for trusted leads who need full control over members, settings, billing, and all compute. + +## Available roles + +### Basic role + +The Basic role provides essential access for users who need to work with existing resources without management capabilities. It allows users to access the team account and connect to already-deployed resources such as [Pods](/pods/overview), [Serverless endpoints](/serverless/overview), and [Instant Clusters](/instant-clusters). Users with this role cannot view billing information, start or stop Pods, or create new resources. + +### Billing role + +The Billing role focuses exclusively on financial management. Users with this role can access billing information, manage payment methods, and view invoices, but they cannot access compute resources. This makes the role ideal for finance staff who need billing access without operational permissions. + +### Dev role + +The Dev role extends the Basic permissions with additional capabilities for active development work. It includes all Basic permissions plus the ability to create, start, and stop Pods and manage [network volumes](/storage/network-volumes). Instant Cluster management (creating, deleting, starting, and stopping Instant Clusters) is reserved for the Admin role. Users with this role remain restricted from billing information and account settings. + +### Admin role + +The Admin role provides full control over the account. Administrators can manage team members, configure account settings, handle billing, and control all compute resources. Reserve this role for trusted leads who need full account access. + +## Permissions matrix + +The following matrix shows which permissions each role grants: + +| Permission | Basic | Billing | Dev | Admin | +|------------|-------|---------|-----|-------| +| Access team account | ✅ | ✅ | ✅ | ✅ | +| Connect to existing Pods | ✅ | ❌ | ✅ | ✅ | +| Create/delete/start/stop Pods | ❌ | ❌ | ✅ | ✅ | +| Create/delete Serverless endpoints | ❌ | ❌ | ✅ | ✅ | +| Send requests to Serverless endpoints | ✅ | ❌ | ✅ | ✅ | +| Connect to existing Instant Clusters | ✅ | ❌ | ✅ | ✅ | +| Create/delete/start/stop Instant Clusters | ❌ | ❌ | ❌ | ✅ | +| Create/update/delete network volumes | ❌ | ❌ | ✅ | ✅ | +| View billing information | ❌ | ✅ | ❌ | ✅ | +| Manage payment methods | ❌ | ✅ | ❌ | ✅ | +| Invite team members | ❌ | ❌ | ❌ | ✅ | +| Manage team permissions | ❌ | ❌ | ❌ | ✅ | +| Modify team account settings | ❌ | ❌ | ❌ | ✅ | +| Access audit logs | ❌ | ❌ | ❌ | ✅ | + +If your assigned role does not grant access you need, contact your team's Admin to request a different role. + +## Assign a role to a team member + +You assign a role when you invite a member to your team. The role you choose at invite time determines the member's permissions. + + + + Navigate to the [Team page](https://www.console.runpod.io/team) in the Runpod console. + + + In the **Members** section, select **Invite New Member**. + + + Choose the appropriate role for the new member. This role determines what the member can access and do. + + + Enter the email address of the person you want to invite and select **Create Invite**. + + + Copy the generated invitation link from the **Pending Invites** section and share it with the person you want to invite. + + + + +Invitation links remain active until used or manually revoked. + + +## Remove access + +You can revoke a pending invitation from the **Pending Invites** section before it is used. As part of general offboarding, review team membership regularly and revoke access that is no longer needed. + +To dissolve an entire team and revert to a personal account, see [Manage accounts](/accounts-billing/manage-accounts#convert-to-a-team-account). + +## Best practices + +Assign roles based on each member's responsibilities, and apply the principle of least privilege by granting the minimum role necessary for each person's work. Isolate billing access from technical operations by using the Billing role for finance staff. + +Review team membership regularly and remove access for members who no longer need it. Review audit logs periodically to ensure compliance with your organization's policies and to identify unusual activity early. + +## Next steps + + + + Create or convert a team and invite members. + + + Set up billing and payment methods. + + + Review audit logs to track actions across your team. + + + Attribute team spend by project or team. + + From 87caf0e26ff834337e15839eb170b2a959373176 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Fri, 31 Jul 2026 10:28:43 -0400 Subject: [PATCH 05/28] Update manage-accounts.mdx --- accounts-billing/manage-accounts.mdx | 65 +++++----------------------- 1 file changed, 10 insertions(+), 55 deletions(-) diff --git a/accounts-billing/manage-accounts.mdx b/accounts-billing/manage-accounts.mdx index 8d8726b07..ad1826b8a 100644 --- a/accounts-billing/manage-accounts.mdx +++ b/accounts-billing/manage-accounts.mdx @@ -29,19 +29,11 @@ You can revert your account back to a personal account at any time. To revert, s ## Invite team members -Team accounts can invite new members to collaborate. Each invitation includes a specific role that determines the member's permissions. +Team accounts can invite new members to collaborate, and each invitation includes a specific role that determines the member's permissions. Create Team Invite dialog showing role selection and required email field -To invite a new member: - -1. Navigate to the [Team page](https://www.console.runpod.io/team) in the Runpod console. -2. In the **Members** section, select **Invite New Member**. -3. Choose [the appropriate role](#roles-and-permissions) for the new member. -4. Enter the email address of the person you want to invite and click **Create Invite**. -5. Copy the generated invitation link from the **Pending Invites** section and share it with the person you want to invite. - -Invitation links remain active until used or manually revoked. You can view all pending invitations in the team management interface. +For step-by-step instructions on inviting a member and choosing their role, see [Assign a role to a team member](/accounts-billing/roles-and-permissions#assign-a-role-to-a-team-member). ## Join a team @@ -50,52 +42,17 @@ When invited to join a team, you'll receive an invitation link from a team membe 1. Click the invitation link provided by the team member. 2. Select **Join Team** to accept the invitation. -Your account will gain access to the team's resources based on the role assigned to you. +Your account will gain access to the team's resources based on the role assigned to you. To see what your assigned role allows, see [Roles and permissions](/accounts-billing/roles-and-permissions). ## Roles and permissions -Runpod provides four distinct roles to control access within team accounts. Each role includes specific permissions designed for different responsibilities. - -| Permission | Basic | Billing | Dev | Admin | -|------------|-------|---------|-----|-------| -| Access team account | ✅ | ✅ | ✅ | ✅ | -| Connect to existing Pods | ✅ | ❌ | ✅ | ✅ | -| Create/delete/start/stop Pods | ❌ | ❌ | ✅ | ✅ | -| Create/delete Serverless endpoints | ❌ | ❌ | ✅ | ✅ | -| Send requests to Serverless endpoints | ✅ | ❌ | ✅ | ✅ | -| Connect to existing Instant Clusters | ✅ | ❌ | ✅ | ✅ | -| Create/delete/start/stop Instant Clusters | ❌ | ❌ | ❌ | ✅ | -| Create/update/delete network volumes | ❌ | ❌ | ✅ | ✅ | -| View billing information | ❌ | ✅ | ❌ | ✅ | -| Manage payment methods | ❌ | ✅ | ❌ | ✅ | -| Invite team members | ❌ | ❌ | ❌ | ✅ | -| Manage team permissions | ❌ | ❌ | ❌ | ✅ | -| Modify team account settings | ❌ | ❌ | ❌ | ✅ | -| Access audit logs | ❌ | ❌ | ❌ | ✅ | - -### Basic role - -The basic role provides essential access for users who need to work with existing resources without management capabilities. - -This role allows users to access the team account and connect to already-deployed computing resources (e.g., Pods and Serverless endpoints) for development work. Users with this role cannot view billing information, start or stop Pods, or create new resources. - -### Billing role +Runpod team accounts provide four built-in roles (Basic, Billing, Dev, and Admin) that control access to Pods, Serverless endpoints, network volumes, and billing. Each role grants a different set of permissions. -The billing role focuses exclusively on financial management aspects of the account. +For the full permissions matrix and guidance on assigning and revoking roles, see [Roles and permissions](/accounts-billing/roles-and-permissions). -Users with this role can access all billing information, manage payment methods, and view invoices. They cannot access computing resources, making this role ideal for finance team members who need billing access without operational permissions. - -### Dev role - -The dev role extends basic permissions with additional capabilities for active development work. - -This role includes all basic permissions plus the ability to start, stop, and create Pods. Developers can fully manage computing resources for their work while remaining restricted from billing information and account settings. - -### Admin role - -The admin role provides complete control over all account features and settings. - -Administrators have unrestricted access to manage team members, configure account settings, handle billing, and control all team computing resources. This role should be reserved for team leaders and trusted members who need full account access. + +Apply the principle of least privilege by assigning each member the minimum role necessary for their work. + ## Account spend limits @@ -113,9 +70,7 @@ Regular review of audit logs helps identify unusual activity and ensures team me ## Best practices -When managing team accounts, establish clear role assignments based on each member's responsibilities. Regularly review team membership and remove access for members who no longer need it. - -For enhanced security, use the principle of least privilege by assigning the minimum role necessary for each team member's work. Consider creating separate accounts for billing management to isolate financial access from technical operations. +When managing team accounts, regularly review team membership and remove access for members who no longer need it. Monitor audit logs periodically to ensure compliance with your organization's policies and identify any unauthorized activities early. @@ -126,4 +81,4 @@ After setting up your account and team you can: * [Create API keys](/get-started/api-keys) to enable programmatic access to Runpod services. * [Deploy your first Pod](/get-started) to start using GPU resources. * Configure [Serverless endpoints](/serverless/overview) for scalable AI inference. -* Set up [billing and payment methods](https://console.runpod.io/user/billing) for your team. \ No newline at end of file +* Set up [billing and payment methods](https://console.runpod.io/user/billing) for your team. From de900fcbfe8b25d5cbd1bb6c6902a7424a665e38 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Fri, 31 Jul 2026 10:38:11 -0400 Subject: [PATCH 06/28] Update docs.json --- docs.json | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/docs.json b/docs.json index e0a2e7388..e0c4b7065 100644 --- a/docs.json +++ b/docs.json @@ -269,6 +269,15 @@ "accounts-billing/cost-centers", "accounts-billing/referrals", "accounts-billing/manage-payment-cards" + { + "group": "Organizations", + "pages": [ + "organizations/overview", + "organizations/roles-and-permissions", + "organizations/ssh-key-management", + "organizations/resource-tagging" + ] + } ] }, { From 7de1a963df16cdae2546f7561c24cc0659240f57 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Fri, 31 Jul 2026 11:08:55 -0400 Subject: [PATCH 07/28] Update docs.json --- docs.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs.json b/docs.json index 9cf7c0b81..7016707e5 100644 --- a/docs.json +++ b/docs.json @@ -268,7 +268,7 @@ "accounts-billing/billing", "accounts-billing/cost-centers", "accounts-billing/referrals", - "accounts-billing/manage-payment-cards" + "accounts-billing/manage-payment-cards", { "group": "Organizations", "pages": [ From a8c665612ddc5d0021f5e88a09a34bed208ea29b Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Fri, 31 Jul 2026 11:16:55 -0400 Subject: [PATCH 08/28] Update docs.json --- docs.json | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs.json b/docs.json index 7016707e5..225a2ff6d 100644 --- a/docs.json +++ b/docs.json @@ -272,10 +272,10 @@ { "group": "Organizations", "pages": [ - "organizations/overview", - "organizations/roles-and-permissions", - "organizations/ssh-key-management", - "organizations/resource-tagging" + "accounts-billing/organizations/overview", + "accounts-billing/organizations/roles-and-permissions", + "accounts-billing/organizations/ssh-key-management", + "accounts-billing/organizations/resource-tagging" ] } ] From 98b529172d2412893a8832a1a8781d666a381a50 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Fri, 31 Jul 2026 11:27:15 -0400 Subject: [PATCH 09/28] Rename overview to overview.mdx --- accounts-billing/organizations/{overview => overview.mdx} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename accounts-billing/organizations/{overview => overview.mdx} (100%) diff --git a/accounts-billing/organizations/overview b/accounts-billing/organizations/overview.mdx similarity index 100% rename from accounts-billing/organizations/overview rename to accounts-billing/organizations/overview.mdx From 8ef336288e070737c9f6c981e4d4ac3b059bee81 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Fri, 31 Jul 2026 11:29:00 -0400 Subject: [PATCH 10/28] Update docs.json --- docs.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs.json b/docs.json index 225a2ff6d..dac303efc 100644 --- a/docs.json +++ b/docs.json @@ -274,7 +274,7 @@ "pages": [ "accounts-billing/organizations/overview", "accounts-billing/organizations/roles-and-permissions", - "accounts-billing/organizations/ssh-key-management", + "accounts-billing/organizations/SSH-key-management", "accounts-billing/organizations/resource-tagging" ] } From 9fb0482b9b5acfa14121c8ad11f4ae91606ad2c2 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Fri, 31 Jul 2026 11:58:06 -0400 Subject: [PATCH 11/28] Update resource-tagging.mdx --- accounts-billing/organizations/resource-tagging.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/accounts-billing/organizations/resource-tagging.mdx b/accounts-billing/organizations/resource-tagging.mdx index 205fac50c..f7bd3cd4b 100644 --- a/accounts-billing/organizations/resource-tagging.mdx +++ b/accounts-billing/organizations/resource-tagging.mdx @@ -15,7 +15,7 @@ Tags are shared across your organization rather than defined per user. Once a ta You can apply resource tags to the following resource types: | Resource type | Description | -|--------------|-------------|Expand commentComment on line R18 +|--------------|-------------| | Pods | Tag individual Pods to organize compute resources. | | Serverless endpoints | Tag endpoints to group related Serverless workloads. | | Network volumes | Tag network volumes to track persistent storage. | From f8101bf5dfb639a057bc42dd830ec3c80b384b6e Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Fri, 31 Jul 2026 11:58:57 -0400 Subject: [PATCH 12/28] Update roles-and-permissions.mdx --- accounts-billing/organizations/roles-and-permissions.mdx | 1 + 1 file changed, 1 insertion(+) diff --git a/accounts-billing/organizations/roles-and-permissions.mdx b/accounts-billing/organizations/roles-and-permissions.mdx index d0030f447..57e11ef66 100644 --- a/accounts-billing/organizations/roles-and-permissions.mdx +++ b/accounts-billing/organizations/roles-and-permissions.mdx @@ -2,6 +2,7 @@ title: "Roles and permissions" sidebarTitle: "Roles and permissions" description: "Understand Runpod's built-in team roles and use them to control what team members can do with Pods, Serverless endpoints, network volumes, and billing." +tag: "NEW" --- Runpod team accounts use built-in roles to control what each member can access and do. Assigning roles lets an admin delegate work without granting full account control. This page is for admins who manage a team account. To create or convert a team and invite members, see [Manage accounts](/accounts-billing/manage-accounts). If you received an invitation and want to join, see [Join a team](/accounts-billing/manage-accounts#join-a-team). From d61d4f2f50c8693aaae3f444ddea34cbfc7784f9 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Fri, 31 Jul 2026 11:59:31 -0400 Subject: [PATCH 13/28] Update SSH-key-management.mdx --- accounts-billing/organizations/SSH-key-management.mdx | 1 + 1 file changed, 1 insertion(+) diff --git a/accounts-billing/organizations/SSH-key-management.mdx b/accounts-billing/organizations/SSH-key-management.mdx index 1a91bb287..70be5ab07 100644 --- a/accounts-billing/organizations/SSH-key-management.mdx +++ b/accounts-billing/organizations/SSH-key-management.mdx @@ -2,6 +2,7 @@ title: "SSH key management" sidebarTitle: "SSH key management" description: "Centrally manage SSH public keys for your organization so members can securely connect to Pods." +tag: "NEW" --- Organization-level SSH key management lets org admins store and manage SSH public keys in one place. When a member launches a Pod, org-managed keys are automatically injected into it — no per-member SSH setup required. From 7add49e8f59cae4de8e6f181fdf00f13db673275 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Fri, 31 Jul 2026 12:03:59 -0400 Subject: [PATCH 14/28] Update SSH-key-management.mdx --- .../organizations/SSH-key-management.mdx | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/accounts-billing/organizations/SSH-key-management.mdx b/accounts-billing/organizations/SSH-key-management.mdx index 70be5ab07..7ef5f181c 100644 --- a/accounts-billing/organizations/SSH-key-management.mdx +++ b/accounts-billing/organizations/SSH-key-management.mdx @@ -15,7 +15,7 @@ This is useful for teams that need consistent, auditable SSH access across all P SSH key management is controlled by org roles. - + Organization > SSH Keys? Please verify.] --> +/* [CONFIRM: Exact navigation path to SSH key management in org settings. E.g., Settings > Organization > SSH Keys? Please verify.] */ 1. Open the [Runpod console](https://console.runpod.io) and navigate to **Settings → Organization → SSH Keys**. 2. Click **Add SSH key**. @@ -87,7 +87,7 @@ The key is now available to all Pods launched by members of your org. To view, rename, or delete org SSH keys: - +/* [CONFIRM: Exact UI path and available actions (rename, delete) for managing org SSH keys.] */ 1. Navigate to **Settings → Organization → SSH Keys**. 2. Find the key you want to manage. @@ -98,7 +98,7 @@ To view, rename, or delete org SSH keys: Deleting an org SSH key immediately revokes access for all org members using that key. Members connected to a running Pod via that key will be disconnected. New Pods will not have the key injected. - +/* [CONFIRM: Does deleting a key affect currently running pods immediately, or only new pods going forward? The above assumes immediate revocation — please verify.] */ --- @@ -108,7 +108,7 @@ Deleting an org SSH key immediately revokes access for all org members using tha **Existing running Pods** do not receive newly added keys unless they are restarted. - +/* [CONFIRM: Confirm whether org keys are injected into existing running pods or only at pod creation time.] */ ### Personal vs. org keys @@ -185,7 +185,7 @@ Then connect with: `ssh runpod-mypod` - Removing a member from the org revokes their org key access. However, if the member had a personal SSH key added to a Pod before joining the org, that key remains on the Pod. Audit Pod-level keys if you need to ensure full revocation. - +/* [CONFIRM: How exactly does member removal interact with key injection? Is org access revoked from running pods immediately, or only for new pods?] */ --- From d142cbd7b5eda5ffda4b5e3b79041048b17060c7 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Fri, 31 Jul 2026 12:04:20 -0400 Subject: [PATCH 15/28] Update overview.mdx --- accounts-billing/organizations/overview.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/accounts-billing/organizations/overview.mdx b/accounts-billing/organizations/overview.mdx index 12ad2b447..e5d48f1d3 100644 --- a/accounts-billing/organizations/overview.mdx +++ b/accounts-billing/organizations/overview.mdx @@ -18,4 +18,4 @@ Organizations let you collaborate with your team on Runpod. Members share access To manage your organization's members and settings, navigate to **Settings → Organization** in the [Runpod console](https://console.runpod.io). - +/* [CONFIRM: Is the org settings path Settings → Organization, or something else in the console?] */ From 8e1cb2789dae7e70185df3b02b3d32eb8fb085af Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Fri, 31 Jul 2026 14:26:48 -0400 Subject: [PATCH 16/28] Fix MDX comment syntax: replace /* */ and - - ```bash - ssh-keygen -t ed25519 -C "your-name@yourorg.com" - ``` - - When prompted, accept the default file location (`~/.ssh/id_ed25519`) or specify a custom path. To view your public key: - - ```bash - cat ~/.ssh/id_ed25519.pub - ``` - - - ```powershell - ssh-keygen -t ed25519 -C "your-name@yourorg.com" - ``` - - When prompted, accept the default file location. To view your public key: - - ```powershell - Get-Content "$env:USERPROFILE\.ssh\id_ed25519.pub" - ``` - - If `ssh-keygen` is not available, install [OpenSSH for Windows](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse) or use [PuTTYgen](https://www.puttygen.com/). - + +```bash +ssh-keygen -t ed25519 -C "your-name@yourorg.com" +``` + +When prompted, accept the default file location (`~/.ssh/id_ed25519`) or specify a custom path. To view your public key: + +```bash +cat ~/.ssh/id_ed25519.pub +``` + + +```powershell +ssh-keygen -t ed25519 -C "your-name@yourorg.com" +``` + +When prompted, accept the default file location. To view your public key: + +```powershell +Get-Content "$env:USERPROFILE\.ssh\id_ed25519.pub" +``` + +If `ssh-keygen` is not available, install [OpenSSH for Windows](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse) or use [PuTTYgen](https://www.puttygen.com/). + Your public key will look like: @@ -71,7 +71,7 @@ ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your-name@yourorg.com ### Step 2: Add the public key to your org -/* [CONFIRM: Exact navigation path to SSH key management in org settings. E.g., Settings > Organization > SSH Keys? Please verify.] */ +{/* [CONFIRM: Exact navigation path to SSH key management in org settings. E.g., Settings > Organization > SSH Keys? Please verify.] */} 1. Open the [Runpod console](https://console.runpod.io) and navigate to **Settings → Organization → SSH Keys**. 2. Click **Add SSH key**. @@ -87,7 +87,7 @@ The key is now available to all Pods launched by members of your org. To view, rename, or delete org SSH keys: -/* [CONFIRM: Exact UI path and available actions (rename, delete) for managing org SSH keys.] */ +{/* [CONFIRM: Exact UI path and available actions (rename, delete) for managing org SSH keys.] */} 1. Navigate to **Settings → Organization → SSH Keys**. 2. Find the key you want to manage. @@ -98,7 +98,7 @@ To view, rename, or delete org SSH keys: Deleting an org SSH key immediately revokes access for all org members using that key. Members connected to a running Pod via that key will be disconnected. New Pods will not have the key injected. -/* [CONFIRM: Does deleting a key affect currently running pods immediately, or only new pods going forward? The above assumes immediate revocation — please verify.] */ +{/* [CONFIRM: Does deleting a key affect currently running pods immediately, or only new pods going forward? The above assumes immediate revocation — please verify.] */} --- @@ -108,7 +108,7 @@ Deleting an org SSH key immediately revokes access for all org members using tha **Existing running Pods** do not receive newly added keys unless they are restarted. -/* [CONFIRM: Confirm whether org keys are injected into existing running pods or only at pod creation time.] */ +{/* [CONFIRM: Confirm whether org keys are injected into existing running pods or only at pod creation time.] */} ### Personal vs. org keys @@ -150,10 +150,10 @@ To avoid specifying the identity file every time, add an entry to your `~/.ssh/c ``` Host runpod-mypod - HostName - Port - User root - IdentityFile ~/.ssh/id_ed25519 +HostName +Port +User root +IdentityFile ~/.ssh/id_ed25519 ``` Then connect with: `ssh runpod-mypod` @@ -166,7 +166,7 @@ Then connect with: `ssh runpod-mypod` **Permission denied (publickey)** - Confirm that the private key on your machine matches a public key stored in org settings. -- Verify the key was added before the Pod was launched. Org keys are only injected at Pod startup — restart the Pod if you added the key after it was created. +- Verify the key was added before the Pod was launched. Org keys are only injected at Pod startup. Restart the Pod if you added the key after it was created. - Check that you're using the correct private key file with `-i ~/.ssh/id_ed25519`. **Connected to wrong Pod / unexpected behavior** @@ -185,7 +185,7 @@ Then connect with: `ssh runpod-mypod` - Removing a member from the org revokes their org key access. However, if the member had a personal SSH key added to a Pod before joining the org, that key remains on the Pod. Audit Pod-level keys if you need to ensure full revocation. -/* [CONFIRM: How exactly does member removal interact with key injection? Is org access revoked from running pods immediately, or only for new pods?] */ +{/* [CONFIRM: How exactly does member removal interact with key injection? Is org access revoked from running pods immediately, or only for new pods?] */} --- From 7f9324b6903ed7bd0eaa5698e34e5da679b858a4 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Fri, 31 Jul 2026 14:30:18 -0400 Subject: [PATCH 17/28] Update overview.mdx --- accounts-billing/organizations/overview.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/accounts-billing/organizations/overview.mdx b/accounts-billing/organizations/overview.mdx index e5d48f1d3..058355114 100644 --- a/accounts-billing/organizations/overview.mdx +++ b/accounts-billing/organizations/overview.mdx @@ -18,4 +18,4 @@ Organizations let you collaborate with your team on Runpod. Members share access To manage your organization's members and settings, navigate to **Settings → Organization** in the [Runpod console](https://console.runpod.io). -/* [CONFIRM: Is the org settings path Settings → Organization, or something else in the console?] */ +{ /* [CONFIRM: Is the org settings path Settings → Organization, or something else in the console?] */ } From b83240dc280b1854fd84bb731a56bbb96b8e0eaa Mon Sep 17 00:00:00 2001 From: "promptless[bot]" Date: Wed, 16 Sep 2026 15:05:47 +0000 Subject: [PATCH 18/28] Correct SSH key management doc to real per-member key model Address rambo-runpod review on PR #748: SSH keys are per-member (added in account settings), not an org key store; org Pods inject the union of members' keys frozen at creation. Fix roles, remove nonexistent rename, correct delete/restart/offboarding to redeploy semantics, fix inverted connection recipes via cross-link, add data-loss warning, and remove all [CONFIRM] author notes. --- .../organizations/SSH-key-management.mdx | 216 ++++++------------ 1 file changed, 69 insertions(+), 147 deletions(-) diff --git a/accounts-billing/organizations/SSH-key-management.mdx b/accounts-billing/organizations/SSH-key-management.mdx index 9737025a0..f482add7a 100644 --- a/accounts-billing/organizations/SSH-key-management.mdx +++ b/accounts-billing/organizations/SSH-key-management.mdx @@ -1,202 +1,124 @@ --- title: "SSH key management" sidebarTitle: "SSH key management" -description: "Centrally manage SSH public keys for your organization so members can securely connect to Pods." +description: "Add your SSH public key in your Runpod account settings so members can securely connect to the Pods your organization deploys." tag: "NEW" --- -Organization-level SSH key management lets org admins store and manage SSH public keys in one place. When a member launches a Pod, org-managed keys are automatically injected into it. No per-member SSH setup required. +Each member of your organization adds their own SSH public key in their Runpod account settings. When your organization deploys a Pod, Runpod injects the public keys of all current members into that Pod, so any member can connect to it with their matching private key. -This is useful for teams that need consistent, auditable SSH access across all Pods, and makes it easy to revoke access org-wide when a member leaves. +There is no separate organization SSH keys page: members add keys on the same account settings page whether they belong to a team or an organization. The organization dimension applies only at deploy time, when Runpod combines current members' keys into the Pod. This gives your team consistent access across the organization's Pods without per-Pod key setup. ---- - -## Roles and permissions - -SSH key management is controlled by org roles. - -{/* [CONFIRM: Exact role permissions for SSH key management. Which roles can add/delete org keys vs. which roles can only use them? Align with DOCS-481 role matrix before publishing.] */} - -| Action | Owner/Admin | Member | Billing | Read-only | -|---|---|---|---|---| -| Add an org SSH key | ✅ | ❌ | ❌ | ❌ | -| Delete an org SSH key | ✅ | ❌ | ❌ | ❌ | -| Rename/manage org keys | ✅ | ❌ | ❌ | ❌ | -| Use org keys to connect to Pods | ✅ | ✅ | ❌ | ❌ | - - -Members can still add personal SSH keys to their own account in addition to org-managed keys. See [Personal vs. org keys](#personal-vs-org-keys) for how these interact. - - ---- - -## Adding an SSH key - -### Step 1: Generate a key pair - -If you don't already have an SSH key pair, generate one on your local machine. Runpod only stores the **public key**. Never paste your private key anywhere. - - - -```bash -ssh-keygen -t ed25519 -C "your-name@yourorg.com" -``` - -When prompted, accept the default file location (`~/.ssh/id_ed25519`) or specify a custom path. To view your public key: - -```bash -cat ~/.ssh/id_ed25519.pub -``` - - -```powershell -ssh-keygen -t ed25519 -C "your-name@yourorg.com" -``` - -When prompted, accept the default file location. To view your public key: - -```powershell -Get-Content "$env:USERPROFILE\.ssh\id_ed25519.pub" -``` - -If `ssh-keygen` is not available, install [OpenSSH for Windows](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse) or use [PuTTYgen](https://www.puttygen.com/). - - - -Your public key will look like: - -``` -ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your-name@yourorg.com -``` - -### Step 2: Add the public key to your org - -{/* [CONFIRM: Exact navigation path to SSH key management in org settings. E.g., Settings > Organization > SSH Keys? Please verify.] */} - -1. Open the [Runpod console](https://console.runpod.io) and navigate to **Settings → Organization → SSH Keys**. -2. Click **Add SSH key**. -3. Paste your public key into the field. -4. Give the key a name (for example, `alice-macbook` or `ci-deploy-key`) so it's easy to identify later. -5. Click **Save**. - -The key is now available to all Pods launched by members of your org. - ---- - -## Managing keys - -To view, rename, or delete org SSH keys: +## Key scope and membership -{/* [CONFIRM: Exact UI path and available actions (rename, delete) for managing org SSH keys.] */} +Runpod injects the union of current members' public keys into a Pod when the organization creates it, and that key set is frozen at creation. A key added after a Pod is created reaches only Pods deployed afterward. Restarting a Pod reuses its original key set, so to put an updated key set on a Pod, redeploy it by creating a new Pod. -1. Navigate to **Settings → Organization → SSH Keys**. -2. Find the key you want to manage. -3. To rename it, click the key name and edit it inline. -4. To delete it, click the three-dot menu next to the key and select **Delete**. +When a member leaves the organization, their key is excluded from future deploys, but it remains on any Pod that was already running with it injected. To revoke that member's access to an existing Pod, terminate and redeploy it. -Deleting an org SSH key immediately revokes access for all org members using that key. Members connected to a running Pod via that key will be disconnected. New Pods will not have the key injected. +Terminating a Pod permanently deletes any data that is not stored on a [network volume](/storage/network-volumes). Back up your data or attach a network volume before you terminate a Pod to update or revoke its keys. -{/* [CONFIRM: Does deleting a key affect currently running pods immediately, or only new pods going forward? The above assumes immediate revocation — please verify.] */} - ---- - -## Key scope and membership - -**New Pods** launched after a key is added automatically have all current org SSH keys injected at startup. +## Roles and permissions -**Existing running Pods** do not receive newly added keys unless they are restarted. +Members with any of these roles can add and delete their own SSH keys, and each member's key is included in the set injected into the organization's Pods: -{/* [CONFIRM: Confirm whether org keys are injected into existing running pods or only at pod creation time.] */} +- Admin. +- Dev. +- Basic. -### Personal vs. org keys +The Billing role is limited to billing tasks: it does not manage SSH keys or connect to compute. -Members can maintain personal SSH keys in their individual account settings in addition to org keys. Both sets of keys are injected into Pods the member launches. Either key can be used to connect. +For the full role matrix, see [Roles and permissions](/accounts-billing/organizations/roles-and-permissions). -If a member is removed from the org, their org key access is revoked, but their personal keys are unaffected. +## Add an SSH key ---- + + + If you don't already have an SSH key pair, generate one on your local machine. Runpod stores only the **public key**. Never paste your private key anywhere. -## Connecting to a Pod + + + ```bash + ssh-keygen -t ed25519 -C "your-name@yourorg.com" + ``` -Once an org SSH key is set up, any member whose private key matches an org public key can connect to a Pod. + When prompted, accept the default file location (`~/.ssh/id_ed25519`) or specify a custom path. To view your public key: -### Find the connection details + ```bash + cat ~/.ssh/id_ed25519.pub + ``` + + + ```powershell + ssh-keygen -t ed25519 -C "your-name@yourorg.com" + ``` -1. Open the [Pods page](https://console.runpod.io/pods) and expand the Pod you want to connect to. -2. Click **Connect** to view the SSH connection string. + When prompted, accept the default file location. To view your public key: -### Basic SSH + ```powershell + Get-Content "$env:USERPROFILE\.ssh\id_ed25519.pub" + ``` -```bash -ssh root@ -p -i ~/.ssh/id_ed25519 -``` + If `ssh-keygen` is not available, install [OpenSSH for Windows](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse) or use [PuTTYgen](https://www.puttygen.com/). + + -Replace `` and `` with the values shown in the console. + Your public key looks like: -### SSH over exposed TCP + ```text + ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your-name@yourorg.com + ``` + + + Paste your public key into the **SSH Public Keys** field in your [Runpod account settings](https://www.console.runpod.io/user/settings). This is the same field for team and organization members. There is no organization-specific keys page. For the full procedure, including the CLI method, see [Generate an SSH key and add it to your Runpod account](/pods/configuration/use-ssh#generate-an-ssh-key-and-add-it-to-your-runpod-account). -If the Pod exposes SSH over a TCP proxy (common for Secure Cloud Pods): + To confirm the key was saved, run `runpodctl ssh list-keys`. -```bash -ssh root@ -p -i ~/.ssh/id_ed25519 -``` + Once your key is in your account settings, it is included in the union of members' keys that Runpod injects into Pods the organization deploys afterward. + + -The proxy host and port are shown in the **Connect** dialog in the console. +## Manage your keys - -To avoid specifying the identity file every time, add an entry to your `~/.ssh/config`: +You add and delete your own keys from the **SSH Public Keys** field in your [Runpod account settings](https://www.console.runpod.io/user/settings). Paste each key on its own line to add it, and delete its line to remove it. Renaming a key is not supported. -``` -Host runpod-mypod -HostName -Port -User root -IdentityFile ~/.ssh/id_ed25519 -``` + +Because each Pod's key set is frozen at creation, deleting a key only affects Pods deployed afterward. Existing Pods keep the key until they are terminated and redeployed. + -Then connect with: `ssh runpod-mypod` - +## Connect to a Pod ---- +Connecting to an organization's Pod works the same as connecting to any other Pod: you connect with the private key that matches one of the public keys injected into the Pod. For the connection methods, including basic proxied SSH, full SSH over public IP, and password-based access, see [Connect to a Pod with SSH](/pods/configuration/use-ssh). ## Troubleshooting **Permission denied (publickey)** -- Confirm that the private key on your machine matches a public key stored in org settings. -- Verify the key was added before the Pod was launched. Org keys are only injected at Pod startup. Restart the Pod if you added the key after it was created. -- Check that you're using the correct private key file with `-i ~/.ssh/id_ed25519`. +Confirm that the public key matching your private key was in a member's account settings before the Pod was deployed, and that you're pointing SSH at the right private key with `-i`. A key added after the Pod was created reaches the Pod only after you redeploy it. If the timing is already correct, the cause is usually the key's format: see [Connect to a Pod with SSH](/pods/configuration/use-ssh#troubleshooting-ssh-key-authentication) for common issues, such as pasting the key fingerprint instead of the public key, omitting the `ssh-ed25519` prefix, or not putting each key on its own line. -**Connected to wrong Pod / unexpected behavior** +**Connected to the wrong Pod** -- Double-check the IP and port from the console. These change each time a Pod is restarted. +Copy the IP and port fresh from the **Connect** tab. They may change when you stop and resume the Pod. -**Key not propagated to Pod** +**Key not injected into a Pod** -- Org SSH keys are injected at Pod creation time. If you added the key to org settings after the Pod launched, you must restart the Pod for the key to take effect. +Runpod injects keys only when it creates a Pod (see [Key scope and membership](#key-scope-and-membership)). If you added your key after the Pod was deployed, redeploy it (terminate the Pod and deploy a new one) for the new key to take effect. -**Member cannot connect after joining the org** +**Member cannot connect after joining the organization** -- The member needs to provide the private key for one of the org's public keys. Verify they have the corresponding private key for a key stored in org settings. +A new member's key reaches only Pods the organization deploys after they join. To give them access to an existing Pod, redeploy it (terminate the Pod and deploy a new one). **Access not revoked after removing a member** -- Removing a member from the org revokes their org key access. However, if the member had a personal SSH key added to a Pod before joining the org, that key remains on the Pod. Audit Pod-level keys if you need to ensure full revocation. - -{/* [CONFIRM: How exactly does member removal interact with key injection? Is org access revoked from running pods immediately, or only for new pods?] */} - ---- +Removing a member excludes their key from future deploys only. It does not revoke their access to Pods that are already running with their key injected. To revoke access to an existing Pod, terminate and redeploy it. ## Security notes -**Only store public keys.** Never paste a private key into Runpod. Your private key should remain only on the machine you use to connect. - -**Use strong key types.** Ed25519 (`-t ed25519`) is recommended. RSA keys should be at least 4096 bits (`-t rsa -b 4096`). Avoid DSA and ECDSA with short curves. +**Store only public keys.** Never paste a private key into Runpod. Your private key stays only on the machine you connect from. -**Rotate keys regularly.** If a key may be compromised, delete it from org settings immediately and generate a new key pair. Affected members will need to add their new public key. +**Use a strong key type.** An ed25519 key (`-t ed25519`) is recommended. -**Offboarding members.** When a member leaves the org, remove their key from org settings to revoke SSH access. If they shared a key with others, replace it with a fresh key pair distributed only to current members. +**Rotate keys regularly.** If a key may be compromised, delete it from your account settings and generate a new key pair. Because existing Pods keep their injected keys until redeployed, terminate and redeploy any running Pod that must not accept the old key. -**Audit keys periodically.** Review your org's SSH keys in **Settings → Organization → SSH Keys** and remove any keys that are no longer in active use. +**Offboarding members.** Removing a member excludes their key from future deploys. To fully revoke a former member's access, terminate and redeploy the Pods their key was injected into. Runpod does not remove keys from running Pods automatically. From 6d487f4ee1fc4c49459e2e0f9b946a262c22d218 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 15:50:03 -0400 Subject: [PATCH 19/28] Update docs.json --- docs.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs.json b/docs.json index f57b8b2a0..ec1bba908 100644 --- a/docs.json +++ b/docs.json @@ -291,7 +291,7 @@ "accounts-billing/organizations/SSH-key-management", "accounts-billing/organizations/resource-tagging" ] - } + }, "accounts-billing/sales-tax", "accounts-billing/add-tax-id" ] From 08319fd7380b7eafa3137bf9bd95e206f2e0a5ce Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 16:01:21 -0400 Subject: [PATCH 20/28] Fix overview.mdx: correct links and SSH key model description --- accounts-billing/organizations/overview.mdx | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/accounts-billing/organizations/overview.mdx b/accounts-billing/organizations/overview.mdx index 058355114..154e195aa 100644 --- a/accounts-billing/organizations/overview.mdx +++ b/accounts-billing/organizations/overview.mdx @@ -8,14 +8,12 @@ Organizations let you collaborate with your team on Runpod. Members share access ## What you can manage -**Roles and permissions** — assign roles to org members to control access to pods, endpoints, billing, and org settings. See [Roles and permissions](/organizations/roles-and-permissions). +**Roles and permissions** — assign roles to org members to control access to pods, endpoints, billing, and org settings. See [Roles and permissions](/accounts-billing/organizations/roles-and-permissions). -**SSH key management** — store SSH public keys at the org level so all members can securely connect to Pods without individual key setup. See [SSH key management](/organizations/ssh-key-management). +**SSH key management** — each member adds their own SSH public key in their Runpod account settings. When your organization deploys a Pod, Runpod injects the public keys of all current members into that Pod so any member can connect with their matching private key. See [SSH key management](/accounts-billing/organizations/SSH-key-management). -**Resource tagging** — create and apply key/value tags to Pods, Endpoints, Network Volumes, and Clusters to organize resources by team, project, or environment. See [Resource tagging](/organizations/resource-tagging). +**Resource tagging** — create and apply key/value tags to Pods, Endpoints, Network Volumes, and Clusters to organize resources by team, project, or environment. See [Resource tagging](/accounts-billing/organizations/resource-tagging). ## Managing your organization To manage your organization's members and settings, navigate to **Settings → Organization** in the [Runpod console](https://console.runpod.io). - -{ /* [CONFIRM: Is the org settings path Settings → Organization, or something else in the console?] */ } From 837226e3652e8cddb21cde1ac99b0a49cd8fbde1 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 16:01:56 -0400 Subject: [PATCH 21/28] Fix manage-accounts.mdx: update role page links to organizations subfolder --- accounts-billing/manage-accounts.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/accounts-billing/manage-accounts.mdx b/accounts-billing/manage-accounts.mdx index ad1826b8a..c2995c50a 100644 --- a/accounts-billing/manage-accounts.mdx +++ b/accounts-billing/manage-accounts.mdx @@ -33,7 +33,7 @@ Team accounts can invite new members to collaborate, and each invitation include Create Team Invite dialog showing role selection and required email field -For step-by-step instructions on inviting a member and choosing their role, see [Assign a role to a team member](/accounts-billing/roles-and-permissions#assign-a-role-to-a-team-member). +For step-by-step instructions on inviting a member and choosing their role, see [Assign a role to a team member](/accounts-billing/organizations/roles-and-permissions#assign-a-role-to-a-team-member). ## Join a team @@ -42,13 +42,13 @@ When invited to join a team, you'll receive an invitation link from a team membe 1. Click the invitation link provided by the team member. 2. Select **Join Team** to accept the invitation. -Your account will gain access to the team's resources based on the role assigned to you. To see what your assigned role allows, see [Roles and permissions](/accounts-billing/roles-and-permissions). +Your account will gain access to the team's resources based on the role assigned to you. To see what your assigned role allows, see [Roles and permissions](/accounts-billing/organizations/roles-and-permissions). ## Roles and permissions Runpod team accounts provide four built-in roles (Basic, Billing, Dev, and Admin) that control access to Pods, Serverless endpoints, network volumes, and billing. Each role grants a different set of permissions. -For the full permissions matrix and guidance on assigning and revoking roles, see [Roles and permissions](/accounts-billing/roles-and-permissions). +For the full permissions matrix and guidance on assigning and revoking roles, see [Roles and permissions](/accounts-billing/organizations/roles-and-permissions). Apply the principle of least privilege by assigning each member the minimum role necessary for their work. From 5e3561557f1f4826589aa664acd5b65fab8ad1dc Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 16:02:31 -0400 Subject: [PATCH 22/28] Fix SSH-key-management.mdx: clarify Billing role key injection behavior --- accounts-billing/organizations/SSH-key-management.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/accounts-billing/organizations/SSH-key-management.mdx b/accounts-billing/organizations/SSH-key-management.mdx index f482add7a..4ad5f030a 100644 --- a/accounts-billing/organizations/SSH-key-management.mdx +++ b/accounts-billing/organizations/SSH-key-management.mdx @@ -27,7 +27,7 @@ Members with any of these roles can add and delete their own SSH keys, and each - Dev. - Basic. -The Billing role is limited to billing tasks: it does not manage SSH keys or connect to compute. +The Billing role does not manage SSH keys through the console. However, if a Billing member has a public key in their account settings, that key is still included in the union injected into the organization's Pods. To exclude someone from Pod SSH access, remove them from the organization before deploying. For the full role matrix, see [Roles and permissions](/accounts-billing/organizations/roles-and-permissions). From 95f98d872adaea8d6dec848205c4d89cad3eac47 Mon Sep 17 00:00:00 2001 From: "promptless[bot]" Date: Wed, 16 Sep 2026 20:13:46 +0000 Subject: [PATCH 23/28] Apply Runpod style guide and promptless.md rules to branch files - Rename SSH-key-management.mdx to kebab-case ssh-key-management.mdx and update docs.json nav + the overview link to the lowercase path - Fix docs.json Organizations pages-array indentation to match siblings - Replace em-dash label separators with colons in overview.mdx - Correct term casing in overview.mdx (Pods; endpoints/network volumes lowercase; Instant Clusters); spell out 'org' as 'organization' - Expand overview and resource-tagging meta descriptions to 110-160 chars --- accounts-billing/organizations/overview.mdx | 8 ++++---- accounts-billing/organizations/resource-tagging.mdx | 2 +- .../{SSH-key-management.mdx => ssh-key-management.mdx} | 0 docs.json | 8 ++++---- 4 files changed, 9 insertions(+), 9 deletions(-) rename accounts-billing/organizations/{SSH-key-management.mdx => ssh-key-management.mdx} (100%) diff --git a/accounts-billing/organizations/overview.mdx b/accounts-billing/organizations/overview.mdx index 154e195aa..ad167aeca 100644 --- a/accounts-billing/organizations/overview.mdx +++ b/accounts-billing/organizations/overview.mdx @@ -1,18 +1,18 @@ --- title: "Organizations" sidebarTitle: "Overview" -description: "Manage teams, access, and resources across your Runpod organization." +description: "Manage your Runpod organization: assign roles and permissions, share SSH keys across members, and tag resources by team, project, or environment." --- Organizations let you collaborate with your team on Runpod. Members share access to resources, and admins control who can do what through roles and permissions. ## What you can manage -**Roles and permissions** — assign roles to org members to control access to pods, endpoints, billing, and org settings. See [Roles and permissions](/accounts-billing/organizations/roles-and-permissions). +**Roles and permissions**: assign roles to organization members to control access to Pods, endpoints, billing, and organization settings. See [Roles and permissions](/accounts-billing/organizations/roles-and-permissions). -**SSH key management** — each member adds their own SSH public key in their Runpod account settings. When your organization deploys a Pod, Runpod injects the public keys of all current members into that Pod so any member can connect with their matching private key. See [SSH key management](/accounts-billing/organizations/SSH-key-management). +**SSH key management**: each member adds their own SSH public key in their Runpod account settings. When your organization deploys a Pod, Runpod injects the public keys of all current members into that Pod so any member can connect with their matching private key. See [SSH key management](/accounts-billing/organizations/ssh-key-management). -**Resource tagging** — create and apply key/value tags to Pods, Endpoints, Network Volumes, and Clusters to organize resources by team, project, or environment. See [Resource tagging](/accounts-billing/organizations/resource-tagging). +**Resource tagging**: create and apply key/value tags to Pods, endpoints, network volumes, and Instant Clusters to organize resources by team, project, or environment. See [Resource tagging](/accounts-billing/organizations/resource-tagging). ## Managing your organization diff --git a/accounts-billing/organizations/resource-tagging.mdx b/accounts-billing/organizations/resource-tagging.mdx index f7bd3cd4b..a682d6da3 100644 --- a/accounts-billing/organizations/resource-tagging.mdx +++ b/accounts-billing/organizations/resource-tagging.mdx @@ -1,6 +1,6 @@ --- title: "Resource tags" -description: "Organize, filter, and track usage of Runpod resources across your organization with tags." +description: "Organize, filter, and track usage of your Runpod Pods, endpoints, network volumes, and Instant Clusters across your organization with shared key-value tags." tag: "NEW" --- diff --git a/accounts-billing/organizations/SSH-key-management.mdx b/accounts-billing/organizations/ssh-key-management.mdx similarity index 100% rename from accounts-billing/organizations/SSH-key-management.mdx rename to accounts-billing/organizations/ssh-key-management.mdx diff --git a/docs.json b/docs.json index ec1bba908..a519eed1e 100644 --- a/docs.json +++ b/docs.json @@ -286,10 +286,10 @@ { "group": "Organizations", "pages": [ - "accounts-billing/organizations/overview", - "accounts-billing/organizations/roles-and-permissions", - "accounts-billing/organizations/SSH-key-management", - "accounts-billing/organizations/resource-tagging" + "accounts-billing/organizations/overview", + "accounts-billing/organizations/roles-and-permissions", + "accounts-billing/organizations/ssh-key-management", + "accounts-billing/organizations/resource-tagging" ] }, "accounts-billing/sales-tax", From b293904953ec259c2b5d9964e485e4c8589a8d07 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 16:57:14 -0400 Subject: [PATCH 24/28] Update overview.mdx --- accounts-billing/organizations/overview.mdx | 1 + 1 file changed, 1 insertion(+) diff --git a/accounts-billing/organizations/overview.mdx b/accounts-billing/organizations/overview.mdx index ad167aeca..e5f857a00 100644 --- a/accounts-billing/organizations/overview.mdx +++ b/accounts-billing/organizations/overview.mdx @@ -2,6 +2,7 @@ title: "Organizations" sidebarTitle: "Overview" description: "Manage your Runpod organization: assign roles and permissions, share SSH keys across members, and tag resources by team, project, or environment." +tag: "Beta" --- Organizations let you collaborate with your team on Runpod. Members share access to resources, and admins control who can do what through roles and permissions. From 0c439a56692adf8e4f1badbf19b20750cd9bcd74 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 16:57:32 -0400 Subject: [PATCH 25/28] Update resource-tagging.mdx --- accounts-billing/organizations/resource-tagging.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/accounts-billing/organizations/resource-tagging.mdx b/accounts-billing/organizations/resource-tagging.mdx index a682d6da3..9023a7c73 100644 --- a/accounts-billing/organizations/resource-tagging.mdx +++ b/accounts-billing/organizations/resource-tagging.mdx @@ -1,7 +1,7 @@ --- title: "Resource tags" description: "Organize, filter, and track usage of your Runpod Pods, endpoints, network volumes, and Instant Clusters across your organization with shared key-value tags." -tag: "NEW" +tag: "Beta" --- Resource tags are key-value labels you create and apply to your Runpod resources to organize, filter, and track usage across your organization. By tagging resources, you can group them in ways that reflect how your teams, projects, and environments are structured. From 66a8680214602505804a058e0ecb4f8de136b524 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 16:58:04 -0400 Subject: [PATCH 26/28] Update roles-and-permissions.mdx --- accounts-billing/organizations/roles-and-permissions.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/accounts-billing/organizations/roles-and-permissions.mdx b/accounts-billing/organizations/roles-and-permissions.mdx index 57e11ef66..e88b12fd7 100644 --- a/accounts-billing/organizations/roles-and-permissions.mdx +++ b/accounts-billing/organizations/roles-and-permissions.mdx @@ -2,7 +2,7 @@ title: "Roles and permissions" sidebarTitle: "Roles and permissions" description: "Understand Runpod's built-in team roles and use them to control what team members can do with Pods, Serverless endpoints, network volumes, and billing." -tag: "NEW" +tag: "Beta" --- Runpod team accounts use built-in roles to control what each member can access and do. Assigning roles lets an admin delegate work without granting full account control. This page is for admins who manage a team account. To create or convert a team and invite members, see [Manage accounts](/accounts-billing/manage-accounts). If you received an invitation and want to join, see [Join a team](/accounts-billing/manage-accounts#join-a-team). From 72662490c2ac0d8d488594ee49932b5eb22f545d Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 16:58:21 -0400 Subject: [PATCH 27/28] Update ssh-key-management.mdx --- accounts-billing/organizations/ssh-key-management.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/accounts-billing/organizations/ssh-key-management.mdx b/accounts-billing/organizations/ssh-key-management.mdx index 4ad5f030a..66b6bd7dc 100644 --- a/accounts-billing/organizations/ssh-key-management.mdx +++ b/accounts-billing/organizations/ssh-key-management.mdx @@ -2,7 +2,7 @@ title: "SSH key management" sidebarTitle: "SSH key management" description: "Add your SSH public key in your Runpod account settings so members can securely connect to the Pods your organization deploys." -tag: "NEW" +tag: "Beta" --- Each member of your organization adds their own SSH public key in their Runpod account settings. When your organization deploys a Pod, Runpod injects the public keys of all current members into that Pod, so any member can connect to it with their matching private key. From a8cc0e22adfe7c833e8e124ec417e14ec9532aed Mon Sep 17 00:00:00 2001 From: "promptless[bot]" Date: Mon, 19 Oct 2026 14:57:47 +0000 Subject: [PATCH 28/28] Document SSH key injection and sync on the SSH key management page --- .../organizations/ssh-key-management.mdx | 70 ++++++++++++------- pods/configuration/connect-to-ide.mdx | 13 +--- pods/configuration/use-ssh.mdx | 4 +- 3 files changed, 51 insertions(+), 36 deletions(-) diff --git a/accounts-billing/organizations/ssh-key-management.mdx b/accounts-billing/organizations/ssh-key-management.mdx index 66b6bd7dc..e52303ee9 100644 --- a/accounts-billing/organizations/ssh-key-management.mdx +++ b/accounts-billing/organizations/ssh-key-management.mdx @@ -1,33 +1,51 @@ --- title: "SSH key management" sidebarTitle: "SSH key management" -description: "Add your SSH public key in your Runpod account settings so members can securely connect to the Pods your organization deploys." +description: "Add your SSH public key in your Runpod account settings, and Runpod keeps it in sync across the Pods your organization deploys." tag: "Beta" --- -Each member of your organization adds their own SSH public key in their Runpod account settings. When your organization deploys a Pod, Runpod injects the public keys of all current members into that Pod, so any member can connect to it with their matching private key. +Each member of your organization adds their own SSH public key in their Runpod account settings. Runpod injects those keys into the organization's Pods and keeps them in sync. Running Pods pick up key changes and membership changes without a redeploy. -There is no separate organization SSH keys page: members add keys on the same account settings page whether they belong to a team or an organization. The organization dimension applies only at deploy time, when Runpod combines current members' keys into the Pod. This gives your team consistent access across the organization's Pods without per-Pod key setup. +Members add keys on the same account settings page whether they belong to a team or an organization. There is no separate organization keys page. Runpod combines members' keys for each Pod, which gives your team consistent access across the organization's Pods without per-Pod key setup. -## Key scope and membership +## How key injection works -Runpod injects the union of current members' public keys into a Pod when the organization creates it, and that key set is frozen at creation. A key added after a Pod is created reaches only Pods deployed afterward. Restarting a Pod reuses its original key set, so to put an updated key set on a Pod, redeploy it by creating a new Pod. +Runpod writes the public keys of everyone with access to a Pod into that Pod's `/root/.ssh/authorized_keys` file. The host machine checks the key set continuously, so a key change usually reaches running Pods in under a minute. Runpod also rewrites the file when the Pod restarts and every 15 minutes, even when no key has changed. -When a member leaves the organization, their key is excluded from future deploys, but it remains on any Pod that was already running with it injected. To revoke that member's access to an existing Pod, terminate and redeploy it. +Runpod manages the entire `authorized_keys` file. Any key you add to the file manually from inside the Pod is removed at the next sync. To give someone SSH access, add their key to their account settings or add them to the organization instead. - -Terminating a Pod permanently deletes any data that is not stored on a [network volume](/storage/network-volumes). Back up your data or attach a network volume before you terminate a Pod to update or revoke its keys. - +The key set comes from account settings only. The `PUBLIC_KEY` and `RUNPOD_SSH_PUBLIC_KEY` environment variables no longer change which keys can connect over SSH via public IP. If a Pod sets either variable, Runpod replaces that key with the account keys at the next sync. + +Key injection applies to Pods, including the nodes of [Instant Clusters](/instant-clusters). It does not apply to Serverless workers, which use only the endpoint owner's keys. + +### Connection methods + +The two SSH connection methods apply key changes at different times. + +With proxied SSH through `ssh.runpod.io`, Runpod checks your key against your current account settings each time you log in. A key you add or delete takes effect at your next login. + +With SSH via public IP, you connect directly to the SSH daemon inside the Pod, which reads `authorized_keys`. Key changes take effect after the next sync, usually within a minute. + +For both methods, SSH sessions that are already open stay open after a key is deleted or a member is removed. + +## Who receives keys + +A Pod receives the keys of the same people who can see it in the console. + +A personal Pod receives its owner's keys. By default, an organization Pod receives the keys of the member who created the Pod, members who share a [group](/organizations/orgs-groups) with them, and organization admins. If your organization lets every member see all resources, every member's keys are injected. + +When a member joins the organization, their keys reach the Pods they can see at the next sync. When a member leaves, their keys are removed from those Pods at the next sync. ## Roles and permissions -Members with any of these roles can add and delete their own SSH keys, and each member's key is included in the set injected into the organization's Pods: +Members with any of these roles can add and delete their own SSH keys. Runpod injects each member's keys into the organization's Pods that member can see: - Admin. - Dev. - Basic. -The Billing role does not manage SSH keys through the console. However, if a Billing member has a public key in their account settings, that key is still included in the union injected into the organization's Pods. To exclude someone from Pod SSH access, remove them from the organization before deploying. +The Billing role does not manage SSH keys through the console. However, Runpod still injects a Billing member's public key into the organization's Pods they can see. To remove someone's SSH access, remove them from the organization. For the full role matrix, see [Roles and permissions](/accounts-billing/organizations/roles-and-permissions). @@ -75,7 +93,7 @@ For the full role matrix, see [Roles and permissions](/accounts-billing/organiza To confirm the key was saved, run `runpodctl ssh list-keys`. - Once your key is in your account settings, it is included in the union of members' keys that Runpod injects into Pods the organization deploys afterward. + Runpod injects your new key into the Pods you can see at the next sync, usually within a minute. You don't need to redeploy running Pods. @@ -83,9 +101,7 @@ For the full role matrix, see [Roles and permissions](/accounts-billing/organiza You add and delete your own keys from the **SSH Public Keys** field in your [Runpod account settings](https://www.console.runpod.io/user/settings). Paste each key on its own line to add it, and delete its line to remove it. Renaming a key is not supported. - -Because each Pod's key set is frozen at creation, deleting a key only affects Pods deployed afterward. Existing Pods keep the key until they are terminated and redeployed. - +When you delete a key, Runpod removes it from running Pods at the next sync. Proxied SSH stops accepting the key at your next login. ## Connect to a Pod @@ -95,23 +111,27 @@ Connecting to an organization's Pod works the same as connecting to any other Po **Permission denied (publickey)** -Confirm that the public key matching your private key was in a member's account settings before the Pod was deployed, and that you're pointing SSH at the right private key with `-i`. A key added after the Pod was created reaches the Pod only after you redeploy it. If the timing is already correct, the cause is usually the key's format: see [Connect to a Pod with SSH](/pods/configuration/use-ssh#troubleshooting-ssh-key-authentication) for common issues, such as pasting the key fingerprint instead of the public key, omitting the `ssh-ed25519` prefix, or not putting each key on its own line. +Confirm that the matching public key is in your account settings. Then check that you pass the right private key to SSH with `-i`. If you added the key in the last minute, wait for the next sync and try again. If the error continues, check the key's format. For common format issues, see [Connect to a Pod with SSH](/pods/configuration/use-ssh#troubleshooting-ssh-key-authentication). **Connected to the wrong Pod** Copy the IP and port fresh from the **Connect** tab. They may change when you stop and resume the Pod. -**Key not injected into a Pod** +**A key added inside the Pod stopped working** -Runpod injects keys only when it creates a Pod (see [Key scope and membership](#key-scope-and-membership)). If you added your key after the Pod was deployed, redeploy it (terminate the Pod and deploy a new one) for the new key to take effect. +Runpod manages the Pod's `authorized_keys` file and removes keys added from inside the Pod at the next sync. Add the key to your account settings instead. -**Member cannot connect after joining the organization** +**SSH via public IP doesn't work on a Pod deployed without keys** -A new member's key reaches only Pods the organization deploys after they join. To give them access to an existing Pod, redeploy it (terminate the Pod and deploy a new one). +If no SSH keys were available when the Pod was deployed, the Pod might not start its SSH daemon. Add your key to your account settings, then redeploy the Pod (terminate it and deploy a new one). -**Access not revoked after removing a member** + +Terminating a Pod permanently deletes any data that is not stored on a [network volume](/storage/network-volumes). Back up your data or attach a network volume before you terminate a Pod. + -Removing a member excludes their key from future deploys only. It does not revoke their access to Pods that are already running with their key injected. To revoke access to an existing Pod, terminate and redeploy it. +**Member can't connect to a Pod** + +Confirm that the member can see the Pod in the console. A Pod receives only the keys of members who can see it (see [Who receives keys](#who-receives-keys)). ## Security notes @@ -119,6 +139,8 @@ Removing a member excludes their key from future deploys only. It does not revok **Use a strong key type.** An ed25519 key (`-t ed25519`) is recommended. -**Rotate keys regularly.** If a key may be compromised, delete it from your account settings and generate a new key pair. Because existing Pods keep their injected keys until redeployed, terminate and redeploy any running Pod that must not accept the old key. +**Rotate keys regularly.** If a key may be compromised, delete it from your account settings and generate a new key pair. Runpod removes the deleted key from running Pods at the next sync. After a Pod restarts, the deleted key can still connect for up to about 30 seconds, until the first sync completes. + +**Offboarding members.** When you remove a member from the organization, Runpod removes their keys from the organization's Pods at the next sync. Proxied SSH rejects their keys at their next login. Key removal doesn't close SSH sessions that are already open. To end them, restart the affected Pods. -**Offboarding members.** Removing a member excludes their key from future deploys. To fully revoke a former member's access, terminate and redeploy the Pods their key was injected into. Runpod does not remove keys from running Pods automatically. +**Know what key sync controls.** Key sync manages only the `authorized_keys` file. It doesn't undo other access that a former member set up inside a Pod. For example, they might have created another user account, changed `sshd_config`, or added a scheduled job. If a former member had SSH access to a Pod that holds sensitive data, review the Pod or redeploy it. diff --git a/pods/configuration/connect-to-ide.mdx b/pods/configuration/connect-to-ide.mdx index cb096667c..5a92f0225 100644 --- a/pods/configuration/connect-to-ide.mdx +++ b/pods/configuration/connect-to-ide.mdx @@ -47,16 +47,9 @@ Before you can connect to a Pod, you'll need an SSH key that is paired with your 3. Copy and paste the output into the **SSH Public Keys** field in your [Runpod user account settings](https://console.runpod.io/user/settings). - -To enable SSH access, your public key must be present in the `~/.ssh/authorized_keys` file on your Pod. If you upload your public key to the settings page before your Pod starts, the system will automatically inject it into that file at startup. - -If your Pod is already running when you upload the key, the system will not perform this injection. To enable SSH access, you'll need to either terminate/redeploy the Pod, or open a [web terminal](/pods/connect-to-a-pod#web-terminal-connection) on the running Pod and run the following commands: - -```sh -export PUBLIC_KEY="" -echo "$PUBLIC_KEY" >> ~/.ssh/authorized_keys -``` - + +Runpod injects the keys from your account settings into your Pods' `~/.ssh/authorized_keys` file and keeps them in sync. If your Pod is already running, the new key usually reaches it within a minute. You don't need to redeploy. Don't add keys to `authorized_keys` manually from inside the Pod, because Runpod overwrites the file at the next sync. + ## Step 3: Deploy a Pod diff --git a/pods/configuration/use-ssh.mdx b/pods/configuration/use-ssh.mdx index 6a06cdba8..689d9cc7e 100644 --- a/pods/configuration/use-ssh.mdx +++ b/pods/configuration/use-ssh.mdx @@ -68,9 +68,9 @@ SSH key authentication is recommended for security and convenience. -### Override your public key for a specific Pod +### How Runpod injects your keys -Runpod will attempt to automatically inject the public SSH keys added in your account settings for authentication when connecting using the [basic terminal method](#basic-ssh-with-key-authentication). If you prefer to use a different public key for a specific Pod, you can override the default by setting the `SSH_PUBLIC_KEY` [environment variable](/pods/templates/environment-variables) for that Pod. +Runpod injects the public keys from your account settings into your Pods' `/root/.ssh/authorized_keys` file and keeps them in sync. When you add or delete a key, running Pods usually pick up the change within a minute, without a redeploy. Runpod manages the whole file and removes keys added manually from inside the Pod at the next sync. Environment variables such as `PUBLIC_KEY` don't override your account keys. For details, including how keys are shared across an organization's Pods, see [SSH key management](/accounts-billing/organizations/ssh-key-management). ## Basic SSH with key authentication