SSH Access

Every sandbox is reachable over plain SSH through Daytona's SSH gateway. There are no keys to generate or upload: you authenticate with your existing API key, encoded into the SSH username together with the sandbox id. Because it's real SSH, the entire standard toolset works unchanged — interactive shells, one-shot commands, scp, sftp, port forwarding, and IDE remote-development clients.

Connecting

Connect to port 2222 of the SSH gateway host, with a username of the form <sandbox_id>#<api_key>:

# Interactive shell
ssh -p 2222 "<sandbox_id>#<api_key>"@<ssh-host>
 
# One-shot command (exit code is passed through)
ssh -p 2222 "<sandbox_id>#<api_key>"@<ssh-host> nproc
 
# Copy files in and out
scp -P 2222 script.py "<sandbox_id>#<api_key>"@<ssh-host>:/workspace/
scp -P 2222 "<sandbox_id>#<api_key>"@<ssh-host>:/workspace/results.json .
 
# Interactive file transfer
sftp -P 2222 "<sandbox_id>#<api_key>"@<ssh-host>

Note: <ssh-host> is the SSH gateway hostname for your sandbox's region — it's shown, along with a ready-to-copy command, in the SSH tab of the sandbox's page in the dashboard. Quote the username: the # would otherwise start a shell comment.

Authentication is your project API key — the same rlp_... key you use with the SDK and REST API. Anyone with the key can reach any sandbox in the project, so treat it accordingly and see Authentication for key management.

IDE remote development

Because the gateway speaks standard SSH, VS Code Remote-SSH and JetBrains Gateway both work against a sandbox. The easiest setup is an entry in ~/.ssh/config, which also spares you retyping the long username:

# ~/.ssh/config
Host my-sandbox
  HostName <ssh-host>
  Port 2222
  User <sandbox_id>#<api_key>

Then:

• Terminal: ssh my-sandbox
• VS Code: install the Remote - SSH extension, run Remote-SSH: Connect to Host…, and pick my-sandbox.
• JetBrains: in Gateway (or File → Remote Development), create an SSH connection to my-sandbox and open a project directory inside the sandbox.

Port forwarding over SSH

The -L flag gives you ad hoc access to any service listening inside the sandbox, without declaring ports or creating preview endpoints. It tunnels a local port to a sandbox port for the lifetime of the SSH session:

# Make the sandbox's :8000 available on localhost:8000
ssh -p 2222 -L 8000:localhost:8000 "<sandbox_id>#<api_key>"@<ssh-host>
 
# In another terminal:
curl http://localhost:8000/

This is the quickest way to poke at a dev server or database inside a sandbox. For stable, shareable URLs use preview endpoints instead.

Behavior notes

A few properties worth knowing:

• Exit codes and streams pass through faithfully. cmd | ssh ... remote-cmd pipelines, exit-code checks in scripts, and PTY sessions (ssh -tt) all behave as with a normal SSH server.
• No host keys to manage on the sandbox side. The gateway terminates your SSH connection; you never install or rotate keys inside sandboxes.
• Sessions are resilient to platform maintenance. Long-lived SSH sessions survive live migration of the sandbox between hosts.
• The sandbox must be running. A stopped or paused sandbox has no compute to connect to — start or resume it first.

See also

• Running Commands — programmatic execution via the SDK, usually better for automation than shelling out to ssh.
• Port Forwarding — declared ports and preview URLs for longer-lived access.
• Working with Files — the SDK alternative to scp/sftp.