sudo, let me log you doing something stupid

Allow me to step on my security soap box for a moment. I’ve seen in many places around the internet where bloggers will recommend, and explain how, to enable root to login to the console via ssh. I can not tell you enough how bad this is. An attacker no longer needs to guess two passwords to gain root access to the system, but, rather, only one. It is much, much more secure to disallow root access.

Access to the console operating system of ESX should be limited to the absolute minimum. Only users who absolutely need it, and know what they’re doing, should be able to login. From the console, the user has access to all of the configuration and datafiles for virtual machines. With the built-in tools provided by VMware, administrators can mount vmdk files and gain read/write access to a virtual machine’s hard drive. Additionally, because nearly all aspects of the virtual networking configuration can be changed from the console operating system, anyone with access can gain the ability to see all network traffic traveling to and from virtual machines.

Ok, less words, more action…

This awk command will ensure that direct root login via ssh are disabled. Make sure you execute this as root (or if you have sudo setup already, use sudo for the awk and service command):

Now, assuming you have created a non-root account on your ESX host, try to login remotely via ssh. Go ahead, I’ll wait……(hint: ssh -p 22 -l acct_name name.of.server).

See, no change from before. Now, try to ssh as root. Not only does it deny access, but it gives no indication that access is disabled, it simply reports that the password is incorrect.

In my previous post I mentioned putting console users into the wheel group. If ESX were a normal linux operating system, I would advocate not giving the wheel group full access to all commands. But since it is ESX, and there should be an absolute minimum number of personnel logging in, and those personnel should all be qualified administrators, I’m not going to do that.

So, now your asking “Why bother with logins other than root to begin with if you’re just going to let them execute everything as root via sudo?”, well because not every qualified administrator is a smart administrator…we all do stupid stuff, and it’s good to have a record of it so you (or someone else) can fix it. And because there is the potential for bad apples.

Some of you, ::cough:: windows admins, may be asking, what is the reason for this “wheel” and “sudo”. sudo is short for “super user do”. It allows a normal user to execute a command with root privileges, without providing the root password (they still must provide their own password). Additionally, every command is logged, thus enabling auditors to see who is doing what, when. The wheel group is the default, reserved, group for users who have the ability to use the sudo command.

To add an existing user to the wheel group, use this command: usermod -a -G wheel username

Now, as root (from the physical console, or after you “su”, since we disabled root login from ssh…) we modify the sudoers file. There is a special command for this: visudo. This starts a special instance of the vi editor with the file already loaded. Look for the line that reads:

This line, when uncommented, tells the sudo command to allow users in the wheel group to run all commands via sudo. Remove the comment from the beginning by moving the cursor down using the arrow keys, highlighting the pound (“#”) then using “x” to delete it. Press “ZZ” (Shift-zz) to save and exit the editor. You may be tempted to allow wheel users to uncomment the no password command…for reaasons that should be obvious, this is a bad idea.

At this point, users in the wheel group can run commands as root. To test it out, login as a user in the wheel group and execute the following:

sudo /usr/bin/esxtop

You will be prompted for your password (not root’s…), at which point you should see the esxtop command start. Press “q” to exit. Now, remember I said that sudo commands are logged…to view the log:

sudo more /var/log/secure

You should see the log of all commands, who issued them, and when. These are actually logged by syslog, so it’s entirely possible to set them to be forwarded to a remote log host for external storage (and review).

So, after all this, you should now be able to change root’s password to something that is impossibly complicated (think 14+ characters from all four classes), write it down, put it in an envelope, in a drawer, in a safe, in a secured room, and forget about it. Unless catastrophe strikes, you should never, ever, be logged in as root again.

Oh, and the title is a (bad) reference to a specific XKCD comic.

1 thought on “sudo, let me log you doing something stupid”

  1. Andrew,

    First, thank you for the article. From my research, it is the only one of it’s kind.

    Second, bare with me, I am a Windows guy going through a migration to vsphere and could not hold a candle to your obvious expertise.

    We would like to use FastSCP from Veeam in our environment but we reached the point where the recommendation was to enable root login to the host via ssh. Then, as you said, I found hundreds of postings on how to do this, always with a mention that it is not recommended…to which I would agree.

    So, finally to my question. I am working on a testdev host and have already joined it to the domain. What I would like to accomplish is to allow an Active Directory security group made up of our admins (6) to have readwrite access to the host through FastSCP. Is it possible to go about this by following your guidance…or does your way only apply to non-root accounts on the host? Is it possible to grant an Active Directory security group membership in the “wheel” group, and if so, can you tell me how to accomplish that from a command line perspective.

    Also, so I can fully test this, if I perform the above steps and then want to revert back to the original configuration, I would assume I could follow the same steps and simply change the Permit Login setting to “yes”, then go back into the sudoers file and place the # sign in back on the same line, but can you tell me the command line for removing the account from the wheel group?

    Sorry the above is so scattered…but you know…that is a windows admin for ya…:)



Leave a Reply