This is why we\u2019ve decided to tackle an article that addresses some of the most important SSH key management best practices for your business. But what are the top 14 SSH key management best practices you need to implement now and how do they benefit your organization?<\/p>\n\n\n\n
Let\u2019s hash it out.<\/span><\/p>\n\n\n\n Before we jump right into defining SSH key management, let\u2019s first quickly rehash what secure shell is, what SSH keys<\/a> are, and how organizations use them for user-friendly authentication and increased data security.<\/p>\n\n\n\n SSH<\/strong>, which stands for secure shell<\/strong><\/a>, is a cryptographic network protocol that allows secure authentication and data communications between two devices via open channels. SSH is critical for network and general system administration (such as for managing firewalls, networks, servers, etc.). As something that\u2019s literally built into Unix and Linux servers, it\u2019s a client-server model system that aims to secure remote access between users and critical systems via insecure connections.<\/p>\n\n\n\n More simply stated, SSH is the numero uno<\/em> system that IT admins use to log in to servers and other Linux machines to manage them remotely. The way it works is when authorized users log in to a secure shell environment to authenticate, their devices gain access to one or more devices or resources within your secure IT environment. As such, it\u2019s easy to see how SSH authentication plays a critical role in your organization\u2019s identity and access management processes.<\/p>\n\n\n\n When you use SSH to log in using admin root access, you have complete control over the machine. SSH access serves as your key to your kingdom, giving you control of all commands and files. So, as you can imagine, protecting that kind of privileged access through proper SSH key management is crucial to your organization\u2019s security. (Going out a limb here to say that SSH security is important to you since you’re still here and have read this far, at least…) <\/p>\n\n\n\n SSH authentication can occur in a few different ways. However, the two we\u2019re going to focus on today are password- and SSH-key-based authentication methods. And our primary focus, as your can probably guess from this article\u2019s title, is going to focus on SSH key management best practices specifically.<\/p>\n\n\n\n In a nutshell, SSH keys are another form of machine identity and authentication. They enable your organization\u2019s authorized, authenticated users to access critical systems to perform their jobs. But SSH keys, unlike traditional PKI keys that we use with X.509 digital certificates, don\u2019t have public keys that are signed by a certificate authority<\/a> (i.e. certification authority or CA) like DigiCert or Sectigo. (In SSL, you generate your SSL keys yourself through the CSR process, and the public key is what the CA signs as part of your certificate.) And even though SSH authentication involves a process that\u2019s similar to the SSL\/TLS handshake, its authentication process isn\u2019t as complex.<\/p>\n\n\n\n Related<\/strong>: Secure Your Domain & Sub-Domains with a RapidSSL Wildcard Certificate<\/a>. <\/em><\/p>\n\n\n\n Here’s a quick (and simplified) overview of how SSH authentication works:<\/p>\n\n\n\n But when comparing password- and key-based SSH authentication methods, which option is better or more secure? EdgeScan\u2019s 2021 Vulnerability Statistics Report<\/a> shows that some of the biggest growths in terms of exposure for organizations in 2020 relate to the use of insecure SSH credentials.<\/p>\n\n\n\n \u201cRemote desktop (RDP) and Secure Shell (SSH) exposure increased by around 40%, likely due to the increase in remote working due to covid-19. RDP (and similar services) are easy and commonly used avenues for brute force or credential stuffing attacks, against weak user credentials.\u201d<\/p>\n<\/blockquote>\n\n\n\n EdgeScan’s report shows that in their sample of one million public-facing endpoints’ exposed services, SSH represented 3.8% (38,000) in terms of “remote system login and management.” <\/p>\n\n\n\n When properly managed, SSH keys offer an authentication method that\u2019s more secure than using traditional login credentials alone. Why? Because keys are resistant to brute force attacks. But the security and effectiveness of those keys depend on how well your organization keeps track of them. This is where following SSH key management best practices comes into play.<\/p>\n\n\n\n SSH key management<\/strong> is the combination of policies, processes and tools that enable you to protect and manage those digital key pairs. Secure shell keys allow users to authenticate themselves to your network, servers, or other systems and securely share files without continually logging in using a username and password.<\/p>\n\n\n\n Some of the benefits of effective SSH key management include:<\/p>\n\n\n\n Much like PKI key management, successful SSH key management revolves around how well you can protect and keep track of your organization\u2019s public and private keys. This means using effective methods to generate, store, rotate, revoke, and use them in ways that keep them out of the hands of cybercriminals and other unauthorized users. This requires processes that ensure proper SSH key provisioning, terminations, and monitoring across all of your IT environments.<\/p>\n\n\n\n And this can be tricky, considering that without proper access management and approval processes in place, users can simply issue themselves access privileged access to your most critical systems. This is why having a strong SSH key management program in place is essential. It\u2019s also why SSH key management should be part of your access and IT risk management and remediation processes, policies and strategies.<\/p>\n\n\n\n You should understand by now that mismanaging your SSH keys leaves your organization at risk of credential compromise, data theft, and data breaches, but did you know it also makes you non-compliant with some industry regulations? Many well-known regulations \u2014 HIPAA, GDPR, PCI DSS \u2014 all require data security and privacy protections. Some of these requirements relate to managing access to that data, which implies or specifies the use of cryptographic keys such as SSH keys.<\/p>\n\n\n\n HIPAA\u2019s Security Rule<\/a> requires covered organizations to implement role-based access measures to protect electronic protected health information (ePHI) data when it\u2019s in use, in transit, and at rest. This is something that SSH key management plays a role in.<\/p>\n\n\n\n PCI DSS<\/a> Requirement 4 specifies that covered organizations must use encrypted transmissions to transmit cardholder data over open networks. This requires the use of cryptographic processes and components like public-private keypairs. <\/p>\n\n\n\n PCI DSS Testing procedure 2.3 requires the use of \u201cstrong cryptography\u201d for all non-console administrative access. According to the PCI DSS guidance specified in 2.3c: \u201cTo be considered \u2018strong cryptography,\u2019 industry recognized protocols with appropriate key strengths and key management should be in place as applicable for the type of technology in use[.]\u201d<\/p>\n\n\n\n The European Union\u2019s GDPR requires the secure processing of covered personal data. GDPR Article 32<\/a> specifies the use of \u201cappropriate technical and organisational measures,\u201d which include data encryption and secure access to that data. (This includes the use of public key encryption methods to secure access.)<\/p>\n\n\n\n Needless to say, if bad guys manage to get their hands on your employees\u2019 SSH keys, it can lead to many dire and costly consequences. This is why SSH key management should be a priority for every business regardless of size.<\/p>\n\n\n\n Research from Acunetix\u2019s 2020 Web Application Vulnerability Report<\/a> shows that 15.5% of the 5,000 scan targets they analyzed had SSH-related vulnerabilities. A large part of this is due to SSH key mismanagement. That\u2019s because the security of SSH keys is only as good as the SSH key management and auditing practices you implement.<\/p>\n\n\n\n Effectively managing your SSH keys entails knowing:<\/p>\n\n\n\n The National Institute of Science and Technology (NIST) provides in-depth guidance for SSH access management in their interagency report 7966<\/a> (NISTIR 7966). They cover many vulnerabilities, including:<\/p>\n\n\n\n However, there\u2019s a lot<\/em> of material to cover there and, frankly, we don\u2019t think you\u2019re here to get into the nitty-gritty of all of that now. That\u2019s why we\u2019re going to take a bit more of a high-level approach to SSH key management in this article.<\/p>\n\n\n\n So, without further ado, let\u2019s break down the 14 SSH key management best practices you can put to work now to protect and manage access to your organization\u2019s IT environments and data. These best practices will be divided up into four overarching categories that will help make things easy to follow.<\/p>\n\n\n\n SSH key visibility is the first best practice we\u2019re going to mention because you can\u2019t protect or secure your organization\u2019s SSH keys if you don\u2019t know that they exist<\/em>. It would be like being in charge of the U.S. Secret Service and having to protect the President without knowing in advance where they\u2019re traveling to and whom they\u2019re meeting with.<\/p>\n\n\n\n Likewise, effective key governance requires you to have a clear picture of what\u2019s going on within your network and IT environment. Part of this entails maintaining a current (ideally centralized) inventory of all of your SSH keys and how they\u2019re used across your servers, hosts, and other IT infrastructure. This will help you to identify:<\/p>\n\n\n\n If you don\u2019t know what keys are used by which systems or users, then you\u2019re in for a world of pain. That\u2019s because bad guys like hackers and other cybercriminals might figure out which keys have access to specific systems before you do and exploit them.<\/p>\n\n\n\n So, how can you figure out where all of these different keypair components live and what they have access to?<\/p>\n\n\n<\/span><\/span>\n\n\n Using a reliable SSH key management tool is an easy way to manage the key management lifecycle within your organization. An SSH key manager helps you discover wherever any keys exist within your IT infrastructure and what they control or have access to. This helps you identify potential vulnerabilities that bad guys can exploit via temporarily forgotten, orphaned or rogue SSH keys.<\/p>\n\n\n\n In their eBook “6 Steps to Take Back Control of Your SSH Keys<\/a>,” Keyfactor describes orphaned keys as authorized public keys whose private keys’ locations aren’t known. Forgotten keys are the temporary-use keys admins create for specific tasks but forget to remove later on. As the name implies, rogue keys are unauthorized tools that may be created out-of-band. <\/p>\n\n\n\n SSH key management tools allow you to manually manage your keys while also enabling you to automate many of these functions. They can also help you to avoid or alleviate key sprawl issues, which is particularly useful for large organizations and corporations that have to manage thousands or even millions of SSH keys (in the case of Fortune 500 companies<\/a>) within their environments.<\/p>\n\n\n\n However, it\u2019s important to note that not all key management platforms support SSH keys<\/em>. Some examples of SSH key management platforms that do allow you to protect and manage them are:<\/p>\n\n\n\n As I mentioned earlier, SSH keys come in key pairs that consist of private and public keys. The private key is the one that you store on the user’s device who will use the key for access. For example, their office laptop or smartphone. The public key, on the other hand, is what you\u2019ll need to store on the machine that users will connect to (such as a server). This could be your network, a server, or a variety of other systems.<\/p>\n\n\n\n Every SSH private key should be protected with a unique and hard-to-guess passphrase. What this does it add another layer of security against brute force attacks and tools. This way, even if a bad guy manages to gain access to your private key, they can\u2019t do anything with it because they can\u2019t guess the password. Every time you replace this key, you should also use a new, strong passphrase.<\/p>\n\n\n\n The private key should also remain on the device that you generated it on. The only exception would be if you decide to store it in a secure key vault or hardware security module (HSM). Just be sure to never, ever<\/em> share an SSH private key over a network!<\/p>\n\n\n\n Effective SSH key management requires secure backups and storage of these keys. Part of this means knowing how and where to save keys so that they don\u2019t get leaked or become compromised in another way. For example, you never want to store your SSH key information in whatever folder of code you\u2019re sharing around because they could wind up getting leaked.<\/p>\n\n\n\n One option is to use a trusted and reputable key vault (such as Azure Key Vault or AWS Key Management Service). This is a secure, centralized place where you can store many types of cryptographic elements securely (certificates, PKI keys, SSH keys, and other secrets) so that authorized web applications and entities still have access to it as necessary.<\/p>\n\n\n\n Another option for secure key storage is to store your SSH keys in a physically secure offline environment. This should mean storing the secure device that holds the keys under lock and key and in a secure area that only select authorized individuals have access to.<\/p>\n\n\n\n A great way to ensure your private keys stay secure while still being accessible is through the use of a process known as key escrow. This basically means using a trusted third party or tool to hold on to a copy of your SSH private key. An advantage of using a key escrow is that it serves as a backup should something unforeseen happen to the original key.<\/p>\n\n\n\n An example of using key escrow is when an IT admin uses a third-party tool to store the keys so authorized entities that need them can get access to them. To set this up, they have to determine where and how to save the key and who gets access to it. Some key escrow capabilities may already exist within your system (for example, it may be part of your Active Directory).<\/p>\n\n\n\n In some ways, the concept of key escrow is similar to how your mortgage company manages an escrow account for you. They collect a set amount of money from you each month, part of which they store in an escrow account. This account then is what they use to pay your annual property taxes and homeowner\u2019s insurance when they come due each year.<\/p>\n\n\n\n It\u2019s no surprise that effective user access management is also an SSH key management best practice. After all, SSH keys are just another method of authentication that you can use in lieu of traditional credentials (usernames and passwords) for your users. So, this means that your SSH key management processes and policies should align with your access controls.<\/p>\n\n\n\n As we touched on earlier, NIST also provides guidance regarding SSH user access and key management. This can be found in their interagency report 7966 (NIST IR 7966<\/a>) that we referenced earlier. It also affects the control families they address in special publication 800-53 (SP 800-53).<\/p>\n\n\n\n SSH key management is only as good as the policies you have in place and enforce. If you have policies on paper that are never followed or applied, they\u2019re essentially worthless. These policies should be the backbone that governs your SSH key infrastructure and processes, and they should also ensure accountability by those who are responsible for them.<\/p>\n\n\n\n Suppose you have policies in place that clearly outline everyone\u2019s responsibilities and roles, and those policies are regularly enforced. In that case, carrying out those functions is less likely to get pushed to the back burner of priorities and become forgotten. <\/p>\n\n\n\n While it may be easier to create a few shared accounts, more effective credential management dictates that it\u2019s best to create an individual account for every employee. This means creating that you\u2019ll need to create SSH key pairs for everyone who needs access to specific systems.<\/p>\n\n\n\n Part of this process should include formal access approvals and accompanying documentation. This helps to provide a record about why each key\u2019s access is necessary and which key(s) a user\u2019s access is tied to. While all of this is useful for SSH key management in general, it\u2019s especially useful by helping you keep your ducks in a row when terminating access for users.<\/p>\n\n\n\n The thought here is that only authorized users should have privileged access. To ensure this, you can configure an individual\u2019s SSH key so that it\u2019s associated with an account that limits access to what that user needs.<\/p>\n\n\n\n It\u2019s also best to remove old access whenever employees change jobs within your company or leave your company altogether. This brings us to our next talking point\u2026<\/p>\n\n\n\n Orphaned and forgotten SSH keys are a big issue for businesses. These unaudited keys are essentially forgotten active keys that create backdoors that cybercriminals or even disgruntled former employees can exploit. This is a particularly important step since you don\u2019t want valid SSH keys out there that can access your systems that you don\u2019t know about.<\/p>\n\n\n\n Whenever someone leaves your company, you should have policies and processes in place for how to terminate access for any accounts associated with that user. One such access management method is to remove all public keys that are associated with them. This will prevent their private keys from allowing access to authorized systems. Otherwise, you\u2019re left with keys that bad guys can try to exploit.<\/p>\n\n\n\n One of the ways to harden your SSH security is to ensure that everything is properly configured \u2014 that you\u2019re dotting your i<\/em>s and crossing your T<\/em>s. You can set your SSH configurations using various tools, terminals, and applications such as PowerShell or MacOS\u2019s terminal.<\/p>\n\n\n\n Here are a few SSH key management items you should double-check to make sure you\u2019re doing right:<\/p>\n\n\n\n SSH keys are versatile in that they can be generated in multiple size options. However, NIST IR 7966 specifies that \u201cuser keys must conform to organizational standards for minimum key lengths used with approved algorithms.\u201d<\/p>\n\n\n\n This is why many organizations nowadays opt to generate RSA 2048 SSH keys. The idea here is that a key of this size helps to make factoring attempts too impractical (and costly) for attackers to carry out. So, to ensure that all SSH key generations within your organization meet the minimum, you must specify a minimum key size.<\/p>\n\n\n\n You can generate your keypair in a couple of ways. One method is by generating it directly on the server itself with the command ssh-keygen -t rsa<\/em> and following the prompts, which includes creating a passphrase for the private key. I\u2019m going to borrow a screenshot from one of my former colleague\u2019s articles that shows how this looks:<\/p>\n\n\n\n Another method is to use standalone software (such as PuTTYGen) that allows you to create your public-private keypairs. <\/p>\n\n\n\n What\u2019s interesting about SSH keys is that, unlike PKI certificates, they don\u2019t technically \u201cexpire\u201d after any given period. Sure, they can be revoked, but in order for them to so-call \u201cexpire\u201d in the sense of no longer being usable, you have to manually force your server to reject old keys or delete them outright from your IT systems. (Hmm, maybe I should say \u201cretire\u201d instead of \u201cexpire\u201d here.)<\/p>\n\n\n\n But regardless of the choice of verbiage, why is invalidating SSH keys necessary? You don\u2019t want to leave SSH keys valid indefinitely because doing so poses significant security risks. For one, improperly managing keys results in active keys that offer access to critical systems never being removed. Another huge concern is employee turnover. If employees who leave the company have access because their keys are still active, it\u2019s a huge (and entirely avoidable) liability.<\/a><\/p>\n\n\n\n Because SSH keys don\u2019t expire, a common practice is to rotate your keys regularly. Although you should have processes in place to ensure that inactive keys are removed, we get that life happens and some things don\u2019t always happen as they should. So, regular key rotation helps to prevent compromised keys from being exploited by bad guys.<\/p>\n\n\n\n However, NIST IR 7966 does note that key rotation can negatively affect or break external keys. These keys are those that either come from outside organizations or are internal keys that authenticate and access systems external to your environment. Proper SSH key rotation means: <\/p>\n\n\n\n But how regularly should you rotate keys? Eh, that answer depends on who you ask. For example, NIST IR 7966 is pretty vague about that and just hedges their bets by saying that keys should be rotated \u201cregularly.\u201d But in Appendix F, they include a link to a 2013 NIST document draft<\/a> that specifies the following: <\/p>\n\n\n\n “Authentication credentials for all trust relationships leading to moderate-impact and high-impact systems MUST be rotated every 12 months, and it is RECOMMENDED that trust relationships leading to low-impact systems be rotated every 12 months. It is recommended that all keys be rotated as part of a remediation process to ensure that any previously leaked keys cease to be usable.”<\/p>\n<\/blockquote>\n\n\n\n Trend Micro<\/a>, on the other hand, is more specific. They say that you should rotate SSH public keys approximately every month-and-a-half (i.e., every 45 days).<\/p>\n\n\n\n Toby Gaff, Director of Solutions Engineering at Keyfactor<\/a>, cautions randomly rotating keys without having a plan:<\/p>\n\n\n\n \u201cBut here’s the challenge when it comes to SSH Key, most of them are not used for interactive purposes. We could see two different requirements existing for key rotation. One based on application\/system keys and the other on interactive\/user keys. We believe that keys should be rotated more frequently for interactive\/user keys (kind of like passwords), but having such a policy is kind of pointless unless you can report on it or enforce it.\u201d<\/em><\/p>\n<\/blockquote>\n\n\n\n This brings me to my next point about changing keys\u2026<\/p>\n\n\n\n A good rule of thumb is to use unique SSH keys for different users and environments. For example, the SSH keys you use for admins in production shouldn\u2019t be the same as the ones you use for accounts in development. This way, if someone manages to compromise an SSH key for a user in one environment, they can\u2019t turn around and use that same key to access other environments across your systems.<\/p>\n\n\n\n SSH uses TCP port 22<\/a> by default, but that doesn\u2019t mean you\u2019re automatically stuck using it. Jeremy Caban, IT administrator\/DevOps Engineer at TheSSLstore.com, weighs in on this best practice:<\/p>\n\n\n\n \u201cOne thing that comes to mind is the school of thought around using a different port for SSH. With proper security measures in place, it makes this pretty much a non-issue for the most part. But still, it never hurts to have more security layers in place.\u201d<\/em><\/p>\n<\/blockquote>\n\n\n\n While changing the communication port isn\u2019t necessarily a requirement, it\u2019s a great best practice because it helps to reduce automated attacks (such as brute force attacks). And considering that there are 65,536 TCP communication ports<\/a> you could choose from, it\u2019s only right that you make it harder for threat actors to try to figure out which port you\u2019re using. (Make \u2018em work for it, right?)<\/p>\n\n\n\n According to the Internet Assigned Numbers Authority (IANA)<\/a>, port numbers are typically broken down into three sets of ranges (some of which may require IANA registration):<\/p>\n\n\n\n You can change your client program\u2019s port access specifications<\/a> manually in your SSH configuration files via the Linux command line. This forces SSH to connect via the port number of your choice. You can also configure your firewall to block access to port 22 altogether or restrict access to it from trusted hosts as well. For specific directions on how to change your default SSH port, check out this article Caban recommends by linuxhint.com<\/a>.<\/p>\n\n\n\nWhat Is SSH Key Management? The Role of SSH Keys in Identity & Access Management<\/h2>\n\n\n\n
What Is SSH and What Does It Do?<\/h3>\n\n\n\n
![\"Screenshot](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2021\/04\/ssh-access-management-server-root.png\")
![\"SSH](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2021\/04\/ssh-access-management-root-access.png\")
SSH Authentication (and Where SSH Keys Fit Into the Picture)<\/h3>\n\n\n\n
\n
![\"A](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2021\/04\/how-ssh-authentication-works.png\")
\n
SSH Key Management \u2014 It\u2019s How You Control the Keys to Your Kingdom<\/h3>\n\n\n\n
\n
SSH Key Mismanagement Leaves You Vulnerable and Non-Compliant with Industry Regulations<\/h3>\n\n\n\n
Health Insurance Portability and Accountability Act (HIPAA)<\/h4>\n\n\n\n
Payment Card Industry Data Security Standards (PCI DSS)<\/h4>\n\n\n\n
General Data Protection Regulation (GDPR)<\/h4>\n\n\n\n
14 SSH Key Management Best Practices You Need to Implement Now<\/h2>\n\n\n\n
![\"A](\"https:\/\/media.giphy.com\/media\/Fz6gBKK52Nfyg\/source.gif\")
\n
\n
Use Tools That Increase Visibility of the SSH Keys Within Your Network & IT Environment<\/h3>\n\n\n\n
\n
1. Use an SSH Key Manager to Discover SSH Keys and Enable Automation<\/h4>\n\n\n\n
\n
Use Secure Methods to Store, Backup & Permit Authorized Access to Keys<\/h3>\n\n\n
![\"A](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/04\/Outline-Backup-Strategy.png\")
<\/figure>\n<\/div>\n\n\n2. Use a Key Vault and Physical SSH Key Storage<\/h4>\n\n\n\n
3. Implement Key Escrow to Permit Access to SSH Keys by Only Authorized Entities<\/h4>\n\n\n\n
Implement and Follow Effective Access Management Best Practices<\/h3>\n\n\n\n
4. Implement and Enforce Strict SSH Key Management Policies and Processes<\/h4>\n\n\n\n
5. Create, Manage and Document Individual User Accounts (Avoid Creating Shared Account Credentials)<\/h4>\n\n\n\n
6. Implement a Policy of Least Privilege (POLP)<\/h4>\n\n\n\n
7. Remove Old SSH Public Keys (Mitigate Key-Based Risks)<\/h4>\n\n\n\n
Ensure All SSH Keys and Related Systems Are Properly Configured<\/h3>\n\n\n\n
8. Ensure All SSH Keys Meet or Exceed the Recommended Minimum Key Size<\/h4>\n\n\n\n
![\"A](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2021\/04\/ross-thomas-ssh-shell-example.jpg\")
9. Invalidate Your SSH Keys After a Certain Period<\/h4>\n\n\n\n
10. Rotate Keys Regularly<\/h4>\n\n\n\n
\n
\n
\n
11. Use Different SSH Keys For Different Users, Hosts, and Environments<\/h4>\n\n\n\n
12. Change the Default SSH Port and Disable Port Forwarding<\/h4>\n\n\n\n
\n
\n