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.
Related Stories
The Latacora firm has a blog post asserting that OpenSSH-portable has poor defaults for encrypting private RSA keys because of its reliance on OpenSSL. The blog goes into why this is a problem and how you can test it for yourself.
There is nothing wrong with the generated RSA keys themselves, however, just the encryption of the private RSA keys -- if made using current defaults. There are two ways of encrypting RSA keys, an old and apparently insecure way, and a new key format available but not default. Newer key types like Ed25519 use only the new key format and are not bothered by this problem.
Earlier on SN:
WikiLeaks Unveils CIA Implants That Steal SSH Credentials From Windows, Linux PCs (2017)
Upgrade Your SSH Keys (2016)
OpenSSH 6.8 Will Feature Key Discovery and Rotation for Easier Switching to DJB's Ed25519 (2015)
Researcher Ben Perez has written that it is time to stop using RSA[*] encryption. He goes into some of the problems with the algorithm and its supporting code bases, how bad they are, some of the mitigations, and then explains his conclusion. Curve25519 is being recommended instead.
RSA was an important milestone in the development of secure communications, but the last two decades of cryptographic research have rendered it obsolete. Elliptic curve algorithms for both key exchange and digital signatures were standardized back in 2005 and have since been integrated into intuitive and misuse-resistant libraries like libsodium. The fact that RSA is still in widespread use today indicates both a failure on the part of cryptographers for not adequately articulating the risks inherent in RSA, and also on the part of developers for overestimating their ability to deploy it successfully.
The security community needs to start thinking about this as a herd-immunity problem—while some of us might be able to navigate the extraordinarily dangerous process of setting up or implementing RSA, the exceptions signal to developers that it is in some way still advisable to use RSA. Despite the many caveats and warnings on StackExchange and Github READMEs, very few people believe that they are the ones who will mess up RSA, and so they proceed with reckless abandon. Ultimately, users will pay for this. This is why we all need to agree that it is flat out unacceptable to use RSA in 2019. No exceptions.
[*] RSA:
(Rivest–Shamir–Adleman) is one of the first public-key cryptosystems and is widely used for secure data transmission. In such a cryptosystem, the encryption key is public and it is different from the decryption key which is kept secret (private). In RSA, this asymmetry is based on the practical difficulty of the factorization of the product of two large prime numbers, the "factoring problem". The acronym RSA is made of the initial letters of the surnames of Ron Rivest, Adi Shamir, and Leonard Adleman, who first publicly described the algorithm in 1977.
However, many systems and hardware tokens are still hardcoded for RSA. So upgrading is not as easy a task as it could be.
Where have you been able to migrate from RSA? Where have there been obstacles?
Earlier on SN:
Mathematicians Seal Backdoor to Breaking RSA Encryption (2018)
Upgrade Your SSH Keys (2016)
512-bit RSA Keys Cracked in Four Hours for only $75 (2015)
NSA and RSA - Claims of More Evidence (2014)
SSH key forwarding is to be avoided when possible. When it is not possibile to avoid, it is a good idea to limit what gets forwarded. Software developer Vincent Bernat describes one way by putting a simple shell script wrapper around the SSH client to provide a session with a unique, ephemeral key agent.
ssh-agent is a program to hold in memory the private keys used by SSH for public-key authentication. When the agent is running, ssh forwards to it the signature requests from the server. The agent performs the private key operations and returns the results to ssh. It is useful if you keep your private keys encrypted on disk and you don't want to type the password at each connection. Keeping the agent secure is critical: someone able to communicate with the agent can authenticate on your behalf on remote servers.
ssh also provides the ability to forward the agent to a remote server. From this remote server, you can authenticate to another server using your local agent, without copying your private key on the intermediate server. As stated in the manual page, this is dangerous!
Perhaps another approach would be to embed the wrapper in the ProxyCommand configuration directive, thus obviating the need for either a shell alias or shell function.
How and why have soylentils had to deal with SSH agent forwarding?
Previously:
(2019) How SSH Key Shielding Works
(2019) SSH Gets Protection Against Side Channel Attacks
(2018) Default OpenSSH-Portable RSA Private Key Encryption is Poor
(2017) SSH vs OpenVPN for Tunneling
(2016) Upgrade Your SSH Keys
(2015) Why Aren't We Using SSH for Everything?
A blogger with the handle "Soatok" has written about considerations in safely using RSA. His first recommendation is not to use RSA at all any more. Failing that, if you must use RSA, he has various recommendations to mitigate the problems that using RSA entails.
Every RSA keypair must be represented as all of the following:
- RSA Secret Key (sk)
- Operation (sign or decrypt)
- Mode (padding or KEM-DEM)
- Hash function (signatures, MGF1)
- Modulus size
- Public exponent
- RSA Public Key (pk)
- Operation (encrypt or verify)
- Mode (padding, etc.)
- Hash function (signatures, MGF1)
- Modulus size
- Public exponent
Any time you change any of these configuration parameters, it MUST be used with a new asymmetric key-pair. The new key MUST NOT be used with the same raw key bytes as any previous key.
Elliptic Curve Cryptography (ECC) is apparently easier to work with, but both will be susceptible to cracking with quantum computers some day.
Previously:
(2019) Crown Sterling Demos 256-bit RSA Key-cracking at Private Event
(2016) Upgrade Your SSH Keys
(2015) 512-bit RSA Keys Cracked in Four Hours for only $75
(2014) NSA and RSA - Claims of More Evidence
OpenSSH developer, Damien Miller, has announced plans to remove support for DSA keys from OpenSSH in the near future. His announcement describes the rationale, process, and proposed timeline.
The next release of OpenSSH (due around 2024/03) will make DSA optional at compile time, but still enable it by default. Users and downstream distributors of OpenSSH may use this option to explore the impact of DSA removal in their environments, or to hard-deprecate it early if they desire.
Around 2024/06, a release of OpenSSH will change this compile-time default to disable DSA. It may still be enabled by users/distributors if needed.
Finally, in the first OpenSSH release after 2025/01/01 the DSA code will be removed entirely.
In summary:
2024/01 - this announcement
2024/03 (estimated) - DSA compile-time optional, enabled by default
2024/06 (estimated) - DSA compile-time optional, *disabled* by default
2025/01 (estimated) - DSA is removed from OpenSSH
Very few will notice this change. However, for those few to whom this matters the effects are major.
Previously:
(2021) scp Will Be Replaced With sftp Soon
(2020) SHA-1 to be Disabled in OpenSSH and libssh
(2019) How SSH Key Shielding Works
(2016) Upgrade Your SSH Keys
(2014) OpenSSH No Longer has to Depend on OpenSSL
(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.
(Score: -1, Flamebait) by Anonymous Coward on Monday September 26 2016, @04:21AM
Possession of a private key is the elitist snob version of writing a password on a sticky note and then scanning the sticky note and pasting it into a Word document. You have to store that key somewhere where someone can steal it because you can't possibly memorize it. So you have your keys written to your hard drives while I store my passwords exactly nowhere because all you dillweeds are dinking about with keys and I have my passwords memorized in my brain where you can't steal my passwords.
(Score: 2) by b on Monday September 26 2016, @04:32AM
Except you can use passwords with keys.
(Score: 3, Informative) by canopic jug on Monday September 26 2016, @11:41AM
Except you can use passwords with keys.
With recent versions of OpenSSH you can force both key and password authentication using the AuthenticationMethods setting.
That will check the key and only if the key was correct will it proceed to password authentication. Both are needed for login. Even later versions can be set to require multiple keys for logging in, though I am a little unclear about the use-case for that. Maybe it is if you have one key on the HD in your account and the other in some dongle like a yubikey.
Money is not free speech. Elections should not be auctions.
(Score: 0) by Anonymous Coward on Monday September 26 2016, @04:27PM
Two keys are for server administration with agent forwarding. For example, in order to connect to a server through another server, there are two techniques (which are probably best explained here: http://www.unixwiz.net/techtips/ssh-agent-forwarding.html). [unixwiz.net] But the gap in agent forwarding is that, even though the user authenticates properly, how can you be sure the connecting server is correct as well? You require a valid key that lives on the user's machine and one that lives on the server.
(Score: 2) by canopic jug on Tuesday September 27 2016, @05:44AM
Two keys are for server administration with agent forwarding.
The UNIXwiz link is quite nice. Thanks for posting it.
However, only a single key per server is needed when going in via agent forwarding. And if any of the intermediate machines or their sysadmins are even the slightest bit unreliable, then agent forwarding should not be used. As to being sure the connecting server is correct, that's what the known_hosts file on the client is for. So I'm still wondering about a use-case for ever requiring two keys for authentication. If you connect via a bastion using -W or -J then all the private keys stay and are processed on the originating client machine.
Maybe if you connect through a chain of clients (ssh server1 ssh server2 ssh server3) then there will need to be private keys on remote machines and that could be a case for multiple-key authentication.
Money is not free speech. Elections should not be auctions.
(Score: 0) by Anonymous Coward on Tuesday September 27 2016, @05:20PM
I think we are describing the same use case, but here it is a more exact example. Programmer has a machine that they program on, a central build machine, and a test deployment server. They make a change they want to test on one of the test machines. With a push, the automated build server builds the software. The user can then ssh to build machine and from that machine, copy it to a deployment server with ssh and fiddle with it as necessary. Therefore, the build machine directly confirms the user with the key and the user confirms the server with known_hosts. In addition, the user and build machine verifies the deployment server with known_hosts and the deployment server verifies the user with the forwarded key and the build machine with a separate nonforwarded key. This can be helpful because it can allow easier auditing because you can trace back the whole chain in a single log entry. It is also some small defense against bad actors because you can put separate limits on each machine per user and helps protect against stolen keys as deployment requires multiple keys that no one person has read access to. Although I've only seen that last one used religiously once. Most times people seem to use it for the ease of auditing when something malfunctions or people's memory fails because both parts are recorded.
(Score: 2) by canopic jug on Wednesday September 28 2016, @07:52AM
It is also some small defense against bad actors because you can put separate limits on each machine per user and helps protect against stolen keys as deployment requires multiple keys that no one person has read access to.
Ok. I see it as more of a guarantee that the login came via a specific machine. However, there may be ways around that. Trust has to come into play at some level.
Interesting.
The only way I can see read-only access to a key is if one user runs the agent and another loads it with a key only they can read. As far as I can tell, the loading user can only be root. For regular system users, ssh-add or ssh-agent seem not to acknowledge group read-write permissions on the agent's socket. Using root just steamrolls over that. Either way, it requires a bit of juggling to launch an agent with a known socket address and then, safely, use root to put a key into it.
Money is not free speech. Elections should not be auctions.
(Score: 3, Touché) by edIII on Monday September 26 2016, @05:28AM
Yes. But the elites, of the elites, turn their noses even higher! You can add a password to those keys. One can encrypt a key with 33 rounds and use a long passphrase if they so wished.
Copies of the keys can be kept lying about anywhere, like a penthouse in New York and one in the Hamptons. But we hand the passphrase to the butler, of course. That's what the help is for.
Technically, lunchtime is at any moment. It's just a wave function.
(Score: 2) by zocalo on Monday September 26 2016, @07:04AM
UNIX? They're not even circumcised! Savages!
(Score: 2) by arslan on Monday September 26 2016, @07:48AM
True. And you split your passphrase between them...
(Score: 0) by Anonymous Coward on Monday September 26 2016, @01:41PM
among them....
(Score: 0) by Anonymous Coward on Monday September 26 2016, @04:06PM
arslan wrote about splitting passphrases, not splitting hairs.
(Score: 3, Informative) by darkfeline on Monday September 26 2016, @04:24AM
GnuPG offers the ability to use a key pair as an SSH key. I have one on a Yubikey that basically gives me two factor SSH auth.
The problem with elliptic curve keys is that not all systems support it. If you're a dev using GitHub or whatever you're fine, but sysadmins will have trouble with older machines.
GnuPG also offers elliptic curve PGP keys, but they haven't been added to the OpenPGP standard yet.
Also, simply upgrading your SSH key may not be enough if the server hasn't been properly configured against Logjam.
Join the SDF Public Access UNIX System today!
(Score: 4, Informative) by stormwyrm on Monday September 26 2016, @04:32AM
Maybe I will upgrade my SSH keys, but I'll convert them to 4096-bit RSA. RSA's security properties are much better understood than elliptic curve cryptography. Their security seems to depend on the fact that there don't seem to be any relatively efficient algorithms for computing discrete logarithms over elliptic curves, the way more efficient (but still infeasible for reasonable key sizes) algorithms for doing so exist for computing discrete logarithms over, say, integers modulo a prime, or finite fields of characteristic 2. Thus they can get away with using smaller keys to achieve the same level of security provided no algorithm as efficient as those for other fields exists. Which is why you can get away with a 256-bit key for an elliptic curve algorithm, which appears to have the same level of security as a 3072-bit RSA or ElGamal. But if someone out there finds a method for calculating elliptic curve discrete logarithms as efficient as those for prime fields, then all that security goes out the window and you'll need to use keys as big as those used today for RSA/ElGamal and you then have no advantage using elliptic curves over those older algorithms. I rate the possibility of such an algorithm being discovered higher than that of someone finding a true polynomial time discrete logarithm or factoring algorithm (which would kill all of these schemes dead by the way).
Worse yet, these algorithms are even more vulnerable to quantum computers because of their small key size. Maybe it will be harder to build a quantum computer with 4096 qubits as might be needed to do Shor's algorithm on a 4096-bit RSA modulus, but maybe a 256 qubit quantum computer might be possible, and that would break a 256-bit elliptic curve scheme.
Numquam ponenda est pluralitas sine necessitate.
(Score: 0) by Anonymous Coward on Monday September 26 2016, @05:37AM
Give me 8192 bits or give me death.
I don't think 4096 qubits will be required to factor 4096 bit RSA: http://phys.org/news/2014-11-largest-factored-quantum-device.html [phys.org]
(Score: 1) by drgibbon on Tuesday September 27 2016, @02:12AM
You might like to check out GnuPG FAQs "Why doesn’t GnuPG default to using RSA-4096? [gnupg.org]" and "Why do people advise against using RSA-4096? [gnupg.org]".
Certified Soylent Fresh!
(Score: 0) by Anonymous Coward on Tuesday September 27 2016, @06:20PM
I've read these explanations before. I find them to be bullshit. There could be a classical attack against RSA that lowers the key strength, or a quantum attack that ruins RSA forever. The first would probably be known only to the NSA, and they'll use it for years before it gets made public. The second could at least be made more difficult by an order of a few months or a year by using the 8192 key size.
(Score: 1) by drgibbon on Wednesday September 28 2016, @05:52AM
Well, the point is that there are apparently diminishing returns with increasing RSA keysize;
Almost always when people use 4096-bit RSA they’re doing so because they believe RSA-4096 to be much stronger than it is. The United States’ National Institute of Standards and Technology (NIST) states that RSA-2048 gives roughly 112 bits of security and RSA-3072 gives roughly 128. There is no formal recommendation on where RSA-4096 lies, but the general consensus is that it would come in somewhere around 140 bits — 28 bits of improvement over RSA-2048. This is an improvement so marginal that it’s really not worth mentioning.
If you need more security than RSA-2048 offers, the way to go would be to switch to elliptical curve cryptography — not to continue using RSA.
I use RSA-4096 myself, and I might look into switching over to elliptical curve, but from the sounds of it RSA-8192 doesn't seem like a big benefit. Each to their own though.
Certified Soylent Fresh!
(Score: 2) by VLM on Monday September 26 2016, @11:21AM
Doesn't mention host keys much although they are handy to help vs MITM issues and various other problems. So fix those too.
WRT automation it talks about distributing your ssh .pub key files in a generic sense but in a specific sense I've had a lot of luck making a git repo and some scripts (well, a script) to add the local pub key (with a prompt of course) and add all the pub keys to your authorized file. One cool feature of automation is not having to care about ... excessive verification by manual standards. Why not GPG sign your SSH keys that you store to make sure no one changes them? Its a fun place to play with GPG signed git repos and gpg verification of git repos. Have the computer scan your authorized file and eat (or prompt) any keys that have magically appeared. All kinds of fun. And once you do it, you're done. Personally in my repo I store my ssh keys named loginname-hostname.key but whatever floats your boat.
My latest config system of choice is ansible and its not rocket surgery to make sure every machine in your realm of control have sensible "PubkeyAcceptedKeyTypes" and whatever else. Beware of just whomping in entire files across unix versions due to occasional path issues (like ansible uses stfp which is a library stored in different locations under different OS in the /etc/ssh/sshd_config file, big big fun)
(Score: 2) by opinionated_science on Monday September 26 2016, @02:09PM
All good ssh tips. For extra paranoia My machines use tinc as the only entry port.
Once you have a good vpn setup, all services can listen only on the inside ports, greatly reducing the attack surface.
Is this also a common thing for you folks?
(Score: 0) by Anonymous Coward on Monday September 26 2016, @03:13PM
Never heard if tinc.
Thanks!