Even though Secure Shell (SSH) is used for privileged access, most organizations have no inventory of the trust relationships enabled by these SSH machine identities. Many IT organizations haven’t changed or rotated SSH keys because they’re wary of inadvertently increasing the risk of taking down an application if machine-to-machine connections fail.
This concern is largely due to the fact that SSH works through tightly coupled private and public keys. If you update a private key but don’t update all the corresponding authorized public keys, you may cause a critical automated process to stop working. It only takes one of those management meltdowns for IT teams to decide that they never change or touch SSH keys.
![SSH Machine Identity Management for Dummies](/_next/image/?url=https%3A%2F%2Fcdn.venafi.com%2F994513b8-133f-0003-9fb3-9cbe4b61ffeb%2F0dd73fb2-2395-4618-a81a-88783c0adaef%2Faid_field_img__ae16e236c924b71c7338d6151dafccd6.png%3Fw%3D650%26h%3D400%26fm%3Dwebp%26q%3D50%26fit%3Dcrop&w=1920&q=75&dpl=dpl_9nMnPWFgUR3MNGqVKD9tfneGCtKt)
SSH Machine Identity Management for Dummies
Defining the management challenges
Here are some of the main challenges you may face when you attempt to strengthen your SSH machine identity management program:
Difficulty of monitoring SSH usage
SSH is a valuable security asset because it allows strong encryption. However, once data is encrypted, it becomes expensive for security operations teams to monitor the data inside the encrypted channel. Some security administrators have given up on monitoring SSH completely, and it’s not uncommon to hear comments such as “If it’s encrypted, it must be good.”
Setting up key life cycle isn’t an IT priority
Generally speaking, security operations teams aren’t big fans of elaborate approval processes. SSH is no exception. Unfortunately, that includes SSH key life cycles, including obtaining change approvals, assigning, auditing, approving, and rotating SSH keys. Without automated processes, all these life cycle functions can easily become part of an arduous workflow.
Vendor misconfigurations
It’s not only your own IT teams that can create SSH vulnerabilities. Many vendors can inadvertently do it by leaving identical manufacturing root keys on the device to be installed. These keys are easy to get to by just opening a new box but can also be found on the internet.
Rapid adoption of DevOps and cloud
Development operations (DevOps) teams favor SSH access to enable rapid, frequent, and highly automated build and release processes. To accommodate this, cloud service providers offer fast and easy deployment of application services in cloud environments, but this rapid implementation opens more space for errors and misconfigurations by their users.
According to a recent report by Unit42, 32 percent of exposed hosts in public clouds have open SSH services, and 47 percent of the SSH servers on Azure virtual machines had password authentication enabled—making them potentially vulnerable to brute- force attacks.
Seeing the consequences of poor management
Management of SSH keys is most often left in the hands of IT administrators who manually manage them for the systems they control, skipping security best practices or using inconsistent policies. Despite the never expiring and sweeping access they grant, SSH keys are left untracked, unmanaged, and unmonitored by most organizations. A continuously growing set of SSH machine identities creates several risks.
SSH key sprawl
A lack of governance in creation and management of SSH keys can lead to the reckless proliferation of keys, which can, in turn, lead to unauthorized access that’s difficult to detect. For instance, SSH keys delivering privileged access can get duplicated or shared between users, making the connections less private and more prone to attacks.
Lost or stolen SSH keys
SSH credentials can be stolen or compromised in many ways, such as administrators getting tricked by a phishing attack or a malware using one-day vulnerability, which is slowly extracting data. SSH keys are defined in a file, easy to recognize, and stored on both sides of a connection. As a result, malware or malicious insiders can easily misappropriate keys, opening the door for an intruder to start a privileged SSH administrative session. After an SSH key has left your organization, you’re challenged to limit the exposure, and responding can quickly become expensive.
Slow incident response processes
When a security incident occurs, responders need to take action and remove all potential access paths available to the intruder. A dense and uncontrolled mesh of SSH machine identities with hundreds of thousands—if not millions—of keys can be hard to clean up and consumes costly resources, which allows cybercriminals extra time to leverage the privileged access they’ve acquired.
Understanding the SSH machine identity management challenges
That is just one of many reasons SSH machine identity management is such a hurdle for organizations. Several factors drive the increased usage of SSH machine identities and the corresponding escalation of management challenges. When these factors aren’t addressed, you may face severe consequences. Understanding these factors on a deeper level will help you overcome them in your own business!
Get a FREE & Confidential SSH Risk Assessment from Venafi!
Related Posts
![Summit 2024 Teaser Photo](/_next/image/?url=https%3A%2F%2Fcdn.venafi.com%2F994513b8-133f-0003-9fb3-9cbe4b61ffeb%2F537b500f-ee2a-44ba-82b4-d7be0b23506c%2Fsummit-promo-graphic-2.jpg&w=3840&q=75&dpl=dpl_9nMnPWFgUR3MNGqVKD9tfneGCtKt)
Machine Identity Security Summit 2024
Help us forge a new era of cybersecurity
☕ We're spilling all the machine identiTEA Oct. 1-3, but these insights are too valuable to just toss in the harbor! Browse the agenda and register now.