At work we're migrating from CentOS7 to Alma Linux 9. As part of that we are separating out some pieces of our infrastructure and generally cleaning up cruft. To separate out parts of our infrastructure we are going to setup a new build server at a cloud provider. So, we'll need to migrate some of our SSH infrastructure to get everything working.
I was working on a plan for the migration with Rob and we were going over the SSH bits. Every time I need to setup SSH, which I've done quite a few times, I forget the different keys and what each one does. What is known hosts? What goes in authorized keys? Where is the public and private key? I'm embarassed to even be writing that out. It isn't very complicated. But whatever the cache invalidation strategy is in my head it keeps removing SSH knowledge before the next time I need it. So, this is a very basic article of the bare minimum of knowledge needed to work with SSH keys. Hopefully I can at least remember I wrote this article and refer back to it next time I need this information.
Public/Private Keypair
When people say "SSH keys" this is usually what they are reffereing to. The keys clients use to authenticate.
Private Key (ex. ~/.ssh/id_<algo>)
The private key lives on a client's machine and is usually protected by a password. This key is a secret. It is able to decrypt messages encrypted by the public key.
Public Key (ex .~/.ssh/id_<algo>.pub)
This key lives on the server one wants to authenticate with. It is not a secret.
Other words to remember:
- public key authentication: Another way to describe this auth
mechanism.
- Assymetric encryption: One half public and one half private.
Authorized keys (~/.ssh/authorized_keys)
This file contains the public keys of all clients that can authenticate with that user/server (they live under a users $HOME).
Host Keys (ex. /etc/ssh/ssh_host_<algo> and /etc/ssh/ssh_host_<algo>.pub)
The host key identifies a server. It should be unique to every server.
When setting up an SSH connection the server exchanges this key with
the client. The client validates this key against the fingerprint it
has for it in ~/.ssh/known_hosts. If it is different the user is
notified. If it is the first time the client is connecting then the
user must have some alternate means of validating that the key is correct.
Known hosts (ex. ~/.ssh/known_hosts)
Contains a fingerprint of the public keys of all hosts the client has authenticated with.
There is also an ip/hostname that is stored/checked (maybe).
Baisc steps of setting up an SSH connection
- Sever and client negotiate encryption for the session and setup symmetric encryption keys they will use to secure the conneciton.
- As part of step 1 the server provides it's public host key which the client checks against known_hosts.
- The server and client then do a dance using the ssh keys, authorized_keys, and session key to authenticate the client.
- Use the encrypted tunnel!