How To Give Someone Temporary Root Access

The other day, I had a problem with my server, where I got an e-mail saying that some SSL certificates were about to expire. These came with the original VPS, and I’d already installed my own SSL certificates, so I wasn’t worried about my webserver going down. However, I WAS worried that something else might fail, so I contacted my VPS support team who needed access to my server.

The problem? I’m not comfortable giving anyone my root password. I’d done it once before and later couldn’t sleep until I’d changed all the exposed passwords. I didn’t want to go through all of that again, so I put in place a process that allowed me to give temporary root access to a 3^rd party, without needing to change all my passwords.

Solution: Create a New User with Sudo Privileges, then Disable Afterwards

The solution I found was to create a new user called “debugger”, and give them sudo privileges. This means that you give them the right to execute root commands temporarily. Doing this requires adding the user to the “sudoers” list. You can check out my tutorial here on how to allow a Linux user to run sudo commands.

Once you’ve added this user, you just need to give the login details to the person who’s troubleshooting, and they can perform whatever tasks they want with root privileges if necessary.

Disabling the User Afterward

The most critical part of the process is disabling access to the user afterward. Once the debugging is done, the person no longer needs root access, and having a user out there with a password they can use to run root commands is a huge security risk. As a result, you need to lock or disable the account easily.

In WHM, you can simply click the “Manage Shell Access” icon, and then disable shell use for any user. For an InterWorx user like me, you can disable shell access by accessing the “Shell Users” section in NodeWorx from the SiteWorx sub-menu on the dashboard.

Now the user will no longer be able to log in and you’re safe. If you want, you can also change the password of the test account.

Verifying what the User Ran

I take things a step further. I log in afterward and check all the commands issued by the user in question to verify that nothing fishy happened. Overkill? Probably. But it makes me sleep better!

To see all the commands issued by a particular user, use the following command:

cat /[username]/.bash_history

So in my example, I would type:

cat /debugger/.bash_history

This should list the entire set of commands issued in the recent past, so you can perform an audit of what happened.

If you don’t want to access the shell, you can also view the command history from the GUI via the same interface you used to disable shell access. Whenever possible, do without the shell I say!

The Extra Security is Worth it

Taking these steps should also drill good habits into you so that they become second nature. No one needs to ever know your root password except yourself, and no one needs unrestricted access to your server for an unlimited period. If you’re placed in a situation where you must give your root password to someone, then change it as soon as feasible. The notion that someone else has your password shouldn’t allow you to rest easy!

Managing a server is a huge responsibility, especially if you’re migrating from a shared environment. You need to learn new habits and best practices. Keep your server safe!