NIST issues Best Practices on how to best use Secure Shell software

NIST's drafted recommendations warn sys admins of pitfalls in SSH use that give attackers the advantage.

The Secure Shell (SSH) protocol and software suite is used by millions of system administrators to log into application and service accounts on remote servers using authentication methods that include passwords, tokens, digital certificates and public keys. But when improperly managed, SSH keys can be used by attackers to penetrate the organization's IT infrastructure.

A Ponemon Institute study earlier this year of more than 2,100 systems administrators at Global 2000 companies found that three out of the four enterprises were vulnerable to root-level attacks against their systems because of failure to secure SSH keys, and more than half admitted to SSH-key-related compromises.

+ ALSO ON NETWORK WORLD Poorly managed SSH keys pose serious risks to most companies +

Because of rising concerns about this, the National Institute of Standards and Technology (NIST) has formulated a 37-page "best practices" guidance for SSH key management. Here are some highlights in what NIST in its draft document, "Security of Automated Access Management Using Secure Shell (SSH)" is telling sys admins to do:

- NIST says there are two kinds of password authentication mechanisms in SSH: basic password authentication and keyboard-interactive authentication.

Basic password authentication is said to be a "legacy method mandated by the SSH protocol standards," while keyboard-interactive authentication "is used in most modern environments, and can support challenge-response authentication and one-time passwords in addition to traditional password authentication." NIST recommends that password authentication should generally not be used for automated access because hard-coded passwords can be obtained by attackers. If an organization does use password authentication for automated access, the passwords should be rotated frequently in accordance with the organizations password policy.

- Host-based authentication uses the server's host key--the key used by the client to verify the server's identity--to authenticate the source host and to vouch for the identity of the user on the client side. However, NIST points out that because host-based authentication does not permit configuring command restrictions (limits on what can be done on the server with the access), use of host-based authentication for automated access is "not recommended."

- Many organizations use Kerberos or Active Directory authentication with SSH for single sign-on within a Windows domain or Kerberos domain. NIST notes that some widely used SSH implementations provide single sign-on within an Active Directory domain or Kerberos realm by default. But NIST points out single sign-on "implies that once access has been gained to one account using Kerberos, it is possible to log in to any other server that has the same account and is into the same domain (with single sign-on permitted) without further authentication. This can easily create lots of unwanted implicit trust relationships. Another concern is that currently widely used SSH implementations do not support command restrictions for Kerberos. Because of these problems, the use of Kerberos authentication for automated access is not recommended."

- Public-key authentication in SSH makes use of the user key or certificates to authenticate a connection, with an SSH client having a user key called an "identity key," typically an RSA or DSA private key, with the server requiring the corresponding public key configured as an "authorized key" for a user account. Any user in possession of the identity key is then allowed to log into the server to that user account and perform actions under the privileges configured for the key, NIST points out. The identity key is often stored on a smartcard or in a password-protected file. NIST says many SSH implementations support configuring restrictions for authorized keys to limit what can be done on the server using the key (command restrictions) and from limiting the IP addresses from which the key can be used (source restrictions). NIST says an advantage of public-key authentication is that "it does not create any implicit trust relationships, only expressly-defined trust relationships." Permitted access can be determined by inspecting the destination host, which is important for being able to audit who can access what system and account. Because of the advantages seen with public-key authentication, NIST calls it "the recommended authentication mechanism for automated access with SSH."

The NIST guidance document (NIST 7966 draft) is out for comment until the end of the month, includes a wealth of other security management recommendations related to use of SSH software implementations as well as a "tool selections" guide covering vendors such as Fox Technologies, SSH Communications Security, and Venafi.

Join the CSO newsletter!

Error: Please check your email address.

Tags network securityShellsecuritybecaPonemon Institute

More about RSASSHSSH CommunicationsSSH Communications SecurityTechnology

Show Comments

Featured Whitepapers

Editor's Recommendations

Solution Centres

Stories by Ellen Messmer

Latest Videos

  • 150x50

    CSO Webinar: Will your data protection strategy be enough when disaster strikes?

    Speakers: - Paul O’Connor, Engagement leader - Performance Audit Group, Victorian Auditor-General’s Office (VAGO) - Nigel Phair, Managing Director, Centre for Internet Safety - Joshua Stenhouse, Technical Evangelist, Zerto - Anthony Caruana, CSO MC & Moderator

    Play Video

  • 150x50

    CSO Webinar: The Human Factor - Your people are your biggest security weakness

    ​Speakers: David Lacey, Researcher and former CISO Royal Mail David Turner - Global Risk Management Expert Mark Guntrip - Group Manager, Email Protection, Proofpoint

    Play Video

  • 150x50

    CSO Webinar: Current ransomware defences are failing – but machine learning can drive a more proactive solution

    Speakers • Ty Miller, Director, Threat Intelligence • Mark Gregory, Leader, Network Engineering Research Group, RMIT • Jeff Lanza, Retired FBI Agent (USA) • Andy Solterbeck, VP Asia Pacific, Cylance • David Braue, CSO MC/Moderator What to expect: ​Hear from industry experts on the local and global ransomware threat landscape. Explore a new approach to dealing with ransomware using machine-learning techniques and by thinking about the problem in a fundamentally different way. Apply techniques for gathering insight into ransomware behaviour and find out what elements must go into a truly effective ransomware defence. Get a first-hand look at how ransomware actually works in practice, and how machine-learning techniques can pick up on its activities long before your employees do.

    Play Video

  • 150x50

    CSO Webinar: Get real about metadata to avoid a false sense of security

    Speakers: • Anthony Caruana – CSO MC and moderator • Ian Farquhar, Worldwide Virtual Security Team Lead, Gigamon • John Lindsay, Former CTO, iiNet • Skeeve Stevens, Futurist, Future Sumo • David Vaile - Vice chair of APF, Co-Convenor of the Cyberspace Law And Policy Community, UNSW Law Faculty This webinar covers: - A 101 on metadata - what it is and how to use it - Insight into a typical attack, what happens and what we would find when looking into the metadata - How to collect metadata, use this to detect attacks and get greater insight into how you can use this to protect your organisation - Learn how much raw data and metadata to retain and how long for - Get a reality check on how you're using your metadata and if this is enough to secure your organisation

    Play Video

  • 150x50

    CSO Webinar: How banking trojans work and how you can stop them

    CSO Webinar: How banking trojans work and how you can stop them Featuring: • John Baird, Director of Global Technology Production, Deutsche Bank • Samantha Macleod, GM Cyber Security, ME Bank • Sherrod DeGrippo, Director of Emerging Threats, Proofpoint (USA)

    Play Video

More videos

Blog Posts

Market Place