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: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.