Slashdot Mirror
OpenSSH Will Feature Key Discovery and Rotation For Easier Switching To Ed25519
ConstantineM writes: OpenSSH developer Damien Miller has posted about a new feature he implemented and committed for the next upcoming 6.8 release of OpenSSH — hostkeys@openssh.com — an OpenSSH extension to the SSH protocol for sshd to automatically send all of its public keys to the client, and for the client to automatically replace all keys of such server within ~/.ssh/known_hosts with the fresh copies as supplied (provided the server is trusted in the first place, of course). The protocol extension is simple enough, and is aimed to make it easier to switch over from DSA to the OpenSSL-free Ed25519 public keys. It is also designed in such a way as to support the concept of spare host keys being stored offline, which could then seamlessly replace main active keys should they ever become compromised.
Agreed - this makes sense if you want to display a message to the user: "The server is advertising updated host keys via the trusted channel. Do you want to add them to your local host key list?"; but automatically replacing them without prompting seems overeager...
"Go to CNN [for a] spell-checked, fact-checked summary" -- CmdrTaco
Although, in hindsight - you've already authenticated the server, so you are going to treat it as a trusted party anyway...
Agreed, but *I* would still like to be prompted anyways. The same way when it comes to things like windows or app "automatic updates" I always pick the "notify me, but don't download/update without asking" option. I like to *know* what's happening to my systems, and have the option to say NO, even if it's probably unlikely.
OpenSSH is not buggy and has good security already. You must be thinking of the OpenSSL.
Yeah, but it's also easier to compromise a host, send out fake server keys, and then patch things up so the server looks fine again but intercept targeted clients. ...
I didn't RTFA, but based on the summary it seems like this is unlikely.
If you can compromise a host to the point that you have read access to the private host key, then your MITM can simply use that private key. No need to change to a new key to exploit that. AFAICT, you would need access to the existing host key pair in order to sign the new keys. If this was done right, then it seems like this would be adding very little (if any) additional risk.
That said, I'd want to have the option of being prompted. I could set that for all my interactive shells (or it could be the default), and I could set my automated jobs to auto-sync the new keys.
It's one thing to trust the server to be who you expect it to be.
It's something completely different to trust that server to tell you how to authenticate all the other servers that you know about. That requires a LOT more trust than "this server is the one I expected"
This is not what this is about. TFA talks only about updating keys for the same server as far as I can see.
Correct me if I'm wrong but this can only take place after a fully authenticated session.
If the NSA is in a position to MITM this connection then they are likely already in the possession of all necessary keys at either end and gain nothing by being able to send the client and server new keys.
How can NSA not loving this feature?
I mean, the two way encrypted channels between userA and serverA, if NSA would like to crack it, they would need to invest some crunch time just to take a peek
With this new protocol all NSA needs to do is to perform a MITM act ... get the info needed and then tell the user (and the server) to update keys and such
Mission accomplished !
Let's not go over the top with this. When you say "all NSA needs to do is to perform a MITM act" you are forgetting that the default for SSH is to abort during a MITM. That means they are back at needing "to invest some crunch time just to take a peek". The only loss is that, if they did compromise a server or manage to get into the encrypted channel they could potentially leverage that for a silent compromise of the client side key without thaat being visible on the host. It's still a pretty high risk attack for pretty low gain compared to what they have to already have (the ability to compromise some SSH connections).
Firstly, let's not just talk about the NSA. There are plenty of other bad actors and don't forget the Chinese and Russians also have pretty hot capabilities. Weakening crypto helps the enemy of all kinds. People who suggest reducing encryption knowing that, and I think most of them do, are traitors.
There should be a warning on key replacement or, better, a warning when the new key is taken into use. This would be important in the case where the enemy could compromise some connections but not others and then use key replacement to escalate that to all connections.
It is an internal function so the input validation should have already happened.
The hard coded offsets look like they are part of how the crypto works.
If I read the article (or even the summary) correctly, this is about updating the known_hosts file, not authorized_keys. So, even with this enabled, this only affects the "The hostkey has changed" warning message, not who can log in with which keys. Although I am a tad uneasy about automatic key updates, this seems to be fairly safe, and it makes it so much easier to change a hostkey, without bothering all the users of a system.
In Murphy We Turst
So, I have to trust a server to automatically replace a trusted key with a new trusted key.
Yeah, this is the type of thing I'll try when it's been in the code for five, ten years.
I'm perfectly sure, as a mathematician, that you can use some kind of secure exchange to make this work but - fuck - I won't be trusting implementations of it for a while.
Isn't this exactly the sort of thing that, half-assed, will generate security problems for years to come and yet still seems to be outside the SSH protocol and has to be a custom extension? Is there an RFC for this?
Sorry but as far as I'm concerned key management shouldn't be a part of the process that's handling connection authentications, etc. Why can't this be an outside protocol entirely? For decades, we've been waiting for some kind of automated decentralised, anonymised key-store and surely the effort going into securing this very dangerous piece of code would have been better put into moving the problem away from SSH and allowing multi-protocol use of such things.
Might be a canary, i.e. a test of how much stupidity and potentially insecure automation OpenSSH users are willing to accept. In that case the OpenSSH maintainers team is not stupid, but has been compromised. Would make sense...
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.