Secure Shell (SSH) key management is a critical security issue. After all, SSH keys act as a password of sorts to grant entry into an organization’s operating system. As organizations tackle the challenge of SSH user key and access management, they typically do so in one of three ways.

A cryptographic team, which may already be managing certificates and other public key infrastructure (PKI)-related issues, may head up the project. The challenge may also be dealt with as part of a privileged access management project. The third approach has organizations dealing with key management as part of their configuration management system processes.

Any one of these approaches is acceptable – except that each of them is missing critical components needed to gain comprehensive control and an understanding of the challenge at hand.

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

The crux of the matter is that the purpose of SSH user keys are to grant access, and they do it either for interactive flesh-and-blood users or, even more frequently, for file transfers and application-to-application connections. Beneath all of this are important factors such as the usage of proper cryptographic standards, as well as proper controls of the SSH daemon configurations in an environment. When managed properly in unison, organizations can achieve the maximum effect of risk reduction, resilience, and compliance.

Let’s explore each of the areas further.

Three Key Management Best Practices

If we want to effectively address SSH user key issues in our environments, we need to understand, first and foremost, what access-related risks we are interested in addressing. At the end of the day, SSH provides access to our most critical infrastructure, and risk reduction and resilience are of the highest priority. Here are three best practices, or pillars, on which to build successful key management projects.


Clearly, it’s important to get control of which key-based access may have root access in your environment, and, more importantly, how deep the transitive trust of this access extends. The question to be answered here is, “If I breach one root key, how deeply can I penetrate into the environment?

Next, we need to understand which key-based trusts are for interactive usage, and which are related to service accounts. Each key-based trust, regardless of its usage, should be assigned back to an individual owner in the environment to establish accountability.

Where SSH user key-based trusts are in use, it is critical to ensure the clear segregation of duties. This means having a clear understanding of what key-based connections may be running across development to production environments, and re-establishing clear IP source and command restriction accountability of all key-based access within the production environment.


Cryptographic standards and good practices in this area should not be underestimated. The disconnect from projects being run by PKI organizations is the idea that we need to manage SSH user keys in the same way that we do for certificates. The significant difference between SSH user keys and certificates is that SSH user keys have no expiration dates. And whereas a service may go down if a certificate is not rotated, SSH user keys provide access and will continue to exist if not removed after an application is decommissioned, or an administrator leaves an organization.

Cryptography standards are clearer and can be better controlled through improved processes around provisioning and trust rotation. The essentials are key size, key algorithm, and key age. Additional components for consideration are passphrase protections related to private key controls and the elimination or rotation of SSH1 keys regardless of status and use case.

Once you have a baseline visibility of the environment in terms of the SSH user key-based trust relationships that exist, getting cryptographic policies under control for remediation and future provisioning is easier to manage.

Additionally, the remediation of cryptography-based policies poses a lower remediation risk and high security value versus access-related remediation, which has a higher remediation risk, but the highest security value.

Configuration management

How is this topic related to SSH user key- and access-based controls? Good, standardized SSH daemon configuration management is frequently overlooked in terms of how we can better lock down access in our environments and decrease risk.

With good configuration management, we can standardize key locations and ensure unified version management, control access-related controls such as which sub-channels of the protocol may or may not be used, deny root access and restrict deprecated SSH versions and algorithm usage, as well as control login restrictions and log how frequently and from where keys are being used. These controls, when implemented properly, already provide us a good baseline of control in our environment and SSH usage.

Creating a Trustworthy Environment

When all is said and done, what drives effective SSH user key and access management is the establishment of what access controls we have to mitigate risk, ensure resilience, and achieve compliance. Only from there, and after we have visibility of the SSH user key-based trust relationships in our environment and can effectively monitor their usage, can we remediate access and improve the way we provision, remove, and rotate access. Strong cryptographic controls and strong configuration management practices are extremely important supporting roles to achieve our access-related objectives.

The reason for enacting these three best practices is to create an environment in which we understand, control, monitor, and analyze every SSH user key-based trust. More significantly, each key-based trust will have an assigned owner, no matter its purpose. Achieving this goal will create a more secure network and enable IT security teams to sleep better at night.

For additional information on SSH, see the free content from Aberdeen Group, Shhhh…It’s SSH: The Keys to the Enterprise, Left Under the Doormat.

matthew_mckennaMatthew McKenna brings over 15 years of high technology sales, marketing, and management experience to SSH Communications Security, and drives strategy, key account sales, and evangelism. 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.

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!