GoKawiilWhen I ssh into a server for the first time, I’m confronted with a dialog which asks me to verify I’m actually talking to the machine I expect to be talking to.
$ ssh -l jane 192.0.2.65 The authenticity of host '192.0.2.65 (192.0.2.65)' can't be established. ED25519 key fingerprint is SHA256:4WTRnq2OR1m03TpnHCfkFdlh1gN/PBXE4vDi0WnjFEc. No matching host key fingerprint found in DNS. This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])?
It is likely that the majority of users cross their fingers and type ‘yes’, which is not really a clever response. This Trust on First Use (TOFU) is what permits SSH to ensure that my SSH client verifies which server it’s talking to. I ought to have asked the administrator of the server to tell me its fingerprint, and if I am the administrator I ought to know how to do this: (in the following examples, a shell prompt % indicates I’m working as `root)
% ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key 256 SHA256:4WTRnq2OR1m03TpnHCfkFdlh1gN/PBXE4vDi0WnjFEc root@d13 (ED25519)
If the two fingerprints compare equal, I can trust that I am connecting to the correct server and can continue with ‘yes’ or I paste a known host fingerprint into the prompt: trust on first use is accomplished. (Utilities such as ssh-keyscan gather public keys from remote hosts, but I still ought to verify out-of-band whether I’m talking to the correct machine. SSH fingerprints can also be in the DNS, what can’t?, but that’s a different story.)
The session then possibly continues with me being asked for the target user’s password which, if entered correctly, grants me access to the machine.
SSH key pairs
If I create an SSH key pair, install my public key in the correct location (typically $HOME/.ssh/authorized_keys on the target node), and present the private key upon connection, then I don’t need to type the target user’s password; instead I enter the key’s passphrase, a hopefully much more complicated combination of words, to unlock the private key. I say “hopefully”, because this passphrase is what encrypts the private key so that it cannot be used without it. (Note that I typically generate keys with a comment in them so as to more easily keep track of them ( -C ), and specify which file ( -f ) they should be written to. The comment can be read from the public key file and will later be visible in the SSH agent.)
$ ssh-keygen -t ecdsa -C "JP's demo key" -f demokey Generating public/private ecdsa key pair. Enter passphrase for "demokey" (empty for no passphrase): Enter same passphrase again: Your identification has been saved in demokey Your public key has been saved in demokey.pub $ ssh-copy-id -i demokey.pub [email protected] /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "demokey.pub" /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys [email protected]'s password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh -i ./demokey '[email protected]'" and check to make sure that only the key(s) you wanted were added. $ ssh -i demokey [email protected] Enter passphrase for key 'demokey': jane@node:~$
The private SSH key still needs unlocking on use because I set a passphrase on it when creating it.
... continue reading