Password authentication over an encrypted channel is safe from interception and vulnerable to everything else, including guessing, reuse, and the fact that the password must be typed into whatever prompts for it.
Key authentication removes those problems and introduces different ones, mainly around where the private key lives and who can use it.
What actually happens with a key
The private key never leaves the client. The server sends a challenge, the client signs it, and the server verifies the signature against the public key it holds.
A compromised server therefore learns nothing usable, which is the substantive advantage over a password. It received a signature over a value it chose, and cannot replay it anywhere else.
Choosing a key type
| Type | Status | Notes |
|---|---|---|
| ed25519 | Preferred | Short, fast, no parameter choices to get wrong |
| ecdsa | Acceptable | Depends on curve selection |
| rsa | Acceptable at 3072 bits or more | Widest compatibility, larger keys |
| dsa | Obsolete | Disabled by default in current versions |
Passphrase protecting the private key is what makes a stolen laptop survivable, since the file alone is useless. The agent is what makes that tolerable, holding the decrypted key in memory so the passphrase is entered once per session.
Host verification is the part people skip
The warning on first connection asks whether the server presenting itself is the one intended. Accepting it stores the host key, and every later connection is checked against that record.
The warning that a host key has changed means either the server was rebuilt or something is intercepting the connection, and those are not distinguishable from the client. Deleting the stored entry to make the warning go away discards the only protection against interception the protocol offers.
The configuration file does the real work
Per host entries in the client configuration remove almost all repetition. A short alias can carry the hostname, port, username, and key, so a long command becomes a single word.
It also supports patterns and defaults, which means common settings are written once. This matters beyond convenience, because settings typed by hand are eventually typed wrongly, and settings in a file are applied consistently.
Reaching hosts through a jump host
Where a target is only reachable through an intermediate machine, the client can establish the connection through it directly, without the private key ever being present on the intermediate.
This is the correct pattern for bastion access, and it replaces the older practice of copying keys onto the jump host or forwarding the agent to it. Agent forwarding allows anyone with sufficient privilege on that machine to use the key while the session is open, which is exactly the exposure the arrangement was meant to prevent.
Hardening the server side
Disabling password authentication once keys are working removes guessing entirely. Disabling direct administrative login forces an audited path through a normal account.
Restricting which users or groups may connect is more effective than changing the listening port, which reduces log noise without deterring anything deliberate. Where keys are used for automation, restricting what a key may do on the server bounds the damage if it is stolen.
Note: permissions on the client are enforced strictly and silently. A private key or directory readable by others causes the client to refuse the key without a clear explanation, which is one of the most common reasons key authentication appears to be ignored.