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.
How about 'no'.
Not sure I trust a central repository of trust.
How about you feature less bugs and better security before adding new stuff we aren't really ask for ....?
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 !
Muchas Gracias, Señor Edward Snowden !
Agreed. I want to know if my servers' keys have changed unexpectedly. You can set UpdateHostkeys No to turn this off; I'd like the option of UpdateHostkeys Prompt.
I do understand that having Prompt as the default would undermine the intended use case somewhat, but I think it would be good to have the option.
Maybe it's off-topic, but is it just me who see potentially big problems with ed25519.c? e.g. http://bxr.su/OpenBSD/usr.bin/ssh/ed25519.c#25
Hint: no input validation, hard-coded array offsets with no clue about their expected size, etc...
I know, it's open-source (I should contribute, blablabla) but I see this kind of problems all over that code base.
How about 'no'.
Agreed.
Consider the situation where an attacker has actually compromised a server key - either it was leaked, brute forces, a vulnerability exploited. It happens and big parts of the certificate system such as revocation lists, OCSP, validity periods etc are concerned with this. Or consider the situation where a vulnerability allows the attacker to *fake* the fact that he has the private key.
Many systems are set up to warn or outright block if they are not able to check revocation for a certain time period. Seems to me, that with this extension an attacker can use the time from when the key is actually compromised until the breach is discovered/reported and gain permanent foothold instead of a temporary one.
This capability seems too dangerous to even have in the protocol - even if one can argue that it is protected. It broadens the attack surface in a significant way.
Of course, all security is a balance between risks, consequences and cost. Maybe, if this capability significantly lowers some other risk, it could outweigh the risk incurred by the increased attack surface. But color me skeptical.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
So the server, whose key has been compromised, tells the client to replace keys? It's February 1st, not April 1st.
We need keys and host passwords checked as authentication types without having to revert to PAM hackery. Just how many systems have been exploited because some root process found a way to read some .ssh/keys and then hopped to other systems with no human intervention.
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
Dangerous because automatic key updates should require a great deal of verification of the new keys. I could imagine some scenarios (e.g. cloned virtual machines), which lead to the authenticated key being correctly updated (e.g old instructions/documentation) by the admin, but the EC key not overwritten (since it's not in the standard procedure). If this EC key then is copied automatically to the client, any of the cloned machines would accepted as a verified server after the login.
Overkill because exposing the public keys in terms of the sftp protocol would be less invasive and give the client full control what to do whith the keys.
No thanks, I'll pass on this feature.
Buck Feta. You know what to do.
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.
Wild Bill Donovan is a "faggoty European name"?
Watch this Heartland Institute video
Now the executable has code that will look up a particular key and replace it by something provided by the program.
This is the perfect code to execute via a buffer overflow. It does all of the drudge work of compromising and is maintained by the OpenSSL developers, so will get updated to deal with whatever changes in the key files.
So your attack kits just need to replace the call address to be used for "arbitrary code execution" for each new binary and are fit to go. You don't even need an executable stack. The code doing all the work is already there.
This is so typical of the current OpenSSH maintainers, it actually hurts to watch.
The actual problem is that there's no client tool for clearing replaced keys. You hve to open up your "authorized_keys" file with a text editor or the client keeps moaning "oh, no, the key doesn't match, boo-hoo-boo-hoo!!" even when you know damn well you rebuilt the host and it has new keys, or a dozen similar situations. If the software is smart enough to read and detect old and not matched recorded host keys, it should be intelligent enough to delete the old one if you say "ok, yes, I do want to replace that". But there's not even a tool to do it with. And you can't just use "ssh-keygen" to scan the relevant target and script it, because known_hosts entries are not in a canonical format or one that matches the output of 'ssh-keygen'. So scripting it turns into a right pain in the ass, partly because people ignore the RFC's about hostnames and now are using Unicode hostnames for things. (Check out Thailand and other Asia, non-compliant registrars for an introduction to non-compliant DNS).
The result is that, if you have significant system churn, you set your client to ignore host key validation (Setting "CheckHostIP no") because you *do not have the time to waste with this*. This especially happens when you are building new hosts in a small DHCP assigned address space, or if you have non-registered DHCP for a bunch of development environments that all get built from scratch rather than using a deployed, locked set of standard SSH keys. When keys expire and a new host gets the same IP address, you're screwed.
SSH hostkeys are, frankly, a joke in any case. They cannot be trusted for the initial host authentication because there is no default signature or verification method for the keys themselves. And the client behavior is so painfully awful that everyone who actually handles more than the machine room they built in their mom's basement has learned to just ignore the damn things and either set 'CheckHostIP no' or simply delete the $HOME/.ssh/known_hosts file on a regular basis, because the criping and whinging about accumulated discrepancies break things on an unpredictable basis. And yes, I reported the issue and tried to patch it with SSH 1, SSH 2, and OpenSSH, it's a fundamental architectural "practice".
So basically, this is a complex and stupid answer to what is the wrong problem. It's not a server hostkey publication problem, it's a client "we're too stupid to know how to expire old or invalid hostkeys because we arrogantly assume all servers are complete stable and you should just be able to open 'vi' and fix it yourself" problem.
ED25519? That sounds good. I haven't upgraded to anywhere near the current version, I'm still running the ED209 for security. It's a bit buggy, but no one gets past it.