Troubleshoot connecting to a VM

Retrieve the SSH command for a VM in the Connect section of its Overview tab:

ssh <vm-handle>@ssh.run.openrelay.inc

Common causes for connection failures

• The VM is not running, or its handle is misspelled. The gateway answers No running VM found for "<vm-handle>". and closes the connection.
• The offered SSH key is not attached to the VM.
• The client offers so many other keys that the gateway ends the connection before it reaches the attached one.

Error: No running VM found for "<vm-handle>".

The handle in your command matches no running VM, so the gateway prints this and closes the connection before any key is tried. Two things produce it.

Check that the VM is running

On the VM's Overview tab, the status must be Running and SSH in the Connect section must show Live.

Check the command

Confirm the command matches what is presented in the Connect section. Use the copy button to avoid typos.

Error: Permission denied (publickey)

The VM is running and its handle is right, and the gateway accepted none of the keys your client offered.

Check that you are connecting with a key attached to the VM

List the identity files your client will offer for this connection:

ssh -G <vm-handle>@ssh.run.openrelay.inc | grep -i identityfile

Without -i or an ssh_config entry, OpenSSH offers only the default identity files that ssh -G lists and that exist on disk, plus any keys loaded in your agent.

Confirm which keys were offered on a connection attempt:

ssh -v <vm-handle>@ssh.run.openrelay.inc 2>&1 | grep -E "Offering public key|Server accepts key|Authenticated to"

Each Offering public key line carries the fingerprint of a key your client sent. Server accepts key means the gateway recognized that key as attached to the VM, and Authenticated to ssh.run.openrelay.inc confirms the session.

Check the private key fingerprint matches an attached key

Run ssh-keygen against the private key file:

ssh-keygen -lf <path-to-private-key>

Compare the SHA256:... value with the fingerprints listed under the VM's Settings tab, where the keys attached to this VM are checked.

Authenticating with the correct key

If the attached key was not offered, specify it with -i:

ssh -i <path-to-private-key> -o IdentitiesOnly=yes <vm-handle>@ssh.run.openrelay.inc

IdentitiesOnly=yes stops the client offering agent keys ahead of that one. The gateway ends a connection with too many authentication failures after six rejected keys, so a loaded agent can use up the attempts first.

Or add an entry per VM to ~/.ssh/config and connect with ssh <alias>:

Host <custom-alias>
  HostName ssh.run.openrelay.inc
  User <vm-handle>
  IdentityFile <path-to-private-key>
  IdentitiesOnly yes

Then connect with

ssh <custom-alias>

Attaching the required key

If the expected key is not attached to the VM, attach it on the VM's Settings tab, or with the CLI. Registering a key on the organization is not enough on its own: the gateway accepts only the keys attached to this VM.

orl ssh-keys create \
  --name <name> \
  --public-key "$(cat <path-to-public-key>)"

orl vms ssh-key attach <vm-id> --ssh-key-id <ssh-key-id>

orl ssh-keys list prints the key ids. orl vms ssh-key get <vm-id> lists the keys attached to the VM.

Host key

ssh.run.openrelay.inc presents one ED25519 host key:

SHA256:Y5ODA2RGr1dccK+FuGZTkeWjuMjxoPklDro7sgrPv+g

Verify it before accepting on first connection:

ssh-keyscan ssh.run.openrelay.inc | ssh-keygen -lf -

Windows

OpenSSH ships with Windows 10 and 11, so ssh, ssh-keygen and ssh-keyscan run in PowerShell. Stock PowerShell has no grep: pipe to Select-String with the same pattern instead. It does not continue a line on \ either, so run the orl ssh-keys create command on one line. Keys, config and known_hosts live in C:\Users\<username>\.ssh\. PuTTY .ppk files are not OpenSSH keys: export the key with PuTTYgen (Conversions > Export OpenSSH key) before passing it to ssh -i.

Contact support

If the steps above do not resolve the problem, contact support with:

1. The output of ssh -v <vm-handle>@ssh.run.openrelay.inc.
2. The fingerprint of the key you are using, from ssh-keygen -lf <path-to-private-key>.

Never send or share your private key with anybody.