In our running example, the user pat is authenticated by the SSH server via login password. Passwords, however, have serious drawbacks:
In order for a password to be secure, it should be long and random, but such passwords are hard to memorize.
A password sent across the network, even protected by an SSH secure channel, can be captured when it arrives on the remote host if that host has been compromised.
Most operating systems support only a single password per account. For shared accounts (e.g., a superuser account), this presents difficulties:
Password changes are inconvenient because the new password must be communicated to all people with access to the account.
Tracking usage of the account becomes difficult because the operating system doesn’t distinguish between the different users of the account.
To address these problems, SSH supports public-key authentication: instead of relying on the password scheme of the host operating system, SSH may use cryptographic keys . [3.2.2] Keys are more secure than passwords in general and address all the weaknesses mentioned earlier.
A key is a digital identity. It’s a unique string of binary data that means “This is me, honestly, I swear.” And with a little cryptographic magic, your SSH client can prove to a server that its key is genuine, and you are really you.
An SSH identity uses a pair of keys, one private and one public. The private key is a closely guarded secret only ...