Skip to main content
banner image
venafi logo

How to Control Root-Level SSH Access

How to Control Root-Level SSH Access

how-to-control-root-level-ssh-access
March 7, 2022 | Anastasios Arampatzis

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.
 

Are Your SSH Machine Identities Secured? Find Out Now!
">
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.

  1. 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.

     
  2. 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.

     
  3. 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.
 

Related posts

Like this blog? We think you will love this.
how ssh works
Featured Blog

How Secure Shell (SSH) Keys Work

How it works SSH is a type of network protocol that creates a cryptographically secure

Read More
Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

See Popular Tags

You might also like

TLS Machine Identity Management for Dummies
eBook

TLS Machine Identity Management for Dummies

Certificate-Related Outages Continue to Plague Organizations
White Paper

CIO Study: Certificate-Related Outages Continue to Plague Organizations

About the author

Anastasios Arampatzis
Anastasios Arampatzis

Anastasios Arampatzis is a retired Hellenic Air Force officer with over 20 years of experience in evaluating cybersecurity and managing IT projects. He works as an informatics instructor at AKMI Educational Institute, while his interests include exploring the human side of cybersecurity.

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud


Venafi Cloud manages and protects certificates



* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
(@%+^!#$?:,(){}[]~`-_)
* Please fill in this field
* Please fill in this field
* Please fill in this field
*

End User License Agreement needs to be viewed and accepted



Already have an account? Login Here

×
get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more