SoylentNews is people
SoylentNews
from the if-only-i-remember-where-I-laid-them-down dept.
Arthur T Knackerbracket has found the following story:
Whether you're a software developer or a sysadmin, I bet you're using SSH keys. Pushing your commits to Github or managing your Unix systems, it's best practice to do this over SSH with public key authentication rather than passwords. However, as time flies, many of you are using older keys and not aware of the need to generate fresh ones to protect your privates much better. In this post I'll demonstrate how to transition to an Ed25519 key smoothly, why you would want this and show some tips and tricks on the way there.
If you've created your key more than about four years ago with the default options it's probably insecure (RSA < 2048 bits). Even worse, I've seen tweeps, colleagues and friends still using DSA keys (ssh-dss in OpenSSH format) recently. That's a key type similar to RSA, but limited to 1024 bits size and therefore recommended against for a long time. It's plainly insecure and refused for valid reasons in recent OpenSSH versions (see also the changelog for 7.0).
The sad thing about it is that I see posts on how to re-enable DSA key support rather than moving to a more secure type of key. Really, it's unwise to follow instructions to change the configuration for PubkeyAcceptedKeyTypes or HostKeyAlgorithms (host keys are for a later post). Instead, upgrade your keys!
Compare DSA with the technology of locks using keys like this one. You wouldn't want this type of key to unlock your front door, right?
List all your keys:
You're probably thinking... "I'm using my key for a long time, I don't want to change them everywhere now." Valid point, but you don't have to! It's good to know you can have multiple keys on your system and your SSH client will pick the right one for the right system automatically.
It's part of the SSH protocol that it can offer multiple keys and the server picks the one your client will have to prove it has possession of the private key by a challenge. See it in action adding some verbosity to the SSH connect command (-vvv). Also if you're using an SSH agent you can load multiple keys and it will discover them all. Easy as that.
(Score: 0) by Anonymous Coward on Monday September 26 2016, @04:21AM
Now I'm supposed to have more keys around for those systems that accept the new format and still need the old keys those that don't. I can't upgrade the SSH daemon on my old OpenWRT-based router. I don't control all of the servers that I log into that are older than 4 years old (with current backported security patches, just not a current OpenSSH daemon).
Let me know when RSA-2048 has been broken completely. Until then, yes it is theoretically less secure than Ed25519 keys, but that's not enough motivation to have twice the number of keys to manage right now.
(Score: 2) by driverless on Monday September 26 2016, @10:46AM
Let me know when RSA-2048 has been broken completely.
I was just about to post the same thing. Does the OP even have the faintest idea of what it would take to factor a single RSA-2048 key? If the bad guys get into your system, I can guarantee it will be by anything other than attacking your RSA-2048 key. Switching to Ed25519 or whatever other fashion statement you want to make this week is just a distraction from having to address the ways in which attackers are actually going to get in.
(Score: 2) by VLM on Monday September 26 2016, @11:09AM
anything other than attacking your RSA-2048 key
Assuming they didn't subvert your key generation system and the key is a multiple of 1337 or merely 2 ** 2000 or something. A good RSA-2048 key.