SSH login

First principles

SSH authentication is a proof. For key login, the server looks up your account's authorized_keys file. Each line is a public key. The client must prove it holds the matching private key. The private key never crosses the wire. A challenge goes out; a signature comes back; the server checks it against the line it already stored.

Password authentication is a different proof: you type a secret the server can verify. Anyone who learns that secret is you, from any client. Key authentication requires possession of a file. Steal the password and you are in. Steal nothing of the file and you are not.

What the server must already have

The public line belongs in the remote account's ~/.ssh/authorized_keys, mode 600, directory ~/.ssh mode 700. One line per key. Comment field at the end is for you, not for the protocol.

Install the public file from a session you already control: a console, a cloud serial, an existing login. Append. Do not replace a working authorized_keys unless you mean to.

Log in

macOS Terminal, Linux, Windows OpenSSH — same client:

ssh you@host.example
ssh you@host.example -i ~/.ssh/id_ed25519
ssh you@host.example -i ~/.ssh/id_ed25519_admin

Use -i when the key is not the default id_ed25519 / id_rsa. On Windows the path is %USERPROFILE%\.ssh\id_ed25519. The first successful key login is the moment you know the lock is on the door.

Disable passwords only after a key works

sshd can refuse password authentication. Do that after you have logged in with a key, from a second window, while the first session is still open. If you flip PasswordAuthentication to no before a key login has succeeded, you own a box you cannot enter. Keep an out-of-band console until the next key login works.

Root login with a password should already be off. Root login with a named key is a separate decision. Prefer a named user and a logged sudo.