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. We have additional information on what constitutes a strong password.
  • 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

Direct shell access to the root user account is not allowed. 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.

For additional administrators you must configure administrative accounts in /etc/group and add those users. 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 were provided the admin username and password when you ordered your VPS v2 account) 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:


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
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. This limits access to PCs with the private key file installed. Password logins as root are disallowed. Access via admin accounts as described in Method 1 also works alongside this method.

Note: If you are using another client, such as PuTTY or WinSCP, you will need to generate the keys with your SSH client. Please see configuring SSH Keys for instructions.

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) (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):


    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.

    Note: on Linux, this file is named authorized_keys2.

  4. Disable password access to the root account in sshd

    After May 4th, 2005, the default setting for all new VPS accounts has password access to the root account disabled. You will only need to edit sshd_config if the PermitRootLogin line is NOT set like this:

    PermitRootLogin without-password

    If the PermitRootLogin line is NOT set like the above, then do the following while connected to the server as root:

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

Please note: the information on this page applies to ITS web hosting plans. It may or may not apply to other environments. If you are looking for a feature described here, or better support from your hosting provider, please consider hosting your site with ITS!

1555 N Naperville/Wheaton Road, Suite 107
Naperville, IL 60563
phone 630.420.2550
fax 630.420.2771