SSH and Keys

A key pair is two matching files, made together:

$ ssh-keygen -t ed25519 -C "jonah@laptop"
$ ls ~/.ssh
config  id_ed25519  id_ed25519.pub

The one ending .pub is the public key. You hand it out, paste it into tickets, copy it to servers. The other one is the private key, and it never leaves the machine it was made on. Nothing you do should ever send it anywhere, and a server never needs it.

Logging in works because the server can set a puzzle only the private key can answer, without the private key ever crossing the network. That's the whole reason keys beat passwords: a password has to be sent to be checked, and anything you send can be captured.

The server side is one file, ~/.ssh/authorized_keys in the account you're logging into. Every public key listed there may log in as that account. Nothing else is needed, and nothing else is checked, which is exactly why an unexpected line in that file matters so much.

A line can also be fenced in, by putting options in front of the key:

restrict,command="/usr/local/bin/handover" ssh-ed25519 AAAAC3Nza... jonah@laptop

Now that key can do one thing. Whatever the person asks to run, sshd ignores it and runs the named command instead, and restrict turns off everything else a session could ask for: no terminal, no port forwarding, no agent forwarding. Backups, deploys and file drops are given keys like this so an automated job can do its one task and nothing more.

Two last details, both of which will bite you:

ssh enforces these rather than warning about them: it refuses to use a private key that other people on the machine can read, and sshd ignores an authorized_keys that anyone but its owner can write.

And ssh checks the server's identity too. The first connection asks you to accept its host key and remembers it in ~/.ssh/known_hosts; if it ever changes, ssh refuses loudly rather than quietly connecting to whatever is now answering.

The command is ssh user@host, and -i picks which key to offer:

$ ssh courier@localhost
$ ssh -i ~/.ssh/courier_key courier@localhost
$ ssh -i ~/.ssh/courier_key courier@localhost 'uptime'

Put a command on the end and ssh runs just that and comes straight back, which is how scripts use it.

Typing all that every time gets old, so ~/.ssh/config names the details once:

Host courier
  HostName localhost
  User courier
  IdentityFile ~/.ssh/courier_key

Now ssh courier is enough. The Host line is a label you invent, not a hostname, and reading somebody's ~/.ssh/config is one of the faster ways to learn which machines they work on.

When a connection is refused, work down the layers rather than guessing. ssh: connect to host ... port 22: Connection refused means nothing is listening, so the problem is the server, not your key. Permission denied (publickey) means sshd is running and didn't accept what you offered, which is a question about authorized_keys or which key you sent. ssh -v prints the keys it tried, in order, and is usually quicker than thinking about it.

The person Jonah is replacing left a handover note in the courier account. He can't log into it and can't read its home folder, but he was given a key.

1. Press Launch in CybRange at the top of this page, then Open terminal next to box once it's ready. You're logged in as jonah.
2. Read ~/todo.txt, then look at what you were given: ls -l ~/.ssh and cat ~/.ssh/config.
3. Try it the direct way first: cat /home/courier/handover.txt. It fails, and ls -ld /home/courier says why.
4. Connect with the key. The config file means ssh courier is enough.
5. You'll notice you don't get a shell. Try ssh courier 'id' and see what comes back instead, then work out from the first task where that behaviour is written down.