0.2 SSH, key pairs and remote access

What this is and why it exists

A cloud server has no keyboard attached to it. SSH is how you reach it, and a key pair is how it knows you. This is also the first place on the course where you hold a secret whose loss has a real cost, so the lesson is half mechanism and half hygiene — and the hygiene half is the part people skip and then pay for.

The vocabulary

• Key pair — two matched files generated together: a private key you keep and a public key you hand out.
• Private key — the half that proves who you are; it never leaves your machine and is never sent anywhere, not even to the server.
• Public key — the half you copy onto every server that should let you in; it can prove nothing by itself, so publishing it costs you nothing.
• Passphrase — an optional password encrypting the private key file, so a stolen laptop is not a stolen identity.
• authorized_keys — the file on the server listing the public keys allowed to log in as that user.
• known_hosts — the file on your machine remembering each server's own key, so you notice if a server is replaced by an impostor.
• Rotation — replacing a key on purpose and on a schedule, rather than in a panic.

The mental model

Think of the public key as a lock you can mass-produce and the private key as the only key that opens any of them. You bolt copies of the lock onto every door you want to use — that is what a line in authorized_keys is — and you carry one key. Nothing secret travels: the server sends a challenge, your machine answers using the private key, and the private key stays where it is. That is why a password can be stolen in transit or from a server's storage and a private key cannot.

Trust runs both ways, which is the part beginners miss. The server checks you with your key; you check the server with its key. The first connection shows you a fingerprint and asks whether you accept it, and the manual says what happens then: "ssh automatically maintains and checks a database containing identification for all hosts it has ever been used with. Host keys are stored in ~/.ssh/known_hosts in the user's home directory." A later warning that a host key has changed is not a formality — it means the server was rebuilt, or something is sitting between you and it.

The last piece is what a lost key costs. There is no reset link. Lose it and you lose access to every server carrying its public half, and you get back in through whatever second route exists — the provider's console, a colleague. Decide that second route before you need it. A stolen key is the mirror image: you cannot un-publish it, only remove its line from every authorized_keys that has it. Both become survivable by rotating on purpose — new pair, add the new public key everywhere, confirm it works, remove the old line — while everything is calm.

Portable operations

Checked against the OpenSSH manuals, which are the reference for every mainstream Linux and macOS build.

ssh-keygen -t ed25519 -C "vithal-laptop-2026"
ssh you@203.0.113.10
ssh -i ~/.ssh/id_ed25519 you@203.0.113.10
scp -r ./site you@203.0.113.10:/var/www/

-t chooses the key type, and the manual lists ed25519 as the default variety; -C "provides a new comment", which is how you later tell four keys apart. The files land at ~/.ssh/id_ed25519 and ~/.ssh/id_ed25519.pub, and the tool "asks for a passphrase" — give it one, because an empty passphrase means anyone who copies the file is you. -i "selects a file from which the identity (private key) for public key authentication is read", needed only when the key is not in its default place. scp "copies files between hosts on a network" and writes a remote location "in the form [user@]host:[path]"; -r copies whole directories.

The config file removes the typing. The per-user file is ~/.ssh/config, which the manual says "must have strict permissions: read/write for the user, and not writable by others":

Host web
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/id_ed25519
  Port 22

Host restricts the following lines to hosts matching that pattern; HostName "specifies the real host name to log into"; User names the account; IdentityFile names the key; Port defaults to 22. After this, ssh web is the whole command — and the fewer characters a safe habit costs, the more often you keep it.

Why servers turn password login off. On the server, sshd_config carries PasswordAuthentication, whose default the manual gives as yes, and PubkeyAuthentication, also yes. A server on a public address receives automated login attempts from the day it exists; keys cannot be guessed, passwords can. So the standard hardening is to set password authentication to no once your key works — never before, or you lock yourself out — and to leave PermitRootLogin at its documented default of prohibit-password. Your public key belongs in the file named by AuthorizedKeysFile, whose default is .ssh/authorized_keys in the user's home directory.

What you should now be able to explain or do

Generate a pair and say which half goes where. Explain what crosses the wire during a login, and why no secret does. Read a host-key-changed warning and name the two possible causes. Write a five-line ~/.ssh/config entry from memory. State what you would do tomorrow if your laptop were stolen tonight — and what you should have done last month to make that answer shorter.

Check yourself