I try to replace mine every two years or so. Sometimes with dev/play servers I let them go a little longer, but those usually aren't even on most of the time when not in use!
Oooo, I don't see that in their last whitepaper I read. Is this new? (Note, any link you share here might get auto-blocked but I'll hopefully see it, vet it, and then allow it through.)
@@Johan.Molenberghs I'd think that this would only be necessary if you have really bad security hygiene; dropping your keys onto every machine that you touch. If you manage your keys well I can't see how changing them like you change your underpants actually helps. (1 to 12 months: yes, I'm a dirty old man :)
I mean, I guess? It's basically, "Here, I'm going to hand you this lock so that the next time we meet, you'll know it's me, because I'm the only one who can unlock it."
That is why i love MikroTik network equipment. even after over twenty years their switches and APs still get firmware updates to support the newest tech.
Love SSH... fast, secure, can do file transfers easily multiple ways... and can trivially be centrally managed with a key server. That might be an idea for a vid too: Key servers. Edited to add: I mean e.g. LDAP vs universal key managers vs simple inotify to copy pub keys to servers that kind of thing. More than one way to skin SSH. :)
Uhm no. The whole point of the SSH key system is to easily create and distribute keys. The ed25519 keys are short so they are perfect, Look into ssh-copy-id. There is probably a manpage. You can just publish those keys pretty much anywhere. Hey, you could piggyback them on the GnuPG keyservers as a comment.
Damn, pitching out other channels is great! but also adding those in the description as well is a sign you are the best!! This channel is pure gold. The topics you cover are not my everyday needs but the most useful when I'm in trouble, which would be my everyday if not for you. Also the script is clear and well delivered, good amounts of comedy and plenty of well researched information distilled with great filmmaking and awesome animations. In any case, I'll recommend this channel as an example of how to do things properly. Even the captions are corrected! Great effort, great results. Thanks for sharing.
Great news. I am happy about the change. The length of the public keys make a practical difference. The new keys fit on one line, and are easy to copy and paste.
One thing that might be cool to cover in the future is SSH certificates. They're built in to OpenSSH, with commands for managing them built in to ssh-keygen. But they're useful because they allow you to essentially create auto-trusted, but auto-expiring keys for any user on the system. You can limit the authorization for the certificate to specific dates/times, specific users, even specific uses of SSH. One benefit is not needing to reconfigure the target system with an updated authorization when a new key is created. As long as a new cert is generated, and signed by a key trusted by the target, the new cert will be accepted, without needing to update authorized_keys. And the "CA key" trust can be specified by the authorized_keys file or by a config option in sshd_config.
Great video again. You can really see how much time, creativity and effort you put into editing your videos. This 10m videos must have taking a day to make.
i want to set up a home network and ssh into my wife's laptop. so i really have to breakdown and learn ssh. thanx for your excellent videos. you always give details. i like that.
OpenSSH is awesome, and so are you! This was a good bit of SSH info, and I found it nicely informative. It also reminded me to go clean up and regenerate my keys!
1. Couldn't agree more about the Macintosh Librarian- one of my favorites 2. Thank you, this is exactly the kind of fun yet informative content that is so hard to find. Hitting the patron.
This is the first video of yours that I've seen and I am immediately struck by how clearly you communicate! Both in terms of your script, and in terms of literally enunciating clearly. You stress the tricky consonants enough that my autistic brain can pick them out, but without going so far that it's just silly. That's such an awesome skill for a teacher to have and I'm so glad you enjoy what you do!
Abloy and SSH, two well-known Finnish invention for security. I am old fashioned and still prefer 3072 bit RSA keys for SSH and Abloy Protec² for mechanical locks.
Thank you for another excellent video, Veronica. Yesterday I discovered sshfs. It seamlessly mounts a remote directory to your local system using ssh. It made life on my multi-OS home network much easier. Have a great day!
Thanks for making this video. I usually added the ed25519 type to generate my keys, seems my keygen command just got simpler. Would/could you do a video on proper ssh key management? That is something I still have issues with how to properly administrate them.
Thanks for the video! Somewhere in enterprise RSA is still requirement, on modern systems too. "Azure currently supports SSH protocol 2 (SSH-2) RSA public-private key pairs with a minimum length of 2048 bits. Other key formats such as ED25519 and ECDSA are not supported."
Enterprise deployments tend to chase FIPS compliance and Ed25519 is not quite there yet with NIST. The NIST curves like P256 are trusted by no one but still used as the least bad option unless you consider RSA the least bad option. Everyone is annoyed with NIST about them taking so long to get the whole Ed25519 certification cake baked.
@aysnov RSA is resource intensive compared to the others. It scales poorly too. NIST aren't even working on writing up the ed25519 specs which tells you that they are doing thier best to delay its adoption.
I'd argue "resource intensive" beats "leaks your private key if you ever use it with poor RNG". Key exchange performance shouldn't really matter on anything reasonably modern anyway, short of maybe some very constrained embedded systems.
@aysnov A poor RNG is never going to be a problem for me (My job). But my primary concern is the side channel and fault injection properties. RSA sucks more than EC in that respect, but the side channel research changes pretty fast so it might be less true over time. Small devices (eg smart cards) have issues with computing large RSA operations. The intersection of good algorithms and NIST compliant algorithms is nothing.
There's also different curves or curve parameters. As I understand it, ECDSA uses some curves published by NIST, where they say "Use these curve parameters" without any particular justification, and people speculate the NSA may be involved in getting them to endorse those particular parameters. The Curve25519 curve used by Ed25519 is also allegedly maybe more secure when it comes to side-channel attacks? But at this point I'm beyond my ability to assertively repeat that information.
The NIST curves are suspect because some of the parameters are randomly generated. NIST publishes the seeds used for the random number generator, but no explanation how they came up with the seeds (they look random). They could have used a nothing-up-my-sleeve number but they didn't.
Thank you for saving me from having to find this out. Pausing my recovery for a moment, I can imagine this breaking things at my old workplace, perhaps on OpenVMS stuff. But as they are not paying me, I'm going to watch a cat video.
Informative video. I will update my procedures to use the newer type of keys. I will watch the other video for information about the catalog to see if it will help me. I have multiple key pairs which results in ssh giving up on login attempts before finding the right key. I made some shell scripts to tell ssh which identify to use when I want to access certain systems.
Nice news on the SSH updates. While there's no problem if both client and server run a modern version of openssh, it could be confusing to connect from modern to legacy system (e.g. an OpenWrt router which hasn't been sysupgraded for years), but all can be done with some knowledge and google-fu. Hey, nice to see the creator shoutout! Who knows, maybe I'll end up there someday :D
Can't explain why but your style reminds me of such of the Beakman's Science Show, great synergy between info and entertainment. I really like your production style. Thanks for sharing.
For Debian the oldest release that supports it is: Debian 8 Jessie from 2015 So in case of Debian, you had to be running software older than that, like Debian 7 Wheezy from 2013
I can't recall ever seeing the ED25519 option whenever I've generated SSH keys on Cisco gear, so I'm guessing it either doesn't support it, or possibly calls it something else. The latter wouldn't surprise me, since Cisco seem to like having their own way of doing things. Also, Macintosh Librarian is a great channel! Maccy is so much fun!
There's no need to so I'm pretty sure they won't do it. Also, I'd expect them to want gov certifications (FIPS, and the like), Ed25519 wasn't allowed in those until very recently (like 2023)
Been loving Macintosh Librarian. She really hits you right in the nostalgia button, assuming you used old Apple and Macintosh computers in school. It’s also really neat to see the things people have come up with to keep old tech running or even expand it’s capabilities, far beyond what was possible when it was new.
Thanks. I just watched this as my 1st video from you. Good job as all my instructions always have -T option. I did run into this issue with Hadoop I think that needed RSA keys vs ed25519, the newer modern one that you and I use.
Fun fact. A week ago or so, I played a game called Scanner Sombre (awesome btw) which used a faulty OpenSSH feature code. Intel 10th+ generation CPUs apparently have a feature for better key generation and that faulty code caused the game to crash when attempting to use the CPU feature with it. Intel has posted an article about it "OpenSSL* SHA Crash Bug Requires Application Update." A game dev unrelated to this game has debugged the issue and made a tutorial to edit the executable to replace the OpenSSH commands by NOP and it fixed it. It was later found that just telling Windows not to use those features worked too, albeit not as fun. Perchance.
You're insanely talented, and the information that you provide is so important to hear, so I say this with deep respect. My hearing isn't what it used to be, and sometimes it can be be a difficult to understand words when the pitch goes too high. Thankfully closed captioning helps, but if you could keep an ear on your pitch for the benefit of older listeners when you record your videos? Thanks again for all the great information!
That's not for her to say, not you. =) It is fair for me to say that I need to hear what she's saying. As mentioned, I do use the closed captioning and that does indeed help! You're right that I'm requesting reasonable accommodation, like asking a spouse to use a lower shelf in the kitchen, or a phone app to allow the setting of larger font sizes to ease readability. I'd like to think that we don't (yet) live in a world in which we tell others that they should just go buy a ladder or rely on screen readers. Veronica puts a great deal of effort in taking complex, detail oriented topics and delivering content that is both accurate and nuanced. She also certainly puts considerable thought into delivery style as well and modulates her voice to make the monologues more interesting. The only catch is that it can affect the comprehension for those with hearing loss if not moderated well.
Hi, new subscriber, but ooold S/W guy here. Coupla things: I work for a contractor at a US Gov't agency known throughout the solar system (ahem). The servers on one of my projects don't accept ed25519... they insist on ECDSA, which has, shall we say, a controversial history. Given a choice, I'll use ed25519 key pairs; I trust djb a whole lot more than I do NIST. The other thing: My spouse and I had Power Computing machines in the brief window when Apple allowed clones, before the Second Coming of Jobs. They were pretty cool machines, and the company had an Attitude that I found refreshing. Thanks, looking forward to more of your content!
The edge cases I usually seem to hit in the past with ssh keys were related to software that used ssh internally. Like some kind of niche software for a company. There would usually be some code that specified the type of key and I couldn't use newer types of keys with it.
I love your videos! Great tips and very positive energy, you ALWAYS make my day 😁, by the way, the C=64 and Amiga Boing reminded me of all the fun. Thanks and Greetings from Northwest Mexico.
Just yestarday I generated a new keypar for a fresh arch install and when I pasted the public key on my nas server, I noticed this weird new key that look nothing like my old ones. Thanks for the info 😅😊
The "More secure" part is debatable. Yes, you can get away with way smaller key sizes to achieve similar security, but they are fundamentally different algorithms. Comparing them isn't as simple as one might think. Whether it is more secure will depend on your threat model and key sizes. AFAIK rsa is still way more resistant against quantum attacks than Ed25519 for example.
I believe I said RSA is "often" less secure, and I said I'm not a cryptographer. But please, if you know of any reputable cryptographers who feel RSA public/private keys are a more secure choice than Ed25519, I'd like to hear it. :)
@@VeronicaExplains I mean we could argue about it, but realistically speaking both (at the current default key sizes) are more than good enough for 99.99% of use cases. Many bank and government websites to this day use RSA 2048 in their SSL certs. It all depends on the threat model, and let's be honest, if you're dealing with an organization that has the capability to brute force these algorithms, they also have the capability to raid your house/data center and just grab the server directly, and they won't bother with trying to brute force the algorithm unless they absolutely have to. More secure defaults, smaller keys, why not, but realistically speaking, it doesn't really matter, your old rsa keys are fine just fine. It's far more likely that someone will find a pre-auth 0-day vulnerability in openssh than someone bruteforceing your RSA 2048 key. XKCD 538: Security
I needed to keep RSA keys around because AWS EC2 didn't support ed25519 keys. I just checked again, and it turns out they added support for it 2 years ago. I can now use ed25519 keys for all my use cases
I do sysadmin in a "legacy" setting (so many stupid windows servers), we are just looking at transferring to ssh keypairs... Although somehow we run docker containers like they're going out of fashion. Gonna go watch the OpenSSH video now, cheers!
Yay, I needed to get sshd running under Ubuntu after doing a complete wipe/reinstall a few weeks ago, so this would be the perfect time to see if this improvement is in the changelogs, or whatever. I'm just accessing my PC from my Chromebook, so I'm no power user of sshd, but it's always fun to delve into a part of Linux that I normally just "set and forget". Thanks for the info.
@@bogdanrzheusski8115 Thanks, yes, as Veronica explained. That's what I wound up doing, as my ssh-keygen isn't yet the newest release (Ubuntu being downstream of Debian). Read the man page for it too, like every day with Linux, a learning exercise.
Recently got a nice deal on a very old Cisco PoE switch. When attempting to SSH into it, I wasn't supersized that doing so required setting flags for algorithms no longer supported by default, like SHA1 and aes-256-cbc.
Here's a problem point I see coming & I'm prepping my popcorn for the show: Last I looked Windows (11 no less) does NOT support/allow ed25519 keys (it does support ecdsa though). A hole that carries over into Windows Subsystem for Linux as well.
WSL2 doesn't support ed25519 keys? Are you talking about someone SSHing into a Windows 11 machine remotely? I've been using ed25519 keys to SSH into remote servers FROM Windows 11 WSL2, no problem.
I just finished changing all my keys over to ed25519 a couple of days ago. I had no idea they'd be changing the default so this is good news. I always had to either run '--help' or do a quick 'man ssh-keygen' cause I could never remember ed25519 and then because I had an old rsa key still hanging around I'd always have to specify the id file either on the command line or in a config file which was a bit of a drag.
Yeah, I’ve already been bitten by outdated servers that only accept rsa,dss (which cannot be updated from my end at least). Thankfully the workaround from the client side isn’t too hard. Also, good advice and reminder to rotate those crusty old keys… 😅
If you want go further, you can set up hardware-based SSH key which usually stated as ed25519-sk or rsa-sk. So the hacker need to be a physical theft to penetrate :)
Love the content! One question I keep pondering watching your videos is that are you and the Technology Connections person connected in any way? Your jokes and style feel very similar to me and I am having an absolute blast yours and his videos!
Being a fellow minnesotan, it's uncanny to hear what sounds exactly like my aunt schooling me in how to use OpenSSH, it's like I can't help but not pay attention.
I remember integrating RSA keys into LDAP years ago and found that I had to strip the line ends of the public key before it would work. I wonder if I'd have to do the same with this key type?
I see you have the 'bible' working as a monitor riser ;) That's the defacto resource for Unix and Linux systems administration for those not in the know. Great learning resource for both Linux and BSD Unix.
Updating SSH keys is a pain in the toucans, but totally agree that it's definitely good hygiene. As a slight aside, I recently wiped and reinstalled the OS on my Steam Deck, making sure to back up ~/.ssh to avoid having to update my keys. Except I forgot to back up my *host* keys in */etc/ssh,* and so I had to go through the hassle of key-pruning across my ecosystem anyway. 😭
Wait, why do you care about your host key and why did that make you have to rekey everything? Just delete the offending line in known_hosts.. Right? Or am I missing something?
@@Raycursion Yes, that's correct. But I have *a lot* of machines on my network running OpenSSH that needed to be pruned. And given that they tend to have entries for each _way_ the machine is identified (via IP vs via DNS), it was maybe five minutes each across a dozen machines, so an hour in sum.
Note that the client keys are only used for authentication, not encryption, so Veronica is right to reassure work-shy viewers than nothing needs to be done. New symmetric session keys are negotiated by the hosts to encrypt the traffic for each session _before_ authentication. This employs a special key exchange algorithm and a variety of ciphers. Further, hosts have their own asymmetric keys for an added layer of trust. A security-sensitive administrator can distribute these host keys around a network to improve this. Moreover, traffic is normally compressed, and thus is already in a fairly incomprehensible state before it is encrypted. One more thing, you can increase key strength when generating your client key pairs with ssh-keygen by using the -b flag to make longer keys than the default.
I have LMDE6 on an old Dell M4700. Till now, for me the minus is the way to configure an Access Point. I`m wondering if you also found some stuff that needs some refactory/improvement.
It’s never a bad idea to update SSH keys regularly - even better when there is a more secure algorithm. 🙂
I try to replace mine every two years or so. Sometimes with dev/play servers I let them go a little longer, but those usually aren't even on most of the time when not in use!
Hi @@VeronicaExplains. Great vid. However NIST is recommending to rotate your keys every 1 to 12 months now ;)
Oooo, I don't see that in their last whitepaper I read. Is this new? (Note, any link you share here might get auto-blocked but I'll hopefully see it, vet it, and then allow it through.)
@@Johan.Molenberghs I'd think that this would only be necessary if you have really bad security hygiene; dropping your keys onto every machine that you touch. If you manage your keys well I can't see how changing them like you change your underpants actually helps. (1 to 12 months: yes, I'm a dirty old man :)
Good to know, @@Johan.Molenberghs. I usually do the same as @VeronicaExplains does, updating my keys every couple of years.
Officially requesting that "Oh No! Am I going to have to do some work, Veronica?!" becomes a regular line in your show.
I might make it work!
oh, no...
+ also "Linux is awesome, and so are you."
Ringtone. That is all.
I read that comment exactly at the moment this sentence fell.
I'm so happy I subscribed to this channel. Love the content.
I subscribed when I read "no paid product placement"
Xana, so many good memories
Woohoo!! Code Lyoko!! \o/
Love the TLDR right after 5 seconds 😀
Doing my part to reduce clickbait! :P
I always like to describe public keys like locks and private keys like ... keys. I find this works well
Yeah, I think this is the best analogy. They are tied together in the same way
I mean, I guess? It's basically, "Here, I'm going to hand you this lock so that the next time we meet, you'll know it's me, because I'm the only one who can unlock it."
Public key is smart card reader, private key is your smart card.
You can register your smart card to any amount of readers.
@@Gornius You can also pin any amount of locks to fit a given key.
That is why i love MikroTik network equipment. even after over twenty years their switches and APs still get firmware updates to support the newest tech.
Love SSH... fast, secure, can do file transfers easily multiple ways... and can trivially be centrally managed with a key server. That might be an idea for a vid too: Key servers.
Edited to add: I mean e.g. LDAP vs universal key managers vs simple inotify to copy pub keys to servers that kind of thing. More than one way to skin SSH. :)
Uhm no. The whole point of the SSH key system is to easily create and distribute keys. The ed25519 keys are short so they are perfect, Look into ssh-copy-id. There is probably a manpage.
You can just publish those keys pretty much anywhere. Hey, you could piggyback them on the GnuPG keyservers as a comment.
using signed keys and KRL is part pf this
I also switche dto ed25519 keys years ago, and I'm glad it's now the default. It took me years to remember the digits.
Thank you for being an awesome smart woman! and for linking my channel :) !
Thank YOU for making awesome videos which help all of us learn more! :)
Damn, pitching out other channels is great! but also adding those in the description as well is a sign you are the best!! This channel is pure gold.
The topics you cover are not my everyday needs but the most useful when I'm in trouble, which would be my everyday if not for you. Also the script is clear and well delivered, good amounts of comedy and plenty of well researched information distilled with great filmmaking and awesome animations.
In any case, I'll recommend this channel as an example of how to do things properly. Even the captions are corrected! Great effort, great results. Thanks for sharing.
This comment brightened my day. Thank you so much!
@@VeronicaExplains
Great news. I am happy about the change.
The length of the public keys make a practical difference. The new keys fit on one line, and are easy to copy and paste.
One thing that might be cool to cover in the future is SSH certificates. They're built in to OpenSSH, with commands for managing them built in to ssh-keygen.
But they're useful because they allow you to essentially create auto-trusted, but auto-expiring keys for any user on the system. You can limit the authorization for the certificate to specific dates/times, specific users, even specific uses of SSH.
One benefit is not needing to reconfigure the target system with an updated authorization when a new key is created. As long as a new cert is generated, and signed by a key trusted by the target, the new cert will be accepted, without needing to update authorized_keys. And the "CA key" trust can be specified by the authorized_keys file or by a config option in sshd_config.
Yup, you can combine this kind of thing with something like Keybase and use it to manage your own custom CA for key management, it's fantastic.
Great video again. You can really see how much time, creativity and effort you put into editing your videos. This 10m videos must have taking a day to make.
i want to set up a home network and ssh into my wife's laptop. so i really have to breakdown and learn ssh. thanx for your excellent videos. you always give details. i like that.
OpenSSH is awesome, and so are you!
This was a good bit of SSH info, and I found it nicely informative. It also reminded me to go clean up and regenerate my keys!
Veronica is BACK!!!!!!!!!!!!!!!!!!!!!!
It would probably take a while for me to stop using the `-t ed25519` parameter 😁
Favorite tech channel on UA-cam. Love your content Veronica
Thanks for the explanation, and yes - the Macintosh Librarian channel is a _bunch_ of fun!
1. Couldn't agree more about the Macintosh Librarian- one of my favorites
2. Thank you, this is exactly the kind of fun yet informative content that is so hard to find. Hitting the patron.
Ok, ko-fi not patron. 🤷♂️
so great to see you back! Set looks like it's coming along well, and I hope things are turning for the better across the board for you!!
Incredibly well made video
First post "I quit COBOL" video and I love it. From one old-timer engineer to another, "great job, keep it up!"
This is the first video of yours that I've seen and I am immediately struck by how clearly you communicate! Both in terms of your script, and in terms of literally enunciating clearly. You stress the tricky consonants enough that my autistic brain can pick them out, but without going so far that it's just silly. That's such an awesome skill for a teacher to have and I'm so glad you enjoy what you do!
That Commodore 128 I dreamt to have back in the day... Until I saw the Amiga 500. Got the 500 and I never regetted it!
Same here! 😁
Abloy and SSH, two well-known Finnish invention for security. I am old fashioned and still prefer 3072 bit RSA keys for SSH and Abloy Protec² for mechanical locks.
5:15: That was incredibly well done! Wow! :) Great video. Thoroughly enjoyable.
Thank you for another excellent video, Veronica. Yesterday I discovered sshfs. It seamlessly mounts a remote directory to your local system using ssh. It made life on my multi-OS home network much easier. Have a great day!
Thanks for making this video. I usually added the ed25519 type to generate my keys, seems my keygen command just got simpler.
Would/could you do a video on proper ssh key management? That is something I still have issues with how to properly administrate them.
I just checked my FreeBSD-14.0 system and needed to update the config. Thanks for this info!
Thanks for the video!
Somewhere in enterprise RSA is still requirement, on modern systems too. "Azure currently supports SSH protocol 2 (SSH-2) RSA public-private key pairs with a minimum length of 2048 bits. Other key formats such as ED25519 and ECDSA are not supported."
Enterprise deployments tend to chase FIPS compliance and Ed25519 is not quite there yet with NIST. The NIST curves like P256 are trusted by no one but still used as the least bad option unless you consider RSA the least bad option. Everyone is annoyed with NIST about them taking so long to get the whole Ed25519 certification cake baked.
RSA *is* the least bad option. Even if you're willing to use crypto parameters from a three-letter agency, non-ed ECDSA is a giant footgun.
@aysnov RSA is resource intensive compared to the others. It scales poorly too. NIST aren't even working on writing up the ed25519 specs which tells you that they are doing thier best to delay its adoption.
I'd argue "resource intensive" beats "leaks your private key if you ever use it with poor RNG". Key exchange performance shouldn't really matter on anything reasonably modern anyway, short of maybe some very constrained embedded systems.
@aysnov A poor RNG is never going to be a problem for me (My job). But my primary concern is the side channel and fault injection properties. RSA sucks more than EC in that respect, but the side channel research changes pretty fast so it might be less true over time. Small devices (eg smart cards) have issues with computing large RSA operations. The intersection of good algorithms and NIST compliant algorithms is nothing.
There's also different curves or curve parameters. As I understand it, ECDSA uses some curves published by NIST, where they say "Use these curve parameters" without any particular justification, and people speculate the NSA may be involved in getting them to endorse those particular parameters.
The Curve25519 curve used by Ed25519 is also allegedly maybe more secure when it comes to side-channel attacks? But at this point I'm beyond my ability to assertively repeat that information.
The NIST curves are suspect because some of the parameters are randomly generated. NIST publishes the seeds used for the random number generator, but no explanation how they came up with the seeds (they look random). They could have used a nothing-up-my-sleeve number but they didn't.
This is so good. Finally, someone is addressing topics like these.
Absolutely fantastic config file at 8:35. 👍🏼the Brian May reference!
I always smile when I see your smiling face 😄, (and learn from your explanations.)
Oh that ending. LOL!! Thank you for another wonderful and informative video.
I'm glad you stayed until the end! It was a lot of fun. :)
Thanks for this. More please! More of everything please!
Thank you for saving me from having to find this out.
Pausing my recovery for a moment, I can imagine this breaking things at my old workplace, perhaps on OpenVMS stuff.
But as they are not paying me, I'm going to watch a cat video.
I'm looking behind you and I see you're on top of things
Informative video. I will update my procedures to use the newer type of keys. I will watch the other video for information about the catalog to see if it will help me. I have multiple key pairs which results in ssh giving up on login attempts before finding the right key. I made some shell scripts to tell ssh which identify to use when I want to access certain systems.
Hi from the patreon crowd! Using ssh since 1997, this was new to me!
As a genXer I appreciate all of the commodore/amiga surprises in this
Nice news on the SSH updates. While there's no problem if both client and server run a modern version of openssh, it could be confusing to connect from modern to legacy system (e.g. an OpenWrt router which hasn't been sysupgraded for years), but all can be done with some knowledge and google-fu.
Hey, nice to see the creator shoutout! Who knows, maybe I'll end up there someday :D
Also: if you allow password login, you should still be able to login with password.
Can't explain why but your style reminds me of such of the Beakman's Science Show, great synergy between info and entertainment. I really like your production style. Thanks for sharing.
It might be the fingerless gloves...
I like that your "Unix and linux system administration" is serving to raise your monitor height.
Commands in the description, this is why I come here! Well, one of the many reasons.
Lover your stuff. Keep doing it❤
I didn't even know this was a thing! Thanks Veronica for your explanation!
For Debian the oldest release that supports it is: Debian 8 Jessie from 2015 So in case of Debian, you had to be running software older than that, like Debian 7 Wheezy from 2013
Great video! Thanks :)
Nice to see you back making videos!
Thank you! Hopefully now the cadence picks up a bit!
I love the random Commodore 64 drops. I remember using that machine. Good times. :-)
I can't recall ever seeing the ED25519 option whenever I've generated SSH keys on Cisco gear, so I'm guessing it either doesn't support it, or possibly calls it something else. The latter wouldn't surprise me, since Cisco seem to like having their own way of doing things.
Also, Macintosh Librarian is a great channel! Maccy is so much fun!
There's no need to so I'm pretty sure they won't do it. Also, I'd expect them to want gov certifications (FIPS, and the like), Ed25519 wasn't allowed in those until very recently (like 2023)
Remember that SSH is the underpinning for SFTP, which is used by a few other user classes besides system admins and devops.
Been loving Macintosh Librarian. She really hits you right in the nostalgia button, assuming you used old Apple and Macintosh computers in school. It’s also really neat to see the things people have come up with to keep old tech running or even expand it’s capabilities, far beyond what was possible when it was new.
Thanks. I just watched this as my 1st video from you. Good job as all my instructions always have -T option. I did run into this issue with Hadoop I think that needed RSA keys vs ed25519, the newer modern one that you and I use.
It's awesome ed keys are the default now, been using them for a while just so the authorized_keys entries would look neater
Fun fact. A week ago or so, I played a game called Scanner Sombre (awesome btw) which used a faulty OpenSSH feature code. Intel 10th+ generation CPUs apparently have a feature for better key generation and that faulty code caused the game to crash when attempting to use the CPU feature with it. Intel has posted an article about it "OpenSSL* SHA Crash Bug Requires Application Update."
A game dev unrelated to this game has debugged the issue and made a tutorial to edit the executable to replace the OpenSSH commands by NOP and it fixed it. It was later found that just telling Windows not to use those features worked too, albeit not as fun. Perchance.
You're insanely talented, and the information that you provide is so important to hear, so I say this with deep respect. My hearing isn't what it used to be, and sometimes it can be be a difficult to understand words when the pitch goes too high. Thankfully closed captioning helps, but if you could keep an ear on your pitch for the benefit of older listeners when you record your videos?
Thanks again for all the great information!
My guy. She talks how she talks. This is not a reasonable request. She puts huge effort into the closed captioning for this reason.
That's not for her to say, not you. =) It is fair for me to say that I need to hear what she's saying. As mentioned, I do use the closed captioning and that does indeed help! You're right that I'm requesting reasonable accommodation, like asking a spouse to use a lower shelf in the kitchen, or a phone app to allow the setting of larger font sizes to ease readability. I'd like to think that we don't (yet) live in a world in which we tell others that they should just go buy a ladder or rely on screen readers.
Veronica puts a great deal of effort in taking complex, detail oriented topics and delivering content that is both accurate and nuanced. She also certainly puts considerable thought into delivery style as well and modulates her voice to make the monologues more interesting. The only catch is that it can affect the comprehension for those with hearing loss if not moderated well.
Hi, new subscriber, but ooold S/W guy here. Coupla things: I work for a contractor at a US Gov't agency known throughout the solar system (ahem). The servers on one of my projects don't accept ed25519... they insist on ECDSA, which has, shall we say, a controversial history. Given a choice, I'll use ed25519 key pairs; I trust djb a whole lot more than I do NIST. The other thing: My spouse and I had Power Computing machines in the brief window when Apple allowed clones, before the Second Coming of Jobs. They were pretty cool machines, and the company had an Attitude that I found refreshing. Thanks, looking forward to more of your content!
Great video, great reminder.
Un saludo desde Bogotá
So happy about this. It was so annoying to need to google it every time because who can remember ed2?????
Here's a tip- in most terminals you can type `-t ed` and then hit tab. On the few I regularly use, it autofills the rest. :)
@@VeronicaExplains oh yeah auto-completions are standard now...
😅
The intro fakeout was fantastic, glad I had set my coffee down
Oh No!! Am I going to have to do some work Veronica?? 😄🤗 Your videos are so enjoyable to watch!
I love your retro visuals!
The edge cases I usually seem to hit in the past with ssh keys were related to software that used ssh internally. Like some kind of niche software for a company. There would usually be some code that specified the type of key and I couldn't use newer types of keys with it.
I love your videos! Great tips and very positive energy, you ALWAYS make my day 😁, by the way, the C=64 and Amiga Boing reminded me of all the fun. Thanks and Greetings from Northwest Mexico.
Thank you! Your comment made my day!
your videos always have such a good vibe
Just yestarday I generated a new keypar for a fresh arch install and when I pasted the public key on my nas server, I noticed this weird new key that look nothing like my old ones. Thanks for the info 😅😊
I liked the fake-out on the exit music midway through the video.
The "More secure" part is debatable. Yes, you can get away with way smaller key sizes to achieve similar security, but they are fundamentally different algorithms. Comparing them isn't as simple as one might think. Whether it is more secure will depend on your threat model and key sizes. AFAIK rsa is still way more resistant against quantum attacks than Ed25519 for example.
I believe I said RSA is "often" less secure, and I said I'm not a cryptographer. But please, if you know of any reputable cryptographers who feel RSA public/private keys are a more secure choice than Ed25519, I'd like to hear it. :)
@@VeronicaExplains I mean we could argue about it, but realistically speaking both (at the current default key sizes) are more than good enough for 99.99% of use cases. Many bank and government websites to this day use RSA 2048 in their SSL certs.
It all depends on the threat model, and let's be honest, if you're dealing with an organization that has the capability to brute force these algorithms, they also have the capability to raid your house/data center and just grab the server directly, and they won't bother with trying to brute force the algorithm unless they absolutely have to.
More secure defaults, smaller keys, why not, but realistically speaking, it doesn't really matter, your old rsa keys are fine just fine. It's far more likely that someone will find a pre-auth 0-day vulnerability in openssh than someone bruteforceing your RSA 2048 key.
XKCD 538: Security
I needed to keep RSA keys around because AWS EC2 didn't support ed25519 keys. I just checked again, and it turns out they added support for it 2 years ago. I can now use ed25519 keys for all my use cases
I do sysadmin in a "legacy" setting (so many stupid windows servers), we are just looking at transferring to ssh keypairs... Although somehow we run docker containers like they're going out of fashion. Gonna go watch the OpenSSH video now, cheers!
Yay, I needed to get sshd running under Ubuntu after doing a complete wipe/reinstall a few weeks ago, so this would be the perfect time to see if this improvement is in the changelogs, or whatever. I'm just accessing my PC from my Chromebook, so I'm no power user of sshd, but it's always fun to delve into a part of Linux that I normally just "set and forget". Thanks for the info.
You can always specify encryption you want to use for key generation yourself with > ssh-keygen -t
@@bogdanrzheusski8115 Thanks, yes, as Veronica explained. That's what I wound up doing, as my ssh-keygen isn't yet the newest release (Ubuntu being downstream of Debian). Read the man page for it too, like every day with Linux, a learning exercise.
can you please make a video how to manage all these keys, which pam system i should use for organize all my keys?
Recently got a nice deal on a very old Cisco PoE switch. When attempting to SSH into it, I wasn't supersized that doing so required setting flags for algorithms no longer supported by default, like SHA1 and aes-256-cbc.
Yup! That's a thing with a lot of old network equipment!
Here's a problem point I see coming & I'm prepping my popcorn for the show: Last I looked Windows (11 no less) does NOT support/allow ed25519 keys (it does support ecdsa though). A hole that carries over into Windows Subsystem for Linux as well.
WSL2 doesn't support ed25519 keys? Are you talking about someone SSHing into a Windows 11 machine remotely? I've been using ed25519 keys to SSH into remote servers FROM Windows 11 WSL2, no problem.
I just finished changing all my keys over to ed25519 a couple of days ago. I had no idea they'd be changing the default so this is good news. I always had to either run '--help' or do a quick 'man ssh-keygen' cause I could never remember ed25519 and then because I had an old rsa key still hanging around I'd always have to specify the id file either on the command line or in a config file which was a bit of a drag.
Yeah, I’ve already been bitten by outdated servers that only accept rsa,dss (which cannot be updated from my end at least). Thankfully the workaround from the client side isn’t too hard. Also, good advice and reminder to rotate those crusty old keys… 😅
If you want go further, you can set up hardware-based SSH key which usually stated as ed25519-sk or rsa-sk. So the hacker need to be a physical theft to penetrate :)
Love the content! One question I keep pondering watching your videos is that are you and the Technology Connections person connected in any way? Your jokes and style feel very similar to me and I am having an absolute blast yours and his videos!
Oh I love Mac Librarian! Her vids are so good.
ok but will this help me keep my super secret supervillain plans to secret from a totally not imagined quantum threat
I always get Ed25519 and ED-209 mixed up. 👍
HAHA, I was getting ready to post about the ed209, but then I saw your post :P Cool that it is going default now
Ed25519 doesn’t care but don’t upset ED-209!
I've seen so many commercials when I hear ED, I only think of...commercials and blue pills haha
@@ironfist7789 "going default" I like that.
@@randomgeocacher sometimes 209 has minor glitches!
Being a fellow minnesotan, it's uncanny to hear what sounds exactly like my aunt schooling me in how to use OpenSSH, it's like I can't help but not pay attention.
Brian May IS an absolute genius!
Awesome retro feeel u give in ur videos, I date back to PC-XT days of Dos
Love your videos! Interesting. I've used linux since 1993.
That's a lot! Real deal old guard.
I found a RHEL CD from 1998 in my box of archived stuff... nope, don't wanna go back to that.
I remember integrating RSA keys into LDAP years ago and found that I had to strip the line ends of the public key before it would work.
I wonder if I'd have to do the same with this key type?
I see you have the 'bible' working as a monitor riser ;)
That's the defacto resource for Unix and Linux systems administration for those not in the know. Great learning resource for both Linux and BSD Unix.
Nice boing-ball graphic you got there. Have you done any Amiga or AmigaDos videos?
Love your videos, Thank you.
Updating SSH keys is a pain in the toucans, but totally agree that it's definitely good hygiene.
As a slight aside, I recently wiped and reinstalled the OS on my Steam Deck, making sure to back up ~/.ssh to avoid having to update my keys.
Except I forgot to back up my *host* keys in */etc/ssh,* and so I had to go through the hassle of key-pruning across my ecosystem anyway. 😭
No backups?
Changing keys takes 15 seconds?
5 to create it, 5 to copy/save it, 5 to test it…
@@pepeshopping generating isnt the issue but pruning old ones and sharing the new ones is unless you have that process somehow automated
Wait, why do you care about your host key and why did that make you have to rekey everything? Just delete the offending line in known_hosts.. Right? Or am I missing something?
@@pepeshopping Not of /etc. My backups only covered /home/deck.
@@Raycursion Yes, that's correct. But I have *a lot* of machines on my network running OpenSSH that needed to be pruned. And given that they tend to have entries for each _way_ the machine is identified (via IP vs via DNS), it was maybe five minutes each across a dozen machines, so an hour in sum.
Note that the client keys are only used for authentication, not encryption, so Veronica is right to reassure work-shy viewers than nothing needs to be done. New symmetric session keys are negotiated by the hosts to encrypt the traffic for each session _before_ authentication. This employs a special key exchange algorithm and a variety of ciphers. Further, hosts have their own asymmetric keys for an added layer of trust. A security-sensitive administrator can distribute these host keys around a network to improve this. Moreover, traffic is normally compressed, and thus is already in a fairly incomprehensible state before it is encrypted. One more thing, you can increase key strength when generating your client key pairs with ssh-keygen by using the -b flag to make longer keys than the default.
Yep. This is my go to command: ssh-keygen -o -a 100 -t ed25519
Oh great! I've been wondering why RSA is still so common as default.
-- Edit -- I loved both the early intro and early outro!
I have LMDE6 on an old Dell M4700. Till now, for me the minus is the way to configure an Access Point. I`m wondering if you also found some stuff that needs some refactory/improvement.
2:48 the -sk ones, as I understand it, are meant for FIDO2 devices like a Yubikey.
"Because Linux is Awesome. And So Are You." -- I literally just got a huge rush of endorphins!!!
This keygen thing is pretty cool. I bet someone could start a church based on it.