SSH login

The server already has your public line in authorized_keys. The client proves it still holds the matching private file. The private key never crosses the wire: a challenge goes out, a signature comes back. Password authentication is a shared secret from any client. Key authentication is possession of the file. Turn password login off only after a key login already works.

First principles

Password authentication is a different proof: you type a secret the server can verify. Anyone who learns that secret is you, from any client. 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.