8 SSH Key Management Best Practices to Use Right Away

8 SSH Key Management Best Practices to Use Right Away

1 Star2 Stars3 Stars4 Stars5 Stars (11 votes, average: 5.00 out of 5)
Loading...

63% of users surveyed in a Keyfactor/Ponemon Institute report consider SSH keys as the most important machine identity to manage and protect — yet all the evidence suggests that we don’t take as much care with securing these keys as we should! So, let’s look at some SSH key management best practices to make your IT systems more secure.

In a previous article, we explored what passwordless SSH is and why it’s beneficial to organizations. But what is SSH key management itself? To recap, SSH is used to create a secure line of communication between a client and a server over an otherwise open channel. Commonly used by admins, SSH is a secure communication channel that can be secured using passwords or via public key cryptography (i.e., passwordless SSH).

SSH key management is, essentially, the practice of managing those critical admin keys so that you know at all times:

  • How many SSH keys exist,
  • Where they’re stored,
  • Who they’re assigned to, and
  • Whether they’re valid.

Although passwordless SSH is easier to use and usually more secure than using passwords, SSH key management requires proper planning. According to the same Keyfactor/Ponemon Institute report, 53% of the enterprises surveyed don’t have centralized management processes. So, what does this mean for businesses?

Let’s look at what happens when SSH keys are not managed properly. After that, we’ll explore some of the best practices you should follow to manage SSH keys and keep your organization secure.

What Happens When SSH Keys Are Mismanaged

IBM Security reported that the average data breach in 2020 cost businesses a staggering $4.24 million. The report also said that in 20% of breaches, the initial vector was compromised credentials. These figures highlight the importance of establishing and maintaining effective SSH key management systems in any company.

Mismanaged SSH keys are insecure and can result in serious consequences for any enterprise. Below are some of the results of mismanagement of SSH keys:

  • Vulnerability to cyber attacks, which could result in data breaches.
  • Noncompliance violations of various government regulations, including
    • General Data Protection Regulation (GDPR),
    • Health Insurance Probability and Accountability Act (HIPPA),
    • California Consumer Privacy Act (CCPA), and
    • Payment Card Industry Data Security Standards (PCI DSS).
  • Loss of trust among consumers due to data breaches.

So, now that we know what can happen when SSH keys are mismanaged, let’s look at some ways you can up your SSH key management game.

8 Best Practices for SSH Key Management

SSH allows us to use public key infrastructure (PKI) to generate and use SSH keys for encrypted communication. However, in many cases, organizations don’t give enough thought to the management of their SSH access secrets. Mismanagement of SSH keys can lead to many dire circumstances, including cyberattacks and data breaches.  

Let’s have a look at some of the best practices for using passwordless SSH.

1. Maintain an Accurate Inventory of Keys (and Disable Old Ones)

Keyfactor and the Ponemon Institute report that 57% of the organizations surveyed don’t have an accurate inventory of SSH keys. Of course, a proper cryptographic key inventory entails knowing not just what keys you have, but also where they’re stored and who they’re assigned to (or who has access to them).

Why is SSH key management so crucial? Cybercriminals know to obtain the private keys from a target’s device straight after hacking into their system. They can then use these private keys to escalate privileges on the device before moving on to search for the next vulnerable device on the network. Without an accurate inventory of keys, you’re vulnerable to attack.

As with other asymmetric cryptographic keys, SSH keys come in pairs. The private keys are stored on the client device and the public key is stored elsewhere accessible (typically on a server or network device). Most of the time, users don’t bother to delete these keys after their contract has expired or their work is complete. As such, this means that their private keys stay active on the device until they are expressly deleted.

If not deleted in time, the stored private keys could be responsible for a full-blown cyber attack, allowing hackers to impersonate the users to access to whatever resources they have permissions for.

2. Maintain a Current Whitelist of Authorized Users

The developer of SSH, Tatu Ylonen, and his team found that some companies had up to 10 times more SSH keys than users. These companies didn’t bother to delete or deactivate users’ accounts when they left the organization, leading to old keys piling up. This means previous users could still access the organization’s servers remotely, even after their contract was terminated, if the certificates were installed on devices that they continued to have access to.

This is a major risk factor when a disgruntled employee has this kind of access. Imagine the damage one of your employees could cause within your business.

How do you prevent this type of situation from occurring? One way to keep out unwanted users is to create a whitelist of current genuine users. Only whitelisted IP addresses should be authorized to access the servers with SSH. Remove IP addresses from the whitelist as soon as they no longer require access. Because IoT devices lack the security provided by other devices, no IoT devices should be permitted access (even temporarily) to sensitive information.

3. Only Grant Access to Essential Authorized Users

A judicial approach to who can access your systems should be coupled with controls over how much of the system they can access. You should always restrict how much access should be provided to each user. For example, if a contractor doesn’t need access to a certain part of the server, they shouldn’t be assigned permissions to do so.

While access management might sound like a lot of work, it’s a necessary function to keep your organization and data secure. If you allow all users access to every aspect of the server, you leave your organization open to attack. The more users who have access, the bigger your attack surface becomes. Providing limited access to users is a business requirement and a legal requirement, as mentioned in many of the data regulations we mentioned earlier.

4. Assign Key Management Duties to Specific People

SSH keys can be generated easily using simple commands. This advantage can quickly transform into a disadvantage if carried out by someone with bad intentions or ill-gotten access.

Due to the simplicity of generating new keys, anyone who has privileged credentials can create and configure new keys at their convenience. This practice of willy-nilly keygen resulting in more and more keys piling up and ultimately leading to mismanagement of the keys. Startlingly, Ylonen found that 90% of stored keys are no longer needed.

