Skip to main content

Connect over SSH

Copy the connect command​

Open the instance from Instances and stay on the Connect tab. The command is rendered for you with the host, port and user already filled in:

ssh -p 40123 root@sh-us-tx-01.ssh.superheat.dev

Use the copy button next to it rather than retyping the parts. Connection details appear only once the instance reaches running; until then the tab tells you they are not ready.

The user is root unless the rendered command says otherwise. Authentication uses the SSH key you attached at deploy time.

Why the port is not 22​

Inside the container, sshd listens on 22. That port is then published to a port on the host machine, drawn from the range that host has available, and that host port is what you connect to. The number is assigned at launch, it differs from instance to instance, and it has nothing to do with 22.

Two consequences worth remembering:

ssh root@sh-us-tx-01.ssh.superheat.dev with no -pfails, or reaches something that is not your instance
The host and port after a stop and startare reissued, so they may not be the pair you used before

Re-copy the command from the Connect tab after every start instead of relying on a shell history entry.

The first connection​

The container generates a fresh host key the first time it boots, so a new instance always prompts:

The authenticity of host '[sh-us-tx-01.ssh.superheat.dev]:40123 ([203.0.113.14]:40123)' can't be established.
ED25519 key fingerprint is SHA256:0Xk2r1uJ3q…
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Answer yes. The fingerprint is recorded in ~/.ssh/known_hosts against that host and port.

Because host and port pairs are recycled as instances come and go, you will eventually connect to a new instance on a host and port you have used before, and OpenSSH refuses with REMOTE HOST IDENTIFICATION HAS CHANGED. Drop the stale entry and connect again:

ssh-keygen -R "[sh-us-tx-01.ssh.superheat.dev]:40123"

When your client offers the wrong key​

Password authentication is off; only the key attached at deploy time is in authorized_keys. If your agent holds several keys, OpenSSH may exhaust its attempts before it reaches the right one and you get Permission denied (publickey). Name the key explicitly:

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes -p 40123 root@sh-us-tx-01.ssh.superheat.dev

There is no way to attach a different key to an instance after it is deployed. Add the key you want under SSH Keys first, then deploy. See Add a key.

A host entry instead of a long command​

Host superheat
  HostName sh-us-tx-01.ssh.superheat.dev
  Port 40123
  User root
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

Then ssh superheat, scp -r ./data superheat:/workspace/, and so on. Update HostName and Port after a start.

Agent forwarding​

Forward your local agent when the instance needs to authenticate as you — cloning a private repository, for example — so no private key is ever written to the instance:

ssh -A -p 40123 root@sh-us-tx-01.ssh.superheat.dev

Or add ForwardAgent yes to the host entry above.

Agent forwarding lends out your keys

While the session is open, anything with root on that container can use your forwarded agent to authenticate as you anywhere your keys are accepted. Forward per connection, not globally, and prefer a repository-scoped deploy key for unattended work.

Getting data in and out​

scp takes the port as -P, uppercase, not the -p that ssh takes.

# push a dataset up
scp -P 40123 -r ./data root@sh-us-tx-01.ssh.superheat.dev:/workspace/data

# pull checkpoints back down
scp -P 40123 -r root@sh-us-tx-01.ssh.superheat.dev:/workspace/checkpoints ./checkpoints

rsync is installed in the Superheat base image and is the better choice for anything large or repeated, because -P resumes a partial transfer instead of starting over:

# up
rsync -avP -e "ssh -p 40123" ./data/ root@sh-us-tx-01.ssh.superheat.dev:/workspace/data/

# down
rsync -avP -e "ssh -p 40123" root@sh-us-tx-01.ssh.superheat.dev:/workspace/checkpoints/ ./checkpoints/

Trailing slashes matter to rsync: ./data/ copies the contents of data, ./data copies the directory itself.

Destroying deletes the disk

There is no snapshot and no undo. Copy anything you want to keep off the instance before you destroy it. See Stop vs destroy.