OpenSSH operations

## The two files, and which one is a secret `ssh-keygen -t ed25519 -C "alice@laptop"` produces exactly two files in `~/.ssh`: - `id_ed25519` — the **private** key. This is the secret. It stays on the machine you connect *from*. If it has a passphrase, the passphrase protects the file at rest; it is not sent anywhere. - `id_ed25519.pub` — the **public** key. A single line of text, safe to paste into a ticket, a wiki or a config repo. Authentication works by the client proving possession of the private key against the public key the server already holds. The server therefore only ever needs the `.pub` half. Copying the private key to the server is not "how it works" — it is a compromise of the key. ## What ssh-copy-id actually does `ssh-copy-id` is a shell script shipped with OpenSSH, not a protocol feature. It: 1. Works out which public key to install — from `ssh-agent` if one is loaded, otherwise the default identity files, or the one you named with `-i`. 2. Opens a normal SSH connection to the target using authentication that still works today (password, or an already-working key). 3. Creates `~/.ssh` on the remote side if needed, appends the public key as a new line to `~/.ssh/authorized_keys`, and fixes the modes. 4. Prints how many keys it added and tells you to try logging in. It is deliberately append-only: existing keys in the file are left alone, and it tries to skip a key that is already present. `authorized_keys` is a plain text file where **one line is one key**; a normal account can accumulate many, one per laptop or per automation client. ``` ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@server ssh deploy@server 'wc -l ~/.ssh/authorized_keys' ``` ## Doing it by hand when ssh-copy-id is absent Minimal images and some appliances do not ship the script. The manual equivalent is one pipeline, and getting the directory mode right in the same command is the part people forget: ``` cat ~/.ssh/id_ed25519.pub | ssh deploy@server \ 'install -d -m 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys' ``` Note `>>`, not `>`. A single `>` silently destroys every other key in the file, which on a shared jump host is an outage. ## The account, not the host, is the unit Authorised keys are per-account. `~/.ssh/authorized_keys` for `deploy` is a different file from the one for `root` or for `alice`. "I copied my key to that box" is not a complete statement — you copied it to one account on that box. Interviewers often probe this with a scenario where key login works for one user and fails for another on the same server. ## Verifying, and telling keys apart The trailing comment on a public-key line (`alice@laptop`, whatever you passed to `-C`) is free text and is the usual way humans label keys; it is not authenticated and can be edited, so treat it as a label, not an identity. To match a line in `authorized_keys` against a key you hold, compare fingerprints: ``` ssh-keygen -lf ~/.ssh/id_ed25519.pub ``` That prints the size, the `SHA256:` fingerprint and the comment. The server logs the same fingerprint when it accepts a login, which is how you find out *which* of five keys a given session used. ## The failure right after this step The classic sequence is: `ssh-copy-id` reports success, and the next login still asks for a password. Two causes dominate. First, the key went to a different account than the one you are now logging in as. Second, the permissions on the remote home directory, `~/.ssh` or `authorized_keys` are too loose, and the server ignores the file — sshd runs with `StrictModes yes` by default and refuses to trust a key file that other users could edit. `ssh-copy-id` sets safe modes on what it creates, but it cannot fix a home directory that was already group-writable. Finally, a key that is in place but never offered is a *client-side* problem: with several keys present, the client offers them in order and a server may cut the attempt off after too many failures, which is why naming the identity explicitly during triage is useful.