SSH keys

Register SSH public keys in the console so you can shell into your own GPU instances.

To connect to a GPU instance over SSH from your own terminal, register your public key under Account → SSH Keys first. Registered keys are injected into instances you launch, so ssh works without a password.

What SSH keys protect

SSH keys gate direct shell access to a running instance — the box itself, not your account or any console feature. That makes them the right tool for GPU instances where you need a root shell for training runs, custom stacks, or debugging. For naming a credential behind a console integration, see API keys; for protecting your account login, see 2FA.

Add only the public half of a keypair (for example the contents of ~/.ssh/id_ed25519.pub). NevTan never sees or stores your private key.

Why the public/private split matters

Only ever paste the public key into the console. The private key is what actually proves your identity to the instance, and it should never leave the machine it was generated on. Because NevTan only ever holds the public half, there's nothing on NevTan's side that, if exposed, would let someone impersonate you over SSH — the sensitive half of the pair stays on your laptop, in your ~/.ssh directory, for the whole lifetime of the key.

Add a key

1. 1
   Open Account → SSH Keys

   Click Add key to open the registration form.
2. 2
   Paste your public key

   Give it a name and paste the full public key line generated on your own machine.
3. 3
   Launch or reconnect

   The key is injected into any GPU instance you launch afterward — no password needed to ssh in.

List and delete

The console lists all your registered keys. Remove one when a device is retired — this stops it from being injected into new instances, though instances that already have it keep working until they're replaced.

• One key per device. Register a separate key for each laptop or CI runner instead of sharing one keypair, so losing a device only means revoking one key.
• Rotate on device change. Add the new key first, confirm it works on a fresh instance, then remove the old one.
• Remove promptly on offboarding. If a device is lost or a teammate leaves, delete the associated key immediately — it stops future instances from trusting it.

What a lost device means in practice

Losing a laptop that had a registered key on it is a narrower problem than a leaked password or API key, because the private key never touched NevTan and — if the disk is encrypted — is not trivially usable by whoever has the device. Still, treat it as a live risk: delete the corresponding key from Account → SSH Keys as soon as you notice, so it's no longer injected into anything you launch afterward. Any instance that already had the old key baked in continues trusting it until that instance is replaced — the removal only changes what happens going forward, not instances already running.