Complete SSH Key Guide for GPU Cloud

Create, protect, register, use, rotate, and revoke SSH keys for remote GPU instances.

By Hostnot GPU · 9/6/2026

An SSH key pair proves your identity to a remote account. Your public key can be registered with a service; your private key must stay on your own device. The server's host key is a different key: it proves which server you reached. A successful login needs both checks.

Prepare a key on your own computer

These commands use a Linux, macOS, or WSL shell with OpenSSH. Run ssh -V first. Native Windows OpenSSH uses Windows file ACLs rather than these Unix permissions. Use a separate key for this environment so revocation does not disrupt unrelated systems. Check the proposed filename and decline any overwrite prompt if a key already exists.

umask 077
mkdir -p "$HOME/.ssh"
chmod 700 "$HOME/.ssh"
ssh-keygen -t ed25519 -a 64 -f "$HOME/.ssh/hostnotgpu_ed25519" -C "gpu-access"
chmod 600 "$HOME/.ssh/hostnotgpu_ed25519"
ssh-keygen -lf "$HOME/.ssh/hostnotgpu_ed25519.pub" -E sha256

Enter a strong passphrase at the prompt; do not put it in a command argument. Ed25519 is appropriate where the client, server, and organizational crypto policy support it. If policy requires another algorithm, use the approved alternative rather than enabling obsolete signatures. The fingerprint command prints a SHA256 identifier, not the secret key.

Register only the public half

Open the file ending in .pub in a local editor and copy its complete single line into the authenticated workspace's SSH-key control. A public key begins with an algorithm such as ssh-ed25519; a file beginning -----BEGIN OPENSSH PRIVATE KEY----- must never be uploaded. Confirm which key is associated with the instance. Do not assume a later account-key change is automatically pushed into already running instances.

Select the identity and verify the server

Set the following variables to the current connection details displayed for your ready instance. They are placeholders, not a fixed platform endpoint.

GPU_HOST='replace-with-assigned-host'
GPU_PORT='replace-with-assigned-port'
GPU_USER='replace-with-assigned-user'
ssh -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -i "$HOME/.ssh/hostnotgpu_ed25519" -p "$GPU_PORT" "$GPU_USER@$GPU_HOST"

Compare the first-connection fingerprint with the trusted workspace information for that instance before accepting it. Your public-key fingerprint from the earlier command will not match the server fingerprint: they identify different keys. An unverified ssh-keyscan result is not independent proof of server identity.

Use an agent without sharing its authority

If your desktop already provides an SSH agent, ssh-add -t 1h ~/.ssh/hostnotgpu_ed25519 caches the unlocked identity for one hour; ssh-add -l lists loaded fingerprints. This avoids repeated passphrase entry. Agent expiry does not revoke the public key on a server. Avoid agent forwarding (-A) to rented hosts because a compromised remote account could use the forwarded agent while connected.

Rotate, revoke, and recover

Create a replacement under a new filename and register it through the supported workflow.
Keep a working session open and test the replacement in a separate session, with its exact identity selected.
Remove the old authorization from every account and running host that trusts it; confirm the propagation behavior with support. Removing a dashboard entry alone may not revoke a copied authorized_keys entry.
If a private key leaked, prioritize revocation and account review. Changing its passphrase does not invalidate a stolen copy. Review active sessions separately because removing a key does not terminate established sessions.

Lost keys or forgotten passphrases require a supported recovery path; there is no passphrase-recovery command. Keep encrypted backups according to your policy. Preparing access before renting compute avoids paid idle troubleshooting time. Next: connect and transfer files or diagnose a rejected login.