Consider this true story: An auditor asked a developer how he gained access to his development environment to perform his daily tasks. The developer explained that the process involved going through a jump host, allowing him to access the needed servers. This process oversees the commands used and actions taken during his sessions.

Satisfied, the auditor turned to leave, before the developer added, “But I don’t go through the jump at all. I use SSH keys and it makes my life a whole lot easier!”

The auditor stopped in her tracks.

“I use SSH keys,” the developer continued, “so I don’t need to constantly retype my password, can access the hosts I need to, get my work done quickly, and move on to the next. Here, let me show you how easy I can set them up myself.”

Guest article by Matthew McKenna, Chief Strategy Officer, SSH Communications Security

This is an example of just what can go wrong in the arena of SSH user keys: The SSH protocol is one of the security industry’s greatest known unknowns. 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 — SSH has been quietly and efficiently providing encrypted and trusted access for two decades.

Yet, the power it actually harnesses is widely unknown and, consequently, creating a major gap in identity access postures and risk to the resilience of enterprises.

Several things are worthy of note with respect to SSH user keys. First, it 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.

Compliance is not a matter to be ignored. In fact, there are a few key issues that can easily come back to bite an organization if not dealt with proactively.

Rooting out the problem

IT understands that root access is an unfortunate necessity. When not controlled correctly, it represents the greatest resilience risk. When it comes to SSH keys, a blind spot exists. When setting up any SSH user key, it is possible to put what is known as an IP Source restriction on a key, determining 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 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.

Preserve to protect

With SSH user keys, preserving the segregation of duties is a must. There are three components related to the preservation of segregation of duties that need to be considered:

Sidestepping jump host architecture

In terms of interactive access related to SSH user keys, many think: “We have this under control. All the users are required to go through our privileged access management solution and are controlled from there.” The issue that is becoming more evident to the security operations is outlined in the above developer example. That example demonstrates the fact that jump server architectures are frequently used to control users’ access to a destination server.

The challenge here is that a user can generate an SSH user key on that destination server and bypass the jump server in the future. This would bypass any monitoring capabilities of that jump server and potentially make actions taken by the user more difficult to track. More concerning is if that user has the possibility to elevate privilege from that server, and from there, deploy new keys.

Connecting environments

The second problematic aspect of segregation of duties is the connectivity from non-production environments to production environments. 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 permits 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.

Not using transitive trust and agent forwarding capabilities of SSH properly

The concept of transitive trust is a question of how deeply a single key or user may be able to penetrate the infrastructure utilizing key-based authentication. Again, when SSH user keys don’t 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.

Who is the keymaster?

A sound SSH user key and access management strategy must include the monitoring of key-based authentication. 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 to gain control of environments, whereas without key-based activity monitoring, companies are unable to assess whether keys are obsolete or not (remember that 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 used).

Auditors are sharp: They understand the critical nature of SSH keys and will look for any hint of non-compliance. As a cautionary tale to others, Erik Vorhees, CEO of Shapeshift, wrote a detailed article about how someone used SSH keys to steal from his company. Organizations can’t treat this as a backburner issue any more — this “known unknown” poses real risk to both identity access postures and to compliance posture.

matthew_mckennaMatthew 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 Automaster Oyj, which was successfully acquired by ADP Dealer Services Nordic. Before this, Matthew played professional soccer in Germany and Finland.

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

Subscribe To Our Newsletter Today and Receive the Latest Content From Our Team!

Subscribe To Our Newsletter Today and Receive the Latest Content From Our Team!

You have Successfully Subscribed!