Buckle Up: What NIST has to say about Secure Shell

If I told you today I would cover all your expenses and you could choose between a Novell CNE or a Microsoft MCSE certification, which would you choose?  I’m guessing a snap decision through today’s lens would be easy.  Back when I had this choice, the answer wasn't so obvious.  In fact, I ponied up for my CNE.

 Before I start defending that call, let’s just say it’s all moot now.  The CNE helped open a door but I never really put the training into practice. One day I was muttering about IPX/SPX and the next day I was on the command-line learning Sun Solaris.  The why is a story for another day but Solaris and I bonded over the better part of the next decade.

 In those times it wasn't uncommon to use telnet, especially for dev systems.  Not just telnet, we had dev systems still running the r* protocols.  Of course, at one point in history it used to be optional to wear a seat belt.  Nowadays we buckle up when we drive, and we don’t use telnet. That brings us to Secure Shell (SSH).  Let’s put our seat-belt on and look at a recently published NIST draft titled “Security of Automated Access Management using Secure Shell (SSH)”.    The 41 pages cover topics including SSH basics, vulnerabilities, recommended practices and guidance on planning and implementation. 

 Let’s focus on user authentication.  The NIST draft gives a nice overview of the various supported authentication options with SSH.  For the Kerberos option...we've seen the popularity of this option grow over the last decade.  Dell provides a solution that allows Unix systems to integrate with Active Directory.  

 The integration of Unix with Active Directory opens several new avenues like using Group Policy to managing Unix (and Mac) machine/user settings and eliminating the need to provision local users for Unix/Mac access.  In the context of SSH, joining Unix to Active Directory enables a scenario where an administrator can authenticate to their Windows desktop, open a popular SSH client like PuTTY, and get direct single sign-on access to a remote Unix system.  No more typing a username/password for access as the SSH client and server take advantage of the underlying Kerberos infrastructure.

 The NIST draft rightly points out the potential for unwanted implicit trust relationships when using Kerberos.  However.  Most all current AD Bridging technologies provide a solution in the form of granular host-based access control.  The solution enables an administrator to dictate precisely which AD user is permitted to authenticate to which system.  SSH is not directly enforcing the solution but the concern over unfettered implicit trusts is mitigated thru the host-based access control mechanism.

 Another common question that comes up when using SSH with Active Directory integration:  If I choose to use SSH key pairs for authenticating an Active Directory user, what happens if I need to disable the AD user’s access?

 In this scenario, SSH is configured for Public Key Authentication via keys.  However, instead of the user being local to the /etc/passwd file, the user account is actually located in Active Directory.  This is possible as the AD integration solutions typically provide both PAM and NSS modules.  When properly configured, if you disable the Active Directory user account, and the user account was authenticating via key pair, the user authentication will be denied.   This happens by design when PAM properly supports the session check – regardless of how the user authenticates, the PAM session check will catch that the AD account is disabled and therefore deny access despite having a valid key pair.

 The NIST draft is worth an overview if it’s been a while since you reviewed your SSH implementation.  And if you have a good tip for automating SSH access where passphrases are enabled on public/private keys, please share.