SSH & Keys
Log in to other machines without passwords, read every refusal ssh can give you, and harden sshd without locking yourself out.
An interactive Linux lesson: 25 steps, about 35 minutes, on a live simulation in your browser.
You are alice on web01. A second web server, web02, needs a look, and nobody walks to a server. ssh alice@web02 connects to the SSH daemon (sshd, listening on TCP port 22 of web02) and asks it for a shell as the user alice.
Read the output from the bottom. The prompt now says alice@web02: every command you type runs on web02 until you exit. hostname confirms it. Everything in between travels encrypted, so nobody on the network can read your keystrokes or the replies.
What you will learn
A shell on another machine
- A shell on another machine: ssh gives you a shell on another machine through an encrypted connection. The prompt tells you which machine your keystrokes go to.
- The question on first contact: The server proves its identity first, with its host key. known_hosts is the list of keys you have accepted: trust on first use, verify every time after.
- A server that takes no passwords: The words in parentheses after Permission denied are the methods the server would still accept. (publickey) alone means: no key, no entry.
Key pairs
- Generate a key pair: The private key stays with you and is never sent anywhere. The public key is a padlock: hand out as many copies as you like.
- Two halves, one secret: A key login is a signature check: the server holds the public key, your client proves it holds the private one. No secret is transmitted.
- Install the public key: ssh-copy-id: authorized_keys lives in an account's home on the server and lists the public keys allowed to log in as that account, one per line.
- ssh-copy-id on a keys-only server
- Install the public key by hand
- Drill: authorise a colleague's key
The modes ssh insists on
- Break it: a private key others can read: ssh will not use a private key that anyone but its owner can read. Mode 600, or the key is ignored.
- The same broken key, a softer server
- The server checks modes too: Both ends check modes. Client: the private key must be readable by you alone. Server: nobody else may write your home, ~/.ssh or authorized_keys.
When ssh says no
- Mystery: the key that worked a minute ago: In ssh -v, find three lines: Connection established, Offering public key, and then either Server accepts key or the list of methods again.
- Four questions, in order: Permission denied means you reached sshd and it said no. Any message about connecting means you never got that far.
- The host key changed: A changed host key means reinstalled or impersonated. Find out which before you delete the old line, and never switch the check off.
Config, copies and tunnels
- ~/.ssh/config: names for long commands: ~/.ssh/config turns a long command into a name. Everything built on ssh (scp, rsync, git) reads the same file.
- Copy files with scp: scp SOURCE DEST: the side with host: in it is remote. No colon, no network: you made a local copy.
- Drill: fetch a file
- The agent, and hopping through a host: The agent signs on request and never hands the key out. To go through a host, prefer -J: the middle machine carries bytes and holds nothing of yours.
- A tunnel: reach a port through ssh: -L A:host:B means: listen on my port A, and deliver what arrives there to host:B as seen from the server I logged in to.
Hardening sshd
- Who is knocking on port 22: Passwords can be guessed and keys cannot. A server where every user has a key should not accept passwords at all.
- Passwords off, tested before it is live: sshd -t, reload, log in again from a second terminal, and only then close the first one.
- Break it: restart with a broken config: A running sshd with an old config beats a stopped sshd with a broken one. Test, and keep a session open until a new login works.
Recap & playground
- Cheat sheet
- Playground