SSH and Shell Access

You can initiate a shell session to your Render service from its Shell page in the Render Dashboard:

You can also connect from your terminal over SSH after completing setup.

Shell compatibility

Support for shell access varies by service type:

SSH setup

1. Generate an SSH key pair

1. Run the following command to generate an Ed25519 key pair in the ~/.ssh directory:

   shellCopy to clipboard

   $ ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519

   You can optionally use a different key type.

2. The command prompts you to provide an optional passphrase for your private key (recommended for added security).

3. The command generates two files in your ~/.ssh directory:

   • ~/.ssh/id_ed25519 (private key)
   • ~/.ssh/id_ed25519.pub (public key)

2. Add your public key to your Render account

1. Open your Account settings page in the Render Dashboard.

2. Find the SSH Public Keys section and click + Add SSH Public Key. The creation dialog appears.

3. Provide a descriptive Name for the key (e.g., "Personal Laptop").

4. Copy the full contents of your public key file (ends in .pub) to your clipboard.

   On macOS, you can use the pbcopy command to copy the file to your clipboard:

   shellCopy to clipboard

   $ pbcopy < ~/.ssh/id_ed25519.pub

5. Paste your public key into the Key field:

   

6. Click Add SSH Public Key button to save your key.

All set! You're ready to start an SSH session.

Starting an SSH session

After completing SSH setup, you can start SSH sessions from your terminal using the Render CLI, or by running the ssh command directly.

Select a method from the tabs below:

$ render ssh srv-abc123

Troubleshooting permission failures

If you receive a "Permission denied" error, Render rejected the incoming SSH session. Take the following steps first to troubleshoot this issue:

Confirm which SSH key you're using

Add the "verbose" flag (-v) to your SSH command to get more details about which key is being used:

$ ssh -v YOUR_SERVICE@ssh.YOUR_REGION.render.com
$ [...]
$ debug1: identity file /Users/YOUR_NAME/.ssh/id_ed25519 type 3
$ debug1: identity file /Users/YOUR_NAME/.ssh/id_ed25519-cert type -1
$ [...]
$ debug1: Next authentication method: publickey
$ debug1: Offering public key: /Users/YOUR_NAME/.ssh/id_ed25519
$ [...]
$ Permission denied (publickey).

Confirm which keys are attached to your Render account

1. List any keys you have loaded into the ssh-agent.

   shellCopy to clipboard

   $ ssh-add -l

   This should should print out a long string of numbers and letters.

   Copy to clipboard

   256 SHA256:SSH_KEY_FINGERPRINT YOUR_NAME@YOUR_HOST (ED25519)

2. Open your settings page in the Dashboard and find the list of SSH public keys.

3. Compare the list of SSH keys with the output from the ssh-add command.

If you don't see your public key listed, you can add it to your account.

Render's public key fingerprints

Public key fingerprints can be used to validate a connection to a remote server.

Render’s public SSH key fingerprints are as follows:

You can also directly add Render's public keys to your $SSH_DIR/known_hosts file. Render's full set of entries is as follows:

# RENDER PUBLIC KEYS
# ------------------

# Oregon
ssh.oregon.render.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFON8eay2FgHDBIVOLxWn/AWnsDJhCVvlY1igWEFoLD2

# Ohio
ssh.ohio.render.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINMjC1BfZQ3CYotN1/EqI48hvBpZ80zfgRdK8NpP58v1

# Virginia
ssh.virginia.render.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJ6uO0jKQX9IjefnLz+pxTgfPhsPBhNuvxmvCFrxqxAM

# Frankfurt
ssh.frankfurt.render.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILg6kMvQOQjMREehk1wvBKsfe1I3+acRuS8cVSdLjinK

# Singapore
ssh.singapore.render.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGVcVcsy7RXA60ZyHs/OMS5aQj4YQy7Qn2nJCXHz4zLA

Usage details

Supported key types

Render supports the following key types:

• ed25519
• ecdsa
• rsa

Render also supports U2F/FIDO hardware authenticated keys like a YubiKey.

• ed25519-sk
• ecdsa-sk

Docker-specific configuration

If your service runs a Docker image, additional configuration is required for it to accept SSH connections:

1. Make sure your image includes openSSH (openssh-server).

2. Make sure your Dockerfile creates a ~/.ssh directory for the running user with the correct permissions (chmod 0700).

3. If the running user is not the root user, that user must have shell access.

   • If your Dockerfile references a parent image, you will need to perform these steps in a Dockerfile that you control, making use of the USER instruction to change back to a root user and usermod (or equivalent) to modify the non-root user, like so:

     dockerfileCopy to clipboard

     # Switch to root to modify user
     USER root
     RUN usermod -s /bin/bash myuser
     # Switch back to non-root user
     USER myuser

Additionally, some configurations are not supported:

• If your Dockerfile specifies a root user, the account cannot be locked. Use usermod --unlock root or passwd -u root to unlock the account.
• If your service uses a persistent disk, you must not mount it to the $HOME directory of the running user.

Cron job connections

When you connect to a cron job from the Dashboard shell, Render spins up a new, temporary instance of the service and connects to it. This instance includes your cron job's latest build and configuration. It does not automatically execute the cron job's command. After you close the shell session, Render deprovisions the instance.

It is not possible to connect to the actual cron job instances that run as part of your cron schedule.

Automatic session closure

Render automatically closes a service's active SSH sessions in the following cases:

• The service is redeployed or restarted for any reason.
• Render is scheduled to perform maintenance on underlying infrastructure that enables SSH connections.
  • In this case, Render gives existing connections one hour before automatically closing them.

For long-running commands, consider spinning up a one-off job instead of SSHing into an active instance.

Memory usage

SSH and dashboard shell sessions use the same memory pool that's allocated for your service instance. Using SSH requires about 2 MB of memory, plus about 3 MB for each active session (not including memory used by processes executed during the session).

As an example, let's say we SSH into one service instance from two different computers to run bash. In this case, memory usage would look like this:

• 8 MB for SSH
  • 2 MB for SSH access
  • 2x3 MB for the two SSH sessions
• 7 MB for bash
  • 2x3.5 MB for the two bash processes

Total memory usage in this case is about 15 MB.