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

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 CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags ShellPonemon Institutebeca

More about RSASSHSSH CommunicationsSSH Communications SecurityTechnology

Show Comments
[]