Table of Contents
- How are SSH keys used?
- Why is SSH key management important?
- SSH key management compliance
- Best practices for SSH key management
- SSH key management with Encryption Consulting
Secure Shell, or SSH, is a network protocol normally used to connect a user to a remote system over an insecure network. SSH not only authenticates users, but also encrypts communications across networks like the Internet. SSH is used in organizations by system administrators, users, and automated processes to initiate file transfers, manage infrastructure, and provide access to other mission-critical system operations. SSH also works in cloud computing to help deal with network and security issues. SSH keys act as a way of authenticating users without using usernames and passwords. Instead, users have a trusted SSH key pair which authenticates them as the person they say they are.
How are SSH keys used?
SSH key authentication begins with the creation of a key pair. Since authentication with SSH is asymmetric, an asymmetric key pair is created. Asymmetric encryption uses a key pair consisting of a public and private key, also referred to as the authorized and identity keys respectively. The public key gives user access to the remote file system, so that not just anyone can log into the remote file system. Even if an unauthorized user stole the public key, they could not access any information within the remote file system, as they would also need the private key. The private key acts as authentication for the user’s identity, giving the authenticated user access to the data they are allowed access to. As with all private keys, the identity key should be kept secure and should only be accessible by the user who it authenticates. The creation of the key pair only occurs once, meaning the key pair is related to the user through the entirety of its lifetime. A passphrase can also be used to add an additional security measure to the SSH authentication process. The data within the message is encrypted with symmetric encryption.
After the creation of the asymmetric key pair, the client then sends the public key ID to the server for authentication. The server checks for a matching ID number for the public key, and if found, encrypts a message with the public key and sends it to the client. The client then decrypts the message, computes the MD5 hash of the message, and sends it back to the server. If the hashes match, then the client is authenticated into the system and can work within the remote file system.
Why is SSH key management important?
SSH key management is paramount when encrypting connections via SSH. The mismanagement of an SSH key pair can lead to the compromise of the entire remote system being accessed. Below is a list of the risks SSH key management thwarts:
Loss of Information
Attackers that gain control of SSH keys can steal, delete, or modify any data the victim had access to. This can result in the exposure of sensitive data, such as Personally Identifiable Information (PII), or the loss of that same data.
Extraneous Key Generation
Any user with access to the remote system can create a key pair for other authentication purposes. If an SSH key pair were mismanaged and an attacker were to steal the keys, they could create an unlimited number of new key pairs. This would not only make it difficult to manage the legitimate keys, but it would also allow the attacker to login via any of the newly created key pairs if the key pair they stole was deleted.
Lack of Expiration Date
SSH keys do not have an expiration date, like SSL/TLS certificates do, which increases the risk of an SSH key pair becoming mismanaged. The longer a key pair is in existence, the easier it is to not continue protecting it as new keys are created. Older keys are less likely to be rotated too, as system administrators may not know the purpose behind a key. Another issue posed by the lack of expiration date is that when team members leave the organization, they may still have access to their key, allowing them to access any data they could access while at the company. Deletion of older keys also rarely occurs, as system administrators fear they will block important access if they delete the key pair.
If an employee leaves the organization, they tend to leave behind a single key, leading to a key pair that cannot be used. Users can also lose their keys, causing more issues when attempting to delete them. As before, system administrators are hesitant to get rid of keys they do not know the purpose of, especially since it could interrupt critical systems.
As an organization operates over the years, more and more keys are created. With so many keys created, it becomes difficult to track and manage the keys in circulation. This opens the door to attackers to compromise keys, as every single key likely cannot be accounted for.
SSH-based attacks are becoming more prevalent every day. Threat actors can leverage compromised private keys and impersonate administrators, modify encrypted traffic, read encrypted traffic, and access material not meant for unauthorized individuals. If an attacker gained access to the remote systems of an organization, they could modify data, delete data, steal data, implement malware, or disrupt critical systems operations.
One of the most important reasons to properly manage keys is to be compliant with security standards and regulations. Government compliance and regulation standards such as PCI-DSS, and FIPS, require organizations to keep their SSH keys well-managed. The US National Institute of Standards and Technology (NIST) released guidelines on the best ways to ensure SSH keys are properly managed in their document NIST IR 7966.
SSH key management compliance
To be compliant with standards such as PCI-DSS, HIPPA, and FIPS, there are requirements that must be met:
- Identities and SSH keys should properly managed to ensure protection of PII and other sensitive data
- Keys should be rotated when in use for a long time, and deleted if they are no longer active
- The policy of least privilege should be followed. This means that users should only have access to information they absolutely need, and nothing more. This stops attackers who steal keys from accessing the entire remote system
- Keys should be swiftly replaced in the case of loss or compromise
- Security of areas containing payment information or PII data should be especially monitored and segregated from other portions of the network
Best practices for SSH key management
The process of properly managing SSH keys is very important to do correctly. You must ensure full coverage of your organization’s keys and proper coverage of any security vulnerabilities. Following are a series of suggested best practices for proper SSH key management.
Discovery and Consolidation
The first step in the SSH key management process is discovering what and how many keys have been distributed throughout your organization. Keys should be associated with the users and servers they correspond to, and they should be continually checked for how long they have been used. They should be rotated if they have been around for a long time. If the user authenticated by the keys is no longer with the organization, the keys should be deleted to prevent abuse of the key pair. The keys should also be consolidated to one area with the organization. This helps with the management of keys while reducing the attack surface of the keys. Centralizing the storage of the keys helps prevent solo keys and key sprawl from occurring.
Policy Creation and Enforcement
The next step is to create policies to protect the keys. These policies should define:
- Who can create keys
- How to create and store keys
- What keys are created for
- How long keys should exist before rotation
- What justifies deletion of a key
- The maximum access a key should have
- As long as these policies are enforced by the organization, keys should not be mismanaged and attack vectors for threat actors should be greatly reduced. These policies are the heart of SSH key management, so enforcement of these policies should be made a priority in any organization’s security plan.
Risk Identification and Neutralization
Any and all security vulnerabilities relating to SSH keys should be identified and eliminated. With the centralization of the SSH key pairs, identifying issues becomes easier. Security technicians should look for old or unused keys, insecure storage options, or compromised keys. As previously stated, old keys should be rotated and unused keys should be deleted. This step in the process maintains the remote systems and ensures their continued safety.
Keys should be rotated regularly, once they have been in use for a while. Both keys in the key pair must be rotated with new keys. This reduces the risk of a key becoming compromised from security technicians not protecting the key as they do not know what it is for. This also reduces the risk of key sprawl. Automation of this step greatly reduces the risk of human error where a key is overlooked and not rotated.
Continuous Monitoring and Auditing
The final step is to continually monitor and audit the keys to ensure they are rotated and deleted at the appropriate times. Without continual monitoring, keys can fall through the gaps and be left after the user has left the organization, opening the company to compromise from threat actors. Through continued monitoring, the risk of key sprawl, solo keys, and not meeting compliance are all taken care of. Automation of this step in the process would eliminate human error from occurring.
SSH key management with Encryption Consulting
Encryption Consulting provides a variety of methods to create your own successful system for SSH key management. We hold monthly webinars relating to SSH key management, encryption key management, key protection on the Cloud, and more. We also provide assessments and training for Cloud key management on AWS, Azure, and Google Cloud Platform. We can ensure your system is meeting compliance standards, and protecting data with the best methods available. We also write weekly blogs that can help you find the best practices to use for your key management needs and learn more about the different aspects of your organization’s data security needs.