Auditing and management of secure shell (SSH) keys is crucial for avoiding exploits of a rarely discussed security flaw in the protocol. But, until recently, there have been few best practices to help guide you in auditing and managing SSH. Now, a new draft document from the Internet Engineering Task Force (IETF) provides a roadmap for SSH key auditing and management.
A few months ago, I reported on a rarely discussed security flaw in the SSH protocol that is exposed when using locally managed keys for machine-to-machine communications. These are encryption passwords that are commonly set one time and rarely changed or tracked. Additionally, these local keys are often copied and used on multiple servers within an organization. What ends up happening is that these keys can get out into the open, allowing anyone with the key to authenticate to your systems. This is why it is so essential that your SSH keys be audited, organized and managed.
Usually when you think about IETF Request for Comments (RFC’s), you think of technical specifications for new or modified network protocols. But every once in a while, RFC’s are written so that users of an existing protocol can better understand how to work with them properly. These are known as Best Current Practice (BCP) RFC’s. And if one is written, usually it means that there is a distinct lack of understanding regarding a technology that needs to be addressed. SSH is apparently one of those technologies.
Potential threats if SSH keys are not secure
The IETF draft provides technical details behind the protocol, as well as possible threats that can occur if SSH keys are not secured. The RFC reads very much like a how-to document to discover SSH keys within your network and how to find and map machine-to-machine relationships. Once these relationships are mapped, the RFC gives details regarding how to move all of your keys to a trusted location for centralized management.
While this RFC best-practice guide is a great resource for the current-generation of SSH, I believe that key management within the protocol suffers from two problems that need to be addressed — possibly to the point of changing the protocol itself.
First of all, I struggle with the fact that SSH keys can be duplicated across multiple systems. This is a major security flaw that could expose your entire network. Second, even if your server administrators do create unique keys for each machine-to-machine connection, the RFC recommends that we put all of our keys in one centralized location. While this gives you a simplified solution in terms of key management, it also makes your key management server a one-stop shop for hackers.
By all means, read through the RFC and use the guide to get a better handle on your current SSH keys in use today. Clearly, most of us are doing a poor job of this and we should take advantage of the easy-to-understand guide. But I hope that we can also take the SSH protocol one step further and look to improve key management so that we can fix these problems instead of simply working around them.
About the Author
Andrew Froehlich is a network engineer and contributor to EnterpriseEfficiency.com, a UBM Tech community.Tags: Security,Technology