Secure Shell (SSH) is a critical machine identity that every IT administrator uses. It provides a means to authenticate remote machines, such as Linux devices, Unix and Windows servers and network appliances, so they can securely connect and communicate with one another.
But too often organizations give administrators root-level SSH access to machines, even though having that access rarely is necessary. There are several reasons why allowing this level of access puts organizations at risk for everything from advanced malware like TrickBot to unknown permanent, backdoors that take down an entire infrastructure without warning.
Therefore, it’s very important to manage root-level SSH access, limiting the times that access is allowed to anyone as well as continually monitoring all root-access keys. Read on to learn more about why this security control is so important—and steps you can take to control it.
SSH Machine Identity Management for Dummies
Why is it a bad practice to allow root-level SSH access?
The root is the superuser account in Unix and Linux based systems. Once you have access to the root account, you have complete system access. It’s not surprising that hackers find root access keys to be such a valuable target—once you can gain access into a system, there’s no limit to what havoc you can wreak!
Threat actors leverage bots to scan the internet for systems with exposed SSH ports. Once they find one, they attempt to log in using common usernames and crackable passwords. If they succeed, they hit the jackpot because they can now compromise the whole system. This chaos could have been avoided had the organization elected not to trust their admins to properly manage the keys to the kingdom.
Much of the problem has to do with how admins typically create and manage SSH root-level keys. Marty Milbert, Global Principal Architect for Venafi, says that there should only be one root-level key per server. Too often, however, this is anything but the case. “What we're finding is there's one key to 24,000 servers. So, if I were to steal that one key, I'd have access to the entire organization.” Milbert explains.
Adds Milbert: “The problem behind it is the fact that this key is an authentication point. It makes the connection. How do they track it? When it comes to audit, how do they know who did what?”
How to control root level SSH access
The risks above make plain why it is bad practice to allow root-level SSH access. So, here are three best practices you can employ to minimize the risk in your organization.
- Disable root SSH
Your first step should be to disable SSH root logins. To start, edit the SSH daemon configuration, which is usually located in /etc/ssh/sshd_config. Before making any changes, make sure to back up the configuration file. The file should contain the following line:
PermitRootLogin no
If you’re already preventing the use of the root account across SSH, you can now explicitly state which users can connect to the server. Perhaps, you have a regular non-root admin account you use or one that's already configured with sudo privileges. In the SSH configuration file, add the following line:
AllowUsers user1
You can also whitelist a group of users:
AllowGroups groupname
Once the changes are saved, restart the sshd service to make them effective.
- Use sudo
For administrative purposes, certain tasks still need to be performed as root. Therefore, pick up the habit of using sudo for this.
With sudo, admins can act as root without ever having to become root. There is an obvious benefit to this: because every task performed through sudo is performed under a user’s own account rather than the generic root account, you then can track and audit the use of this root key.
- Use SSH keys to login
Regular user accounts are still vulnerable to password guessing by bots. People tend to choose weak passwords or reuse their passwords to make them easier to remember. While password guessing can be mitigated by choosing strong passwords or limiting failed login attempts, it’s better to remove password usage altogether.
So, instead of passwords, use SSH keys to log in. Once set up, disable password logins in /etc/sshd_config by adding the following:
PasswordAuthentication no
and then restart the sshd service.
Protect your SSH keys
Although the use of sudo and SSH keys is a great step towards securing critical systems, it is equally important to protect these SSH keys. SSH machine identities are used in every data center in the world, half of the world’s web servers, and practically every Mac, Unix or Linux computer—whether on-premises or in the cloud.
The sheer quantity of SSH machine identities being deployed makes effective management difficult. Yet cracking just one SSH machine identity allows attackers to pivot to other systems. With that level of access, attackers can explore your enterprise’s entire network and steal the most lucrative data they find.
Are you sitting on an SSH ticking time bomb? Take control over your SSH keys without disruptions or outages with Venafi’s SSH Protect.
Get a FREE & Confidential SSH Risk Assessment from Venafi!
Related posts