Setting Up SSH Key Authentication: 2024 Edition

A recent project I worked on required setting up more SSH key authentication, and seeing as how I'd not written about it for two years since the last iteration, it seems fitting to do another quick primer on setting that up for SSH...the 2024 edition.

My previous posts from summer 2020 and winter 2022 are still relevant and accurate, but if you're already familiar with the concepts this quick post provides the commands and info to get set up and running.

First Step: Generate an Ed25519 Key Pair

It still works to use the old RSA algorithm, but newer algorithms like Ed25519 are widely supported nowadays and way easier to work with after the fact. To generate an Ed25519 key pair, run a command like this on the origin host:

ssh-keygen -a 100 -t ed25519 -f ~/.ssh/id_ed25519 -C "[my origin host name]"

Over the years I've discovered that it is especially important to use the comment for the key. It might seem trivial in the moment, but Future You will appreciate knowing where this key originated or whatever you want to put in to the comment. It doesn't even necessarily need to be consistent, but something that will make sense or jog your memory.

Second Step: Distribute the Key

Years ago I used to do a manual copy of the .pub key to hosts, then cat to the authorized_keys file. That method still works, but if you have direct access to the remote host, use the ssh-copy-id command. This is automatically available with installations of OpenSSH and handles all of the permissions and key authorization business, so if you're using this on any Linux distro (including WSL), it's already available:

ssh-copy-id -i .ssh/id_ed25519 username@remote-host.box

You'll need to authenticate with a password (or other mechanism) to complete the process, but once it's done...

Third Step: Connect to Remote Host

If ssh-copy-id was successful, the next step is simply to give it a try!

ssh username@remote-host.box

That's it. Those are the steps!

Maintenance and Good Practice Reminders

First off, clean up the old stuff once in a while. We're all guilty of it, but that's where the comment flag for new keys comes in super handy. Review that authorized_keys list when you make changes or add something. Clean up stuff that is no longer relevant or should no longer be there. Most keys will live "forever" and might outlast folks with access to a given host.

I like to use aliases for my frequent host connections, and what I wrote about creating aliases (at the end of the post) still works well and saves a few keystrokes (probably).

If you have the need to specify distinct keys for certain hosts (especially if you use different usernames for those connections), the bit I wrote about setting up the SSH config file (at the end of the post) is relevant and useful.

Rotate and keep track of those keys! Your mileage may vary, but if you're heavily vested with key authentication it's worth considering a way to keep track of keys and rotating them once in a while. It can be a bit of a pain in the moment and seem like overkill, but it's a good practice to follow. I personally like to rotate out keys when I start using a new device with frequency as it's a natural time to look at the remote hosts to see where I'd been intending to or actively connecting from.

As I've said many times before: key auth is awesome and you should be using it! Good luck!