Helping Customers Overcome SSH User Key Compliance Concerns
By Matthew McKenna, Chief Strategy Officer, SSH Communications Security
SSH has been doing its job of providing encrypted, trusted access for the last two decades. It is used by 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, creating a major gap in organizations’ identity access postures and risk to the resilience of their enterprises.
SSH user keys are the only form of access that can be provisioned without oversight. Additionally, SSH user keys, unlike SSL certificates, have no expiration dates. Finally, SSH user keys provide not only user-based access but also access for service accounts, which move data between applications for critical transactions.
VARs must be well versed in the three major concerns that can derail compliance for customers.
Illegal Root Access
When not controlled correctly, root access represents the greatest resilience risk. When setting up any SSH user key, it is possible to put 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, over 90 percent of the time, the IP source restriction is simply forgotten. In the worst case, if there are public-facing servers or services and that private key is acquired maliciously or accidentally, it can now access that asset from anywhere.
Preserving The Segregation Of Duties
This concern breaks out into three elements:
- Connecting Environments
The connectivity from non-production environments to production environments is problematic. This happens for both interactive 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.
- Skirting Jump Host Architecture
Jump server architectures are frequently used to control users’ access to a destination server. 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 would potentially make the user’s actions more difficult to track. It’s even worse if that user has the capability to elevate privilege from that server and from there deploy new keys.
- Wrongly Using Transitive Trust And Agent Forwarding Capabilities Of SSH
Transitive trust is about how deeply a single key or user can penetrate the infrastructure using key-based authentication. Again, when SSH user keys do not have IP source restrictions or forced commands dictating what a user may do, 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.
Access Management Via Key Monitoring
Monitoring key-based authentication is a critical factor in solid SSH user key and access management. 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 IT’s 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 gaining control of the environment, whereas without key-based activity monitoring, IT is unable to assess whether keys are obsolete or not. Remember, SSH user keys do not have expiration dates, so customers may find that up to 90 percent of the keys in their environments are no longer being used.
Organizations want to keep their data safe and remain compliant — that’s a given. What’s not a given is whether they have a handle on their SSH key management. VARs can help steer their customers toward best practices and solutions that will keep their customers out of compliance hot water.
Matthew 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.