NIST to sysadmins: clean up your SSH mess NIST has taken a look at how companies use Secure Shell (SSH), and doesn't much like what it sees. In spite of the depth of access generally handed SSH implementations for a host of different activities – “file transfers, back-ups, software/patch management, disaster recovery, provisioning and data base updates”, as SSH (the …
"NIST points to the vulnerabilities in old versions of SSH"
Wasn't Heartbleed, being related to a new feature, present in what was at the time the latest major version but not present in many older ones? The exception confirming the rule then? While applying patches remains crucial, proper monitoring of (unusual) activity remains key in my opinion.
There are quite a few significant issues with ssh version 1 (the protocol, not any particular implementation), yet you still see it available all over the shop.
That is the thing they are meaning. By all means stay away from the bleeding edge, but also stay away from the bloody and broken obsolete stuff too.
Is the SSH version 1 protocol still allowed anywhere? My recollection is that it has been deprecated for ten or more years, and when I left the US DoD several years ago their systems had been required for at least five years to be configured to use only protocol 2.
The article appear to address mainly sloppy administration practices that tools like SSH make easier. Monkeying with SSH will not cure that, and it is not clear that some of the matters complained of are properly the job of SSH at all.
proper monitoring of (unusual) activity remains key in my opinion.
Very true. No matter how modern and bug-free the security code may be, no sysadmin should assume that all the users are using it correctly and sensibly. You may lock your office each night, but I'll bet you still have a burglar alarm.
That, and being able to generate a key limited to a specific source or destination host, to further limit the ability bad actors to re-use a compromised private key or lazy re-use by admins of the public key on multiple hosts. Having this security be inherent to the key itself, rather than require changes to the config file, will make unintentional security oversights that much harder.
There are legitimate reasons why you might want more general keys, but that should not be the default, nor should a key that lasts "forever", so that you have to at least understand enough about how it works to flag the ssh-keygen options to produce more general and long-lived keys.
Agreed, I had a "WTF?" moment a while back when I realised a private key could be copied to another client and would be accepted by the target server in the same way as a cloned physical key. The 'from="list of permitted clients"' syntax in the authorized_keys file is still weak, poorly documented and little known.*
And trusted clients should be trustworthy themselves.
* I know you know this, but posting it explicitly to spread the word.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