Both these problems have one simple solution: assigning the configuration and management of keys to specific people whose duties should include:

  • Generating and configuring new keys
  • Deleting keys once the projects that require them are complete
  • Defining the amount of privilege any user should have
  • Maintaining a current register of authorized keys
  • Changing SSH credentials regularly

Keyfactor’s data also shows a breakdown of how survey respondents say their organizations manage SSH credentials. The following bar chart is based on their answers:

A bar chart that breaks down how organizations approach key management
A graph showing how organizations managed SSH credentials. Data source: Keyfactor.

Do you see the 47% that say they use manual tracking methods? While this is possible if you’re managing a handful of keys, it can quickly get out of hand as people come and go from your organization. Don’t leave your security to chance by allowing SSH keys to become lost or otherwise forgotten…

5. Use a Reliable SSH Key Manager

An SSH key manager is a tool that allows you to manage your organization’s SSH keys easily by automating some of the functions that would otherwise be performed manually. It helps your IT department to control key sprawl and orphaned key issues.

Key sprawl is when the number of keys keeps on increasing over time, ultimately making it impossible to manage the keys efficiently. Keys are generated to establish a secure SSH connection, and then those keys are forgotten, never to be used again. Another set of keys is generated when the SSH connection is established the next time.

As the name suggests, orphaned keys are the authorized public keys whose corresponding private keys’ location is not known. This happens when an employee who has the private key has left the organization or is no longer in the same position but still has access to the private key.

A few examples of reliable SSH key managers are:

6. Rotate SSH Keys

As the task name implies, SSH key rotation means replacing your organization’s old SSH keys with new ones. This process should be carried out regularly in every organization to minimize risks. However, many organizations don’t rotate keys as often as they should, leaving them vulnerable to cyber threats.

Keyfactor’s research shows that SSH key rotation is often not regularly carried out. Keyfactor reported the following figures when they asked individuals how often their organization rotated SSH credentials:

SSH key management key rotation practices
Data source: Keyfactor-Ponemon State of Machine Identity Management 2021

But how often should you be swapping out your keys? Trend Micro recommends rotating SSH keys every 45 days. However, don’t do so without a plan in place for how those keys will be rotated.  

When a user has established a connection with an SSH server without checking the authenticity of the public key, a cybercriminal might slip their own fraudulent public key in as the public key of the server, leading to a man in the middle attack. This is a “rogue key” — a malicious public key supplied by an attacker in the guise of a legitimate SSH server public key. When keys are rotated regularly, vulnerabilities like orphaned and rogue SSH keys can be mitigated.

7. Define an Invalidation Term for Your SSH Keys

Another healthy practice for a secure SSH environment is to set an end-of-life date for all SSH keys that invalidates them after a certain point. Your policy should include a period after which SSH keys should be deleted manually. This will help to prevent cyber threats in the long term as unused or forgotten keys are an easy target for cybercriminals.

Additionally, utmost care should be taken to ensure that all keys belonging to employees who leave the organization should be deleted — or, at the very least, invalidated — on the spot. Failing to do so will leave a working key and allow the person access to your system. Varonis found that most employees have access to almost 11 million files. If an unhappy employee who leaves the organization has continued access to files, they can easily cause a lot of damage.

8. Use Updated Versions of the SSH Protocol

When the SSH protocol is not updated to its latest version, you make yourself vulnerable to cyberattacks. Cybercriminals use known vulnerabilities in the protocol to launch attacks. To mitigate these risks, be sure to apply any updates that include patches for the known vulnerabilities. SSH-1 is an outdated version of the protocol. You should update your default settings to use SSH-2 only for establishing secure connections with other devices.

Pros and Cons of Using Passwordless SSH

Passwordless SSH authentication seems like the perfect protocol with very few downsides. However, even the best code has vulnerabilities, and passwordless SSH authentication is no exception. You should always take into account the limitations of the protocol. If used judiciously and with the right protective measures and processes in place, passwordless SSH can become your friend, helping you protect your organization and IT-related assets against cybercriminals.

If you’re unsure about whether to use a password or opt for passwordless SSH,, then this section is for you. Let’s look at some of the pros and cons of adopting passwordless SSH as part of your organization’s security defenses:

Advantages of Using Passwordless SSHDrawbacks of Using Passwordless SSH
Provides an improved and frictionless user experienceRequires greater upfront costs in terms of time and setup
Offers greater security than traditional passwordsRequires proper training for employees to use
Mitigates risk of credential compromise via phishing and other social engineering scamsIncreases risk in situations where an employee’s device gets stolen (Note: You can minimize this threat by teaching your employees to secure their devices with strong, unique passwords that are hard to guess. This way, even if an unauthorized user gets their hands on an employees’ device, they can’t do anything with it.)
Reduces password-related administrative work (including costly password resets) 
Offers cost savings in the long run if the management is done properly 

Final Thoughts on Best SSH Key Management Practices

When you use SSH keys instead of passwords to establish secure SSH connections, your connection is undoubtedly more secure. SSH keys are generally much longer than passwords and less prone to brute force attacks. However, if you don’t give enough attention to the management of SSH keys, cybercriminals can intercept your communications with your SSH server, which leaves your keys insecure and ripe for the taking.

To stay safe, it’s crucial to define and follow key management policies. In this article, we’ve laid out some best practices to manage your SSH keys securely. However, you should customize your key management policies in accordance with your individual requirements.

About the author

Megha can usually be found reading, writing, or watching documentaries, guaranteed to bore her family. She is a techno-freak with interests ranging from cooking to travel. A regular contributor to various web security blogs, she has earned her diploma in network-centric computing. Being a mother has taught her to speak less and write more (coz who listens to moms, right?).