VPS v2 Support Documentation

Methods for Securing Root Access

One of the greatest strengths of a VPS v2 account is that it looks and acts like a standalone FreeBSD server. This provides an enormous amount of power and flexibility, but it also means increased responsibility, especially in the areas of server administration and security.

Just as with any other Unix-like system, the most important security measure that can be taken on a VPS v2 account is to prevent unauthorized access to the root (or superuser) user. This document describes several methods of setting up secure access to the root user on VPS v2 using ssh and other common tools.

Some preliminaries:

• Only secure tools like ssh, scp, and sftp should be used to access root or administrative user accounts.
• Passwords for root and administrative users should be strong (not easily guessable). The root password, in particular, should be protected as much as possible. For additional information on what constitutes a strong password, see:
  http://www.webhostingsolutions.com/support/vps/basic/admin/users/passwords.html
• Root and administrative user accounts should be closely monitored.
• Shell access should be removed from any user that does not require it. Any user that does require shell access should always connect securely (via ssh, scp, or sftp).

Method 1: Access via Administrative Users Only

In this access method, direct shell access to the root user account is disallowed over the network. In order to access the root account, a user must first connect as an administrator (an account in the wheel group), and then use the 'su' or 'sudo' programs to obtain root privileges for the necessary tasks.

Here are the steps necessary to configure this type of access:

1. Configure administrative accounts in /etc/group

The wheel group is used to determine who can connect to the root account using su and sudo, among other things. Your default VPS v2 admin account (you should have specified the admin username and password when you ordered your VPS v2 account) setup during account provisioning should already be a member of the wheel group, so you only need to modify the list if you want to add additional admin users.

While connected to the root account, edit /etc/group and add the usernames of the users who should be allowed to su to root to the group entry for wheel. For example, to add the usernames larry, moe, and curly to the wheel group, you would do this:

wheel:*:0:root,larry,moe,curly

2. Disable remote root login capability in sshd

While connected to the root account, do the following:
• Edit /etc/ssh/sshd_config, and make sure that the PermitRootLogin line is set like this:

PermitRootLogin no

• Restart sshd. You can do this by either stopping and restarting the main sshd daemon (this won't hurt your established ssh connections) or else sending a HUP signal to sshd like this:

kill -HUP `cat /var/run/sshd.pid`

Assuming everything is set up correctly, administrative users should now be able to connect to the root account by running the 'su' command and typing the root password:

admin$ su
Password:
root# id
uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys), 4(tty),
5(operator), 20(staff), 31(guest)

Access to the wheel group should not be given lightly--it should only be set up for admin accounts which need root access.

The su program only provides on/off access to root privileges, and it requires that all of the administrators know the root password. More fine-grained access is provided by the 'sudo' program, which is installed by default on the VPS v2 platform. Sudo allows admin users to execute a specific set of commands as the root user without the admin user having to know the main root password. Instead, admin users are allowed to run a specific subset of commands with root privileges.

The default VPS v2 configuration of sudo (located in /usr/local/etc/sudoers) includes 2 classes of privileged users:

admin users (group wheel): allowed to run admin commands like vadduser and edquota

webmasters (group webadmin): allowed to run webserver-specific commands like restart_apache and apachectl

For example, an admin user who wanted to run the vadduser command could do the following:

admin$ sudo vadduser

and be able to create the new user without having to log in directly as root.

For more details on sudo configuration, see /usr/local/etc/sudoers.sample and the man pages for sudo(8), sudoers(8), and visudo(8).

Method 2: Access via Authorized SSH Keys

In this access method, remote root shell access is available over the network via ssh, but only using an ssh public/private key pair. Password logins as root are disallowed. Access via admin accounts as described in Method 1 also works alongside this method.

Here are the steps necessary to configure this method:

1. Create public/private key pairs

First, a public/private key pair needs to be created. Here we will document how to do this using OpenSSH (the default ssh version on FreeBSD). Windows SSH clients like SecureCRT can also generate key pairs--please see the client-specific documentation for instructions on creating key pairs.

As an ordinary user, run this command:

ssh-keygen -t dsa

and follow the instructions. This will create two files: the private key, and the public key (the file with the .pub extension). The default values for OpenSSH on FreeBSD are:

id_dsa (private key)
id_dsa.pub (public key)

During the key creation, you will be prompted for a passphrase which is used to protect the private key from unauthorized use. The guidelines for choosing strong passphrases are the same as those for choosing strong passwords--use a mix of upper- and lower-case letters, numbers, and symbols. Passphrases ought to be 10 characters or more in length.

2. Secure the private key on the client

The private key should be secured from outside access, and placed where the ssh client program can access it, depending on which client is being used. For FreeBSD, the default location for the private key is $HOME/.ssh/id_dsa. See the client-specific documentation for information on other clients.

3. Copy the public key onto the VPS v2 server

Next, the public key should be copied onto the VPS v2 server. As the root user, edit the following file (you might need to create the /root/.ssh directory):

/root/.ssh/authorized_keys

Cut and paste the contents of the public key file into the authorized_keys file. You will need to make sure that the key is on a single line--line breaks inside the key will prevent it from being recognized. The authorized_keys file can contain multiple keys, one key per line.

4. Disable password access to the root account in sshd

While connected to the server as root, do the following:

- Edit /etc/ssh/sshd_config, and make sure the PermitRootLogin line is set like this:

PermitRootLogin without-password

- Restart sshd.

It is a good idea to make sure that you have an alternate method for connecting to root (using su, etc.) while testing access using SSH keys.

Assuming that everything is configured correctly, users whose public keys are listed in root's authorized_keys file should now be able to provide their passphrase and log into the VPS v2 account.