SSH User Key Management for Security and Compliance

Featured article by Matthew McKenna, chief strategy officer, SSH Communications Security

Here’s an example of how SSH user keys can be misused and abused. In order to gain access to a development environment, developers go through a jump host, which allows them to access the servers they need. It oversees the commands they use and actions they take during their sessions.

However, developers often don’t follow this process. Instead of going through the jump host, they create SSH keys for the sake of convenience. With these keys, they don’t need to constantly retype their passwords, can access the hosts they need, get their work down quickly and move on to the next task. This is not the kind of thing you want an auditor to uncover.

SSH has been quietly and efficiently doing its job providing encrypted, trusted access for the last two decades. It is used as the tool of choice for administrators around the world to remotely access servers and network devices as well as securely transfer data between applications. Yet the power it actually harnesses is widely unknown and, consequently, creating a major gap in our identity access postures and risk to the resilience of our enterprises. The SSH protocol is one of the security industry’s greatest known unknowns.

SSH user keys have several distinctive characteristics that can become problematic. First, this is the only form of access that can be provisioned without oversight. Second, SSH user keys, unlike SSL certificates, have no expiration dates. So they continue to provide access until they are eliminated from the systems on which they reside. And finally, SSH user keys provide access not only for user-based access but also for service accounts, which move data between applications for critical transactions.

Clearly, any one of these features is a GRC headache at best and a nightmare at worst.

Here are three major concerns that can easily cause trouble down the line.

1. Maintaining Segregation of Duties

SSH user key management must take into account three components related to the preservation of segregation of duties:

Abuse of SSH’s transitive trust and agent forwarding capabilities

How deeply may a single key or user be able to penetrate the infrastructure using key-based authentication? This is the question of transitive trust. Again, when SSH user keys do not have IP source restrictions or forced commands dictating what a user may do during a session, it becomes a question of how far that user can continue to gain access within the environment with their privileges. So in this case, the user may access one server, elevate privilege, drop in new keys and gain access to another server. From there, they may use the sub-channels of the SSH protocol to create connectivity back to their home desktops or other servers, bypass corporate firewall policies and exfiltrate critical data without being noticed.

“Outsmarting” the jump host architecture

Many organizations assume that they have interactive access related to SSH user keys under control. After all, the users are required to go through their privileged access management solution and are controlled from there. The issue that is becoming more evident to the security operations is outlined by the developer example that opened this article.

Jump server architectures are routinely used to control users’ access to a destination server. The challenge here is that a user can generate themselves an SSH user key on that destination server and bypass the jump server in the future. That in itself would bypass any monitoring capabilities of that jump server and would potentially make actions taken by the user more difficult to track. More concerning than this is if that user has the possibility to elevate privilege from that server and from there deploy new keys.

Connectivity between environments

Connectivity from non-production environments to production environments is another

aspect of segregation of duties that is problematic when it comes to SSH user keys. This happens for both interactive access and non-interactive access.  With interactive users, the challenge is closely related to the bypassing of jump server architecture. The user comes through the jump host to the non-production environments as usual, uses tunneling (a sub-channel of the SSH protocol) to tunnel across to a production server and from there may drop in a new key pair, which will permit access again directly from their desktop to a production environment. Now, this is a real red flag in most regulated IT environments, but it happens much more frequently than you may expect.

2. Gaining Control of the SSH Environment

The monitoring of key-based authentication must be controlled. All privileged access must be controlled and monitored according to the majority of compliance mandates; however, key-based authentication is ignored, as is where SSH user keys are authenticated from – and how frequently. Fortunately, this information sits at our fingertips and, as long as VERBOSE logging is enabled on the SSH server, the logs for key-based authentication can be easily captured. This information is essential in us gaining control of our environments, whereas without key-based activity monitoring, we are unable to assess whether keys are obsolete or not. Remember, SSH user keys do not have expiration dates, so you may find that up to 90 percent of the keys in your environment are no longer being used.

3. Dealing with Root Access

The greatest resilience risk in the IT admin world is root access that is not controlled correctly. When it comes to SSH keys, here’s the blind spot that exists. When setting up any SSH user key, it is possible to put what is known as an IP Source restriction on a key, which will determine from what IP source the key may authenticate from and what destination server it has access to. Unfortunately, in over 90 percent of the cases, when root keys are being generated, the IP source restriction is simply forgotten.  What does this mean? In the worst case, if we have public-facing servers or services and that private key is acquired maliciously or accidentally, it can now access that asset from anywhere.

Taking the Initiative

It’s only a matter of time—and the time is short—until auditors will be scrutinizing SSH keys like never before. They are passwords without expiration dates, and if they fall into the wrong hands, theft of data and loss of reputation will occur. These keys are highly vulnerable if not managed properly, and organizations must start planning now to gain control of this critical infrastructure element.

Chief Strategy Officer

Matthew McKenna brings over 10 years of high technology sales, marketing and management experience to SSH Communications Security and is responsible for all revenue-generating operations. His expertise in strategically delivering technology solutions that anticipate the marketplace has helped the company become a market leader.

Prior to joining the company, Matthew served as a member of the executive management team of ADP Dealer Services Nordic and Automaster Oy, where he was responsible for international channel operations and manufacturer relations. In addition, he was responsible for key accounts including Mercedes Benz, General Motors, and Scania CV. Before this, Matthew played professional soccer in Germany and Finland.

Matthew holds a Bachelor of Arts degree in German from the University of South Carolina and an MBA from the Helsinki School of Economics and Business Administration.