SSH has become the defacto method to access UNIX and Linux computers over the network for several different use cases – from shell access or file transfers, to batch jobs that need to communicate with other computer or apps, to name a few. As with any remote access solution to a system that contains corporate data, centralized authentication and access controls are critical to ensure that only the right users can access that resource in line with the business needs. However the challenge is that SSH Server that is typically configured for remote access on nearly all UNIX and Linux systems supports many different methods of user authentication, and the configuration is defined locally on each system independently.
Current implementations of SSH Server support authentication using one of the following methods:
- User ID & Password – A user or service needs to provide an identity and password to the remote system to login. For service account usage, these passwords are either managed locally within the target system and the client side script or managed via a password vault. Passwords are obviously more difficult to manage and keep private, especially for service account or batch job usage.
- Public Keys – Users can create a public and private key pair, then share their public key on systems where they want to be able to login, then login requires only that the user proves he has the corresponding private key in order to access the system. This authentication method is certainly easy to use for both users as well as service accounts and batch jobs, however they can be easily misused as discussed later.
- Keyboard Interactive – This form of user authentication enables a PAM module to challenge for user identification where the user can enter the required data to be used by the PAM module for verification, which may be ideal for login with a One-Time Password.
- GSSAPI – This interface supports external mechanisms such as Kerberos-based authentication which requires the user to get a Service Ticket for the target system from a Kerberos Distribution Center, or KDC, after user login to the KDC. Environments with Active Directory have a built in KDC in every Domain Controller which makes is much easier for a user to get Single Sign-on to a system with an SSH Server after desktop login to Active Directory. I’ll show you how this works a little later.
In an increasing effort to secure access to UNIX and Linux servers, we centralize management of user accounts into Active Directory with Centrify establishing AD as the authoritative name service for the system. This works to ensure that users are required to authenticate with their own AD user ID and password to their workstation, then upon access to a UNIX or Linux system, they can use either their user ID and password or Kerberos through the GSSAPI support in OpenSSH. However, many times we find that the existing authentication method for SSH access uses Public Keys which admins have put on their servers to simplify access to their account or to make it easier to access the root account.
SSH Key Authentication Challenges
While the use of Public Keys is a strong authentication method, there are several challenges with the implementation of Public Key-based authentication, given the lack of central management of the keys as indicated by the recently published Internal Report by the NIST. This report documents several challenges and best practices with the use of Public Keys for automated login to a remote server via SSH.
NIST Internal Report 7966 (http://csrc.nist.gov/publications/drafts/nistir-7966/nistir_7966_draft.pdf) identified several challenges with Public Key authentication for SSH, such as:
- Vulnerable SSH implementation
- Stolen, leaked, and unterminated SSH user keys
- Backdoors (unaudited user keys)
- Unintended usage of user keys
- Incorrect user key location
I have and always will be an advocate for strong authentication, especially authentication with strong cryptography such as PKI Certificates where PIN/Passphrase or Biometric is used to unlock these strong credentials. They are impossible to spoof as long as the relying party or resource performs the proper validation of the certificate with the Certificate Authority that issued the Certificate. But the main issue with the use of Public Key technology for access to an account over an SSH session is that most of these deployments do not have a Certificate Authority or any other central management system creating and revoking or reissuing the keys used during the authentication. This means that anyone is free to create their own Public and Private Key pair, which increases the security over the wire vs. a password, but does not do anything to ensure that the right person is in possession of the Private Key or that they are still authorized to access that server they are trying to access.
SSH Public Key-based Login Scenario
1) The end user simply needs to create a key pair using either the ssh-keygen command line utility on Linux or Mac systems or by using the PuTTY Key Generator on Windows.
2) The user then needs to copy the Public Key of this key pair over to the Linux hosts that he wants to log into and put it into the right file location, typically ~/.ssh/authorized_keys, although this location is defined within the sshd_config file and could be named anything, so double check the AuthorizedKeysFile value for the exact location and file name.
Note: In this example the user copied his SSH Public Key into the root user’s home directory AND removed his user name identifier from the file which should have been listed at the end of the Public Key as email@example.com.
3) Now the user only needs to launch PuTTY and specify the Private Key file to gain access to a remote system where the SSH Public Key is stored.
Note: The user Tim Wilson who logged into his workstation has gained access to the root account just by using his Private Key to authenticate to his Public Key which he stored in the root user’s home directory. After all, if you were an IT guy responsible for this computer and you needed root, wouldn’t you setup automated login to the root account?
But you access the server only after you have verified you are connecting to the right server based on it’s fingerprint. I’m sure everyone checks the server fingerprint before logging in, right?
Now I hope you can see from my example above that one of the problems with Public Keys is that the end user can store their Public Key as an authorized_key to gain access to any account the user has access to, even temporary access privileges, where he can store his key. And in this case he scrubbed his name from the file to hide the fact that it is his key and OpenSSH happily allowed the user to login with this Public/Private Key pair as the root user without additional verifications. So now even a forensic search for all authorized_keys will not even show who owns the key or who has the ability to access this account.
But, what if this user has a friend who needs access to the same computer as root? It’s pretty easy for the user to just email a copy of the corresponding Private Key to his friend in order to grant access to the system as root, and further there is no way for IT or Security Ops to know which user is actually accessing the computer. In your /var/log/secure file you will see only the entry where sshd opened a session for root with no indication of who the remote user is.
From /var/log/secure on a Red Hat system
Sep 29 18:03:00 finserv1 sshd: pam_unix(sshd:session): session opened for user root by (uid=0)
The Centrify Alternative to Mitigate Risks of Unmanaged Public Keys
There is a solution to this problem. While the NIST provides recommendations on how to manage these SSH Keys, Centrify provides an alternative method to mitigate the risks by eliminating these SSH Keys in favor of a centrally managed authentication based on Active Directory and its built in Kerberos.
Centrify provides an alternative solution based on centralizing access controls via Active Directory. In order to eliminate locally managed security credentials, Centrify automates management of Kerberos on the Red Hat system to enable Single Sign-on for the user while simultaneously securing the authentication via Kerberos Tickets which can be obtained only from Active Directory.
This is the end result of a user who logged into his Windows workstation, then used PuTTY to gain Single Sign-on access via Kerberos to the same Red Hat system I showed above. This time, you can see that PuTTY was able to get a Service Ticket for the host which was validated, identifying Tim Wilson, and then granted access to the user’s account.
Centrify provides a modified version of PuTTY that enables the use of Kerberos for both Key Exchange for Server validation as well as user Single Sign-on for users who have authenticated to Active Directory.
IT also has the ability to automatically configure the settings within PuTTY using Group Policy settings to make sure that PuTTY adheres to the security policies of the company.
IT also has centralized control over the SSH Server Configurations (in sshd_config) via Group Policy on all Linux and UNIX systems that are joined to Active Directory with Centrify.
Additionally, Centrify provides several access controls for the OpenSSH Server so IT can grant access much more granularly, such as granting only shell access or maybe only scp-based file access without giving rights to the shell. This set of capabilities does require the OpenSSH Server binary that Centrify provides free to our customers for all platforms.
Centrify eliminates the usage of SSH Public Keys by leveraging Active Directory and its built in Kerberos for strong authentication that ensures accountability and centralized control over user authentication to the Linux, UNIX or Mac systems running SSH. Leveraging Kerberos for authentication eliminates the requirement to verify a server’s fingerprint since computers authenticate to the user the same way that the user authenticates to the server, via Kerberos Ticket verification which cannot be spoofed. This model works well in high security environments where Smart Cards are required for user authentication to meet HSPD-12 requirements since the user will login to AD from their workstation with their Smart Card. Once authenticated where they can get their Kerberos Ticket Granting Ticket (TGT), they will be able to request a Service Ticket for the desired computer they are trying to authenticate against, which identifies the user to the destination computer and is encrypted so that only the destination computer can decrypt and read its contents. This is simply a much more secure and centrally managed environment than other methods of authentication to an SSH Server.
Additionally, Centrify provides centralized granular access controls and configuration controls to ensure that users gain access only to the SSH interface they need and that the desired configuration is enforced on all computers, both client with PuTTY and servers running OpenSSH, through the use of Group Policy-based configuration. This ensures that IT is in control of which users can authenticate to the server, how they connect and how they authenticate such as via Kerberos. These controls enable IT to prevent anyone from logging in as root over the network, as well as to terminate inactive sessions as required by most security policies that I’ve seen enforced by our customers.
If you want to try out Centrify on your Linux or UNIX or Mac systems, click here http://www.centrify.com/products/try-it-buy-it.asp to request a free trial.
Thanks for reading