Treat SSH Keys Like Passwords and Police Accordingly

If you think about it, passwords need to be managed just like SSH keys, and that involves three key requirements:

1. The enforcement of complex or long passwords.
2. Some level of enforcement around the rotation of passwords (we can argue the rotation interval can be argued another time).
3. Controls around who has access to the password.

Let’s cover each requirement in more detail.

Point 1: Complex or long passwords are better, just like SSH keys

This is important because passwords can be stolen through brute-force, so the level of complexity or length of the password is important. I remember when a friend of mine obtained a laptop (legally) but didn’t have the password to get into it.

By gathering the hashed passwords off the laptop, he was able to run it off a dictionary file and effectively brute forced the password in about 45 minutes. He was in high school at the time and definitely not a child-prodigy hacker. Professional hackers with modern tools mean that short or simple passwords don't stand a chance.

Point 2: Password rotation is a must, just like SSH keys

The enforcement of password rotation as of late seems to have shifted a bi. From super complex passwords that require rotation in short intervals to longer passwords with shorter rotation intervals.

The challenge, of course, is that if you force someone to rotate their password too often, their new passwords often become predictable. Users might simply add a number onto the end of their old password. Or they might switch between a couple passwords that they use for every system or application. Or, the worst offense of them all, they might write the password on a post-it note or in an Excel file! I admittedly have done all three before.

Just the other day a co-worker joked, "I found out that if I change my password 12 times, the system lets me keep my same password.”

I think everyone would agree that some level of password rotation enforcement is ideal in case the password gets into the wrong hands or to prevent brute force attacks that can eventually crack a password. Also, the more complex or long the password is, the less often you need to rotate it.

Point 3: Password access controls are essential, just like SSH keys

Of course, passwords are only meant for those who need them, and ownership is pretty clear when it comes to personal accounts and passwords. What happens when the password is used for a service account and the password is stored on a system or application where multiple people have access to it? That access needs to be locked down so that only system admins can access the stored password. Also going back to point 2, what happens if someone that has previously had access leaves the company or changes jobs? At that point, you’ll need to rotate the password.

This holds true for all access that depends on passwords, and this is how we should think about SSH access. As many of you already know, SSH provides access to control, administer, and transfer files to most all systems within a business network. It's not just for Linux and Unix; it's used on mainframes, Windows and also cloud container systems.

When it comes to SSH and the management of passwords, most companies with enough security budget purchase a privileged access management (PAM) solution. Though the industry is changing in this realm as well, where traditional PAM solutions are no longer ideal and companies are instead leveraging "Just In Time" access management solutions when possible, but I'm getting a bit off-topic once again.

In terms of SSH connection, many of those connections are used for automated processes or, dare I say it, to bypass PAM solutions when system admins who don’t want to go through the hassle of a jump host. In many cases, the service account used for those automated processes has a heightened amount of privilege in order to complete its tasks.

These accounts are many times ignored by PAM solutions, but not by hackers! When it comes to SSH, it doesn't differentiate between an interactive user account (an account used by a real human), versus an account that is being used by a software robot, script, or process.

This means that those accounts may have just as many "privileges" as those human accounts covered under traditional PAM solutions.

Don't get me wrong, PAM solutions are a vital part of securing a company network. Typically by taking care of many of the password management points mentioned above by limiting access and rotating passwords. Yet, based on my discussions with many customers and companies, PAM solutions don't typically don’t take care of the 80 percent of the SSH connections that are automated file transfers (SFTP) or processes and that use SSH keys as their primary method of authentication.

So, are you leaving 80 percent of your access unprotected by relying solely on traditional PAM? Well, yes, though it depends. Let’s apply my three earlier points about password management to SSH key management, and you can decide for yourself.

Point 1 revisited: SSH key complexity and length

SSH keys consist of a public key that you put on your destination and a private key that used by the machine initiating the connection. You can think of the private key as a really long password that is stored on the system in order to access any machine that has the public key pair for that private key. As hinted at above, the beauty of this method of access is that no human needs to be present to make the connection. Also, because the private key is essentially a really long password, they can't be brute-forced with any modern machinery within a time period that would be of any value to a hacker.

The private key can be stored anywhere (hard drive, USB, etc.), and aren't directly tied to a particular individual. This makes tracking who has access to each key quite difficult. Which is why you must look at the authorized (public) key for answers as to who can access the destination.

Point 2: revisted SSH key rotation

SSH keys cover the requirements in point 1 quite well. However, they start to fall short when the keys are not managed at least as well as passwords.

Most companies I’ve encountered have never implemented an SSH key rotation policy. That begs the question: why are we so concerned with covering the 20 percent of interactive SSH usage, but don't care about the 80 percent of machine-based accounts that are likely also using SSH keys? I can't fully answer that question, but I have my theories.

1. Most companies are unaware of how bad the problem is, and if they open up the box, they will need to do something about it with already tight resources.
2. SSH keys are used on some of the businesses’ most critical processes and assets, so rotating them can be a scary thought when you don't want to break those processes.
3. I also think there is still some education to be done. It’s not easy to understand which processes rely on SSH keys for access in large organizations with tens of thousands of servers and millions of SSH keys.

The more complex the password (or key) the less often, in theory, you need to rotate it. But in most cases a key has never been rotated – we have seen many 10+ year-old keys in our work. The other problem is that because the SSH private key is stored on the server, and they snever expire, there is any number of employees they have come and gone, and who still may have access to those keys.

So key rotation is still an area where many businesses are missing the mark.

Point 3 revisited: SSH key access controls

With SSH key pairs, you can't 100 percent rely on the private key because its trackability is difficult. So the control needs to be done on the destination end with the authorized key (also called the public key). In other words, by rotating the key pairs regularly and controlling who can actually place authorized keys on the end host, you can more effectively control who has access to the destination.

We have had plenty of companies tell us that they have a PAM solution, and therefore SSH key management isn't a problem for them. Shortly after they say that, we are generally able to show them some accounts that are bypassing their PAM product, all because the ability exists to place a public key on the destination server.

This happens in situations with poor access controls around who could place SSH keys Most SSH servers have the capability to lock down the location of the authorized key to prevent anyone that has general access to place a key on those servers and inherit direct unmonitored access to that machine. Very few companies I have run into leverage that capability. It only takes one legitimate connection through a PAM to set up that access if not controlled and managed properly.

I hope I have shed some light around the need to put similar security practices and policies around SSH key access as you already have for passwords.

If you think you don't have an SSH key problem, I wouldn't be so sure. It certainly doesn't hurt to check and it won't take much of your time. I have seen very few companies with more than a few hundred servers that couldn't benefit from some additional visibility around the SSH key usage within their environment and how that access is being managed.

In the meantime, there is a key-less and credentialess solution available for SMEs and cloud-driven teams everywhere: our user-friendly, multi-cloud proof, and easy-to-deploy Privileged Access Management (PAM) solution called PrivX. Learn why Gartner thinks 'basic PAMs' are no longer an ideal option for cloudification here. Or take the full product to a test drive within your browser without installing anything, or ask for a quick demo.