SSH keys

#Why a key is required

Password login is disabled on every image, and it cannot be turned on. A key is the only way in over SSH, so you need one before you create a machine.

If you lose a key, you are not locked out: give the machine another key from your account, or use the serial console, which works without SSH, the network or a security group.

#Create a key

1. Go to SSH keys and press Add SSH key. You can also do this from the SSH key section of the create form.
2. Name it after the computer you will connect from, usually you@machine (like ada@macbook-pro), so you know which one to remove if that laptop goes missing.
3. Press Generate a key.

We make the key pair for you. The private half downloads straight away as a .pem file named after the key, and the dialog stays open on Save your private key:

• Download again if the download did not land.
• Copy to clipboard if you would rather paste it into a file yourself.

This is the only copy. We never store the private key, and once you close the dialog it is gone. Anyone who holds it can sign in to every machine the key is on, so treat it like a password.

#Put it where ssh can use it

Move the file to ~/.ssh and make it readable only by you, because ssh refuses a key that other users can read:

$ mv ~/Downloads/ada-macbook-pro.pem ~/.ssh/$ chmod 600 ~/.ssh/ada-macbook-pro.pem

Then point ssh at it when you connect, as the image's login user:

$ ssh -i ~/.ssh/ada-macbook-pro.pem ubuntu@<ip-address>

#Which user to log in as

Each image has its own login user, and your key is added to that user. Log in as it, then use sudo for anything that needs root:

So on a Debian machine the command is ssh -i ~/.ssh/ada-macbook-pro.pem debian@<ip-address>. The Connect card on the machine's page shows the right command for its image, and pantech vm ssh picks the user for you.

To stop typing -i every time, add the machine to ~/.ssh/config:

Host web-03
  HostName <ip-address>
  User ubuntu    # debian on a Debian machine
  IdentityFile ~/.ssh/ada-macbook-pro.pem

After that, ssh web-03 is enough.

#Allow SSH in the security group

This applies to a standard VPS. A machine in a VPC subnet has no security group; its subnet's network ACL decides instead, as the next section explains.

A key is not enough on its own: the machine's security group must also let SSH in. If it has no inbound rule for port 22, the connection times out before your key is ever checked.

To add the rule:

1. Open the machine's security group under Firewalls and edit its inbound rules.
2. Add a rule and set Type to SSH. The protocol (TCP) and port (22) fill in for you.
3. Choose who may connect in the Source field (see the table below).
4. Save. The rule applies to every machine that uses the group within seconds.

The Source field decides who can reach port 22. Pick it by who needs to sign in:

Prefer My IP or Custom. Anywhere lets the whole internet try to sign in; your key makes password guessing useless, but scanners will still hammer port 22 and fill your logs. Narrow SSH without locking yourself out explains how to tighten a rule safely.

On an outbound rule the same field is called Destination. Outbound rules do not control who can SSH in to the machine; only the inbound Source does.

#Allow SSH in the network ACL (VPC)

A machine in a VPC is protected by its subnet's network ACL, and it applies to every machine in the subnet. A new subnet blocks every inbound connection except ping, so SSH times out before your key is ever checked until you allow it.

Open the subnet (from VPCs, open the VPC, then the subnet) or the machine's Networking tab, find Network ACL, and press Add rule:

The rule applies to every machine in the subnet within seconds.

Use Your IP or your office block as the source where you can. Anywhere lets the whole internet try to sign in, which is fine for a short test but a bad idea for a machine you keep. A key makes guessing a password useless, though scanners will still hammer port 22.

To reach the machine from outside the VPC it also needs a static IP. The platform's built-in outbound rule lets the replies out, which matters because network ACL rules are stateless.

#Change a machine's key

You can move a running machine to another key on your account, for example after losing the private key or when a laptop that held it goes missing. The machine restarts to take the new key, about two minutes of downtime.

1. Add the new key under SSH keys first, if it is not there yet.
2. Open the machine and go to its Settings tab. The SSH key card lists your keys, with the one the machine accepts marked Current.
3. Choose the new key and press Restart with key name.

The machine's status shows Changing key while it restarts. Once it is running again:

• the new key logs in, as the image's login user;
• the previous key no longer does;
• keys you added to ~/.ssh/authorized_keys on the server yourself keep working.

The machine must be running. Start a stopped machine first. The same change is available in the API as POST /instances/{id}/change-ssh-key, and in Terraform by changing ssh_key_id on pantechdynamics_instance, which updates the machine in place instead of replacing it.

Adding a key to your account does not put it on any machine by itself. To give a machine an extra key while keeping the current one, sign in with a key it already trusts and append the public key to ~/.ssh/authorized_keys yourself.

#Remove a key

Open the key's ⋯ menu on SSH keys and choose Remove.

Removing a key stops it being put on machines you create from now on. It does not remove it from machines that are already running. Anything that trusts the key goes on trusting it. If you are removing a key because the private half may have leaked, first change the key on every machine that uses it, or delete it from ~/.ssh/authorized_keys on each one yourself.