Why should you use sudo?

Introduction

There was a question on the popular GridPane Facebook Group asking about login in as the system user for each site when setting up cronjobs. The discussion then proceeded to use sudo versus logging in as root.

What’s sudo?

Here’s a good explanation from the first return on google.com when searching “sudo”

Sudo is a command-line utility for Unix and Unix-based operating systems such as Linux and macOS. The utility provides an efficient way to temporarily grant users or user groups privileged access to system resources so that they can run commands that they cannot run under their regular accounts.

https://www.techtarget.com/searchsecurity/definition/sudo-superuser-do#:~:text=Sudo%20is%20a%20command%2Dline,run%20under%20their%20regular%20accounts.

Here’s a quick interview with the person who invented sudo

Everyone Loves sudo!

You’ll find that a majority of guides will provide most commands with sudo prefixed to them. Why? The idea is that it’s more secure, but in reality, the original reasoning for sudo was simply to allow more than one person to have root access to a machine that was used by multiple staff to run jobs.

Why did the use “sudo” trend start?

But let’s talk about why this trend started happening. There was a time when you would install a flavour of Linux and set a root password. You’d then log in to the server with the root password and do what you needed to do. This was insecure; by default, this allows root logins via SSH with a password. If that password was compromised, or it’s extremely weak (See the movie Hackers) you’re going to get owned pretty quickly with a brute force attack.

I would group this in with changing your SSH port. It’s really an inconvenience, more than anything. However, it can be used to mitigate attacks. Especially when there are multiple users managing the system

Other Security Best Practicies to Consider aside from utilizing “sudo”

Stop allowing password-based root logins via SSH!

So how do you avoid this? Set a root password, store it safely, and enable SSH key-based logins to root only. Make sure that your SSH key was protected with a password!

It’s now harder for an attacker to gain access to the system as they need to own your SSH key, which is also password protected. You still have a password for root, which you can use at the console (local keyboard and mouse) or when you need to login via single-user mode to fix a failed raid or fsck a hard drive. It took a while to adopt ssh-key only root logins. But it’s pretty much gold standard now.

Say no to root logins via SSH

The next step was to eliminate root logins directly over SSH altogether, instead during the installation of a majority of Linux flavors and cloud provider installs. You’ll be asked to create a local user and a root password. To log in as root you need to log in as the local user, use an SSH preferably and then use one of the following methods to login as root.

You can su - and use the root password, run a single command using sudo ps -auxwwf or login to a root shell by running sudo su -

Linux flavours don’t do sudo correctly

The only issue now is that most Linux flavors will not require a password to sudo as the local user set up during the initial install. So you can log in as the local user with your ssh-key and sudo su – to a root shell. So if your key is compromised, you pretty much have root access.

Unless you require a password for sudo and you limit SSH logins to only key-based logins. So now a user has to log in via SSH with their SSH key, and then to sudo they need their password. But they can’t log in via SSH with this password. It’s almost like two factors, but not OTP based. Two factor isn’t always OTP.

Cloud Providers are doing it wrong, kinda.

Cloud providers allow a user to provide an SSH key to be automatically added to the default local user (ubuntu or ec2-user are common users). You can then login via SSH using this key and sudo su - to root or just run sudo commands at will.

If you’re not 100% familiar AWS as a business owner, and you have a contractor working on your servers. They’ll most likely ask for the original AWS key that you created on the initial deployment. This is pure laziness. It’s not a password protected key, and chances are you’ve given it out to multiple contractors.

Bastion Hosts FTW (For the Win)!

A bastion host is a server used to manage access to an internal or private network from an external network – sometimes called a jump box or jump server. Because bastion hosts often sit on the Internet, they typically run a minimum amount of services in order to reduce their attack surface.

https://www.strongdm.com/what-is/bastion-host#:~:text=A%20bastion%20host%20is%20a,to%20reduce%20their%20attack%20surface.

I had to help a client with this recently and will be setting up a bastion host for them utilizing https://goteleport.com

When a contractor or developer needs access to a server, you can deploy their keys to your Bastion Host and then provide them access to your servers from the Bastion Host. I really wish Amazon Web Services (AWS) and Google Cloud Compute (GCP) had this built out already.

What are some good reasons to use sudo?

Auditing is easily turned on for sudo

The only other reason I see a good reason to use sudo is for audit logging. However, you can turn on full system audit logging for all users and see what commands are being run. So it’s moot, the sudo audting is cleaner however.

Automated deployments + Restricting Access

The other reasons for using sudo would be for automated deployments and restricting access. Pulling down code, and then restarting services using automation. Or providing a user access to restart a service or edit configuration and more.

What do I think?

Does it really matter what my take on this is? 😂

I would group this in with changing your SSH port. It’s really an inconvenience, more than anything. However, it can be used to mitigate attacks. Especially when there are multiple users managing the system

I don’t believe sudo provides enough protection simply by using it. You still need to lock down SSH to SSH key-only authentication for all accounts. Once a user logs in, a password is required to utilize sudo, and it should be different than the SSH key password you’re using.

I’d also set up SSH logins and sudo to use 2FA, which is amazing.

How to Set Up 2-Factor Authentication for Login and sudo – Linux.com

www.linux.com

Changelog

• 11-02-2023 – Moved article from wpguide.io and updated structure and improved some paragraphs.