OpenSSH will now generate
more secure keys by default. Will this break your
workflow? [intro music starts] [music stops] Probably not. [intro music for real this time,
yes that's a real SID chip] Greetings, and welcome to a cryptographic-tastic
episode of Veronica Explains. I'm Veronica, and today I'm going
to cover a recent change to OpenSSH, and what it could mean for you. As of OpenSSH version 9.5, the `ssh-keygen`
program will generate keys using the Ed25519 algorithm by default, instead of the older,
slower, and often less secure RSA algorithm. This updated version of `ssh-keygen` just
rolled out to my Debian Sid installation, so it's certainly coming
to a distro near you soon. In a bit, I'll talk about the practical
implications of the change. But first, what do these encryption algorithms actually mean? This gets pretty complex, and
I'm certainly no cryptographer, so do your own research and make sure
to treat me well in the comments. What I'll say right away is that I've been
using these new keys myself for years, and they work fine. So, if you're fine with
defaults and working with modern systems, there's a really good chance that
this change won't impact you at all. And if you're working with older keys,
don't worry- you probably won't have to regenerate your existing keys in
order to keep connecting to servers. That said, I want to cover the specifics
of this, because there could be some edge cases that impact you, particularly if
you work in administration or devops. As I covered in my "OpenSSH
for absolute beginners" video, OpenSSH lets you connect to a
remote system in an encrypted way, and to increase security, the use
of keyfiles is strongly recommended. [yes, that's the Mario 64 painting sound] The `ssh-keygen` command creates a pair of files-
a public key, and a private key. The public key is then tied to the remote system, using a separate
program called `ssh-copy-id`. An algorithm on the remote server can compare a private key against
a public key to see if they're tied together. So, as long as you keep the private
key private, it can be used as proof of your identity, in a way that's much
harder to crack than simple passwords. Again, watch my other video if
you're completely new to this stuff. Anyway, the `ssh-keygen` program
uses various mathmatical algorithms to generate the pair of files
needed to complete this process. The former default that `ssh-keygen` used was RSA, which used an older mechanism
and results in larger files. Ed25519 on the other hand
is a much newer algorithm, which as I understand it uses something
called "Twisted Edwards curves" to more quickly generate more secure keys, which
are actually smaller than the old ones. You can see that here- on a
Sid box, I'll create a key, and as you can see, it creates
that key now as an Ed25519 key. Now over here, on my Linux Mint Debian Edition
laptop - which I'll be covering in a future video [awkward silence] ...when I cat out the RSA key,
you can see it's quite long. But when I cat out the Ed25519 key,
you can see that it's much shorter. And before you comment- don't worry,
these are not production keys, so I can share them knowing they're already
deleted by the time you see the video. I'll put the full commands I'm using
in the description as well. Anywho, thanks to the work of our
industry's cryptographers, we now have more secure keys which are actually smaller files and are generated faster than the
old ones. What's not to love about that? Luckily for most of us, Ed25519 has been
pretty well supported in most systems for a number of years, so chances are,
we'll all be just fine with this news, even if some of us have to take a few steps
to make sure our processes are up-to-date. "Oh no, am I going to have to do some work,
Veronica?" Probably not. But also, maybe! Well, first of all, if you aren't a
system administrator or developer, it probably doesn't impact you at all. If
you never remotely connect to a server or router resource, this probably has no bearing
whatsoever on your life. Thanks for watching. [kid shouting "1, 2, 3, 4!"] For everyone else, again, particularly
if you work in devops or administration, if you have scripts or playbooks or whatever
you might use in your build systems, you may want to have a look at any `ssh-keygen`
commands you're running, and if the remote systems or equipment requires RSA, you'll want
to make sure you get specific in your commands. Now, you might be thinking: "what requires RSA here in the roaring
2K20s?" Well, you'd be surprised. As a system administrator until recently, there were plenty of older systems which
actually did require RSA keys for connections. Network equipment comes to mind- often you'll
walk into a server room and see 10-15 year old infrastructure still plugging away, and you're
going to need to know how to connect with that. I worked in legacy systems, so there were
plenty of older OS build targets that we had to keep instructions for, and looking through
my notes, a few of them didn't play nicely with anything besides RSA. Admittedly,
that's a bit of an edge case though. Here's an example of an ancient
system for testing- I installed Ubuntu 8.04 on my classic HP netbook. This install predates Ed25519 keys, which I
can see because when I try to connect to it, it tells me it can only handle
older methods like RSA and DSS. Now, this alert isn't just about key types,
it's about all methods of ssh connection, including password based. But it's a pretty good
sign that this system is going to be trouble. And that's really the biggest impact this will
likely have on you as an administrator... if you know you need older-style RSA keys to
work with specific hardware or software, you may need to update any playbooks or
build instructions that use `ssh-keygen`. If your target can't be upgraded
to use Ed25519 keys, you'll want to append the appropriate keytype using the
`-t flag`, such as `-t rsa`, adding that to your `ssh-keygen` commands. Using that `-t` flag
will generate the type of key that your system needs. As always, if you want to learn more, the man
page is going to be your friend- `man ssh`, `man ssh-keygen`, and `man sshd`
are going to be helpful here. Here's the thing- if you mainly work
with up-to-date systems from the last couple of years, you're probably going to be OK. And again, like I said at the top, there's
no reason to suspect your existing keys won't continue to work just fine. Just be prepared for
more secure keys the next time you generate them. Of course, even if you aren't directly impacted, this isn't a bad time to go
through your keys and update them. I like to go through my key lists in the .ssh
folder periodically and make sure I've pruned the old and backed up the current. If you
haven't regenerated your keys recently, now might be a good time to beef up your security. After all, I never like leaving
old keys around for too long. As I showed before, you can quickly tell
what type of key you're creating by default, simply by typing `ssh-keygen`
without any parameters. If it says "generating public/private
rsa key pair.", note the `rsa` here, then you're on an older version. You
can always press Ctrl-C to bomb out, and then run it again with the `-t ed25519`
option to generate the more modern pair of keys. I personally prefer to maintain
different keys for each server, and I keep an extensive config file that points to
the ones that I need. If you want to learn more about the config file, my OpenSSH video from
a couple of years ago is still pretty good. One of the things I love about the Linux and
open source ecosystem is the fantastic group of researchers building more secure
ways for all of us to stay connected. But that shouldn't surprise anyone,
because Linux is awesome! And so are you. And now for a new segment I'm
calling "What I'm Watching", where I shout out another creator's video. [child shouting "1, 2, 3, 4!"]
[punk music starts] Today, I'd like to shout out
Macintosh Librarian's recent exploration of a Power Computing
Macintosh Clone from the 1990s. Macintosh Librarian is one of
my favorite channels. She does these fun explorations of vintage Apple and
Apple-adjacent equipment and software, and I've learned quite a bit about
our shared computing history from her. Plus, her pal Maccy is a gem.
Seriously, you've gotta go check out her channel. [punk guitar outro, yes I made this] "Oh no! Am I going to have to do some work, Veronica?"
