back to article 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 …

  1. jake Silver badge

    So basically ...

    ... folks who are unclear about security are unclear about security?

    Whodathunkit. Go figure. I would have never guessed.

    1. Yet Another Anonymous coward Silver badge

      Re: So basically ...

      And the people that worked with the NSA to subvert the security of standards are giving advice on security.

      Next up - 1970s "top of the pops" stars guide to child care

  2. John Deeb

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

    1. djack

      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.

      1. Brewster's Angle Grinder Silver badge

        The goldilocks version doesn't sit still, but keeps on dancing away.

      2. Anonymous Coward
        Anonymous Coward

        > By all means stay away from the bleeding edge, but also stay away from the bloody and broken obsolete stuff too.

        Sounds like "Run Debian Stable", though I suspect that alone didn't prevent anyone from being hit by heartbleed.

      3. tom dial Silver badge

        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.

    2. gerdesj Silver badge

      Non sequiter

      "Wasn't Heartbleed..."

      ssh = Secure Shell, ssl = Secure Socket Layer. ssl != ssh.

      1. Grifter

        Re: Non sequiter

        He didn't compare the two, you should read his reply more carefully.

    3. Phil O'Sophical Silver badge

      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.

  3. John Robson Silver badge

    Key expiry

    Surely this would be a useful feature to add to keys (and enable by default)?

    1. Anonymous Coward
      Anonymous Coward

      Re: Key expiry

      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.

      1. tfewster
        Facepalm

        @DougS - Re: Key expiry

        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.

    2. MyffyW Silver badge

      Re: Key expiry

      @John_Robson A splendid idea, I would find that very useful functionality.

  4. rts

    SSH key management?

    Out of interest, how do people permit SSH key based logons to machines, whilst ensuring that the private key is well protected? Having some meta data within the public key would permit things like expiry / freshness to be enforced.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2022