Initialize VPS UNPM Server

Now that the server is installed and running, it is time to log in and initialize it for use as a web server. Although this guide assumes the user is using Windows, a user on any platform could use these steps to initialize their server. This article is written with no assumption of experience, though it is more likely that more experienced users will not need it or will only need parts of it. However, all articles in this wiki assume the server is configured as described in this article.

Create users and groups

The server will require at least one administrative user account that will be a member of several additional groups.

Log into the server

If using PuTTY, open PuTTY and enter the server's IPv4 address in the 'Host Name (or IP address)' field. Enter the name of the server in the 'Saved Sessions' field, click 'Save', then 'Open'. PuTTY should connect to the server and display a message stating that the public fingerprint for the RSA key of the server is not in its cache. This message should only appear when connecting to a newly built server or to a server it has never connected to. If this message is displayed when no changes have been made to the server (such as rebuild or restore from image) and the fingerprint is expected to be stored in the cache, then the connection may not be trustworthy. PuTTY may not be connecting to the server and the user may be the target of a man-in-the-middle attack.

Select 'Yes' to continue. Log in as user root (as with nearly everything else in Linux, user names are case-sensitive), then paste in the password Rackspace assigned by right-clicking anywhere in PuTTY. When entering passwords, Linux will not move the cursor, so press enter after right-clicking in PuTTY.

Ubuntu will list the system status, also available with the command landscape-sysinfo and may state that updates are available, which will be addressed in a later step.

Raise the firewall

Rackspace provides no firewall on the default server install. Uncomplicated Firewall (UFW) is a reasonably secure tool for managing firewalls and comes installed in Ubuntu.

For the server's initial setup, it is best to enable a complete firewall. However, if the SSH session is interrupted before setup is complete, then it may not be possible to reestablish the connection. In the unlikely event that this happens, it will be necessary to log in through the terminal in the Rackspace control panel to complete the remaining steps.

root@servername:~# ufw enable

Linux will ask to verify that ufw is to be enabled because it may disrupt the existing SSH session. In the case of this server, enabling UFW will not disrupt the session, but it will not be possible to establish a new session until the UFW settings are changed in a later step.

Create new user and add to groups

It is very insecure to log in as root, so a new user should be created, then added to appropriate groups. The user may use any name desired, keeping in mind that the name is case-sensitive. It is also important to consider that the user's password is used to gain root access, and may be entered many times in a session, but will not be used for logging into the server via SSH.

The new user will need to be a member of several groups. The command used to create the user can also be used to add the user to a group.

root@servername:~# adduser username
root@servername:~# adduser username sudo

When using the adduser command to create a user, a home folder will be created for the user at /home/username/, a group will be created called username, and the user will be assigned to the group. The sudo group is only for users requiring root level permissions.

Change login method

Logging in with passwords is very insecure as it is susceptible to brute force attacks. Logging in with key pairs effectively prevents this from ever happening. As an additional measure, a non-default port will be enabled in the firewall to allow access to SSH.

Add user public key

Adding a public key to a user's authorized_keys file allows the user to log in using that key. Create the .ssh directory in the user's home folder. Opening a file that does not exist with nano will also create the file:

root@servername:~# mkdir /home/username/.ssh/
root@servername:~# nano /home/username/.ssh/authorized_keys

In the authorized_keys file, paste in the device's public key from the OpenSSH Public Key file on the local device, then save the file (ctrl+o) and exit (ctrl+x). Additional device keys may be added to the authorized_keys file. Simply place each key on its own line to allow multiple devices to log in using the same user account.

The user will not be able to log in by key authentication if it is not the owner of the /.ssh/ directory and the authorized_keys file. It is also not necessary for any other user to access this user's home directory, so permissions can be set for this.

root@servername:~# chown -R username:username /home/username/.ssh/
root@servername:~# chmod 750 /home/username/
root@servername:~# chmod 600 /home/username/.ssh/authorized_keys

Set up SSH

The config file for SSH should be edited to prevent the root user from logging in, prevent password login, allow only specified users to login, and tell SSH to use a non-standard port. Though it is first a good idea to make a backup of the original file.

root@servername:~# cp /etc/ssh/sshd_config /etc/ssh/original.sshd_config
root@servername:~# nano /etc/ssh/sshd_config

Change:

Port randomunassignedportnumber

PermitRootLogin no

PasswordAuthentication no

Add at the bottom of the file:

AllowUsers username

Generally, when using instructions such as this wiki, the text will be exactly what should be in the file, with obvious exceptions such as username, servername, example.com, and occasional unique, yet still fairly obvious variables such as randomeunassignedportnumber from the above example. Also of note, if the existing text in the file being edited is commented out, but comment isn't displayed in the change, then remove the comment tag (and associated closing tags, as with HTML and PHP, if present). However, if there appears a misspelling or incorrect punctuation, case, etc., it may be wise to do a quick search and verify that the guide being used is correct. These guides are generally human-generated.

To find an unassigned port number, the Wikipedia article containing the list is a bit easier to read than the official IANA list. Whatever port number is used, it will have to be used for all clients using SSH and related services, such as SFTP.

Restart the SSH service to implement the changes:

root@servername:~# service ssh restart

Configure the firewall for new SSH port

UFW can be used to allow specific ports, protocols, and installed applications. Here are some useful UFW command options and their outputs with the current configuration:

root@servername:~# ufw status
Status: active
root@servername:~# ufw app list
Available applications:
 OpenSSH

The OpenSSH application settings, though available, will not be used for this server setup because the server is using a non-standard SSH port. Allow the port entered into the sshd_config file:

root@servername:~# ufw limit randomunassignedportnumber/tcp

Using the limit rule reduces the effectiveness of brute force attacks hitting the server.

Verify new SSH settings

Use PuTTY to create a new SSH session without closing the current one. A quick way to do this is to use the drop-down menu available in the top left corner of the PuTTY window. To test if a session can be created that is identical to the current session, click 'Duplicate Session'. This will open a new PuTTY session window which should time out as the firewall rules will not acknowledge anything on port 22.

Create a new session by clicking 'New Session...' from the drop-down menu. Select the saved session from the previous step, but change to the port number entered into sshd_config, and click 'Save' to save current settings to the 'Saved Session'. Click 'Open' and attempt to login as username. Note that PuTTY will find a new key fingerprint with the new port. The server should reject the login attempt.

Create another new session. Load the saved session, and in the menu in the left, navigate to Connection -> SSH -> Auth. Under ‘Private key file for authentication’ click ‘Browse’ and select the private key associated with the public key on the server (note that the file used for PuTTY and most Windows applications is .ppk file, which is a different format from an OpenSSH file - what Linux uses). Click ‘Session’ at the top of the left sidebar and save the settings, then 'Open'. Attempt to log in as root. The server should deny the attempt and close the session. 'Restart Session' using the window's menu and enter username. The server should accept the credentials and open a session with username.

username@servername:~$

Verify the new user is a member of the sudo group by creating a test file using the sudo command.

username@servername:~$ sudo touch test
[sudo] password for username:

Entering the password should create the new file test. Use the ll command to verify the new file is owned by root and then remove it using rm:

username@servername:~$ ll test
-rw-r--r--  1 root root     5 Aug 14 21:55 test
username@servername:~$ sudo rm test

If the server did not allow login

If the server did not allow the session to be created, first verify that the username is spelled correctly in PuTTY when logging in, then check that the path to /home/username/.ssh/authorized_keys is correctly spelled and has correct ownership and permissions (easily done using the ll command):

root@servername:~# ll /home/username/
root@servername:~# ll /home/username/.ssh/

Next verify that the public key has been entered without error into authorized_keys. Everything needs to be precisely as PuTTY created it, and it should all be on one line. Note that nano will indicate a line is longer than the screen can display by placing a $ at the end of the line. To review the contents of the line, it can be more convenient to press enter just before the $, and do this until all of the key is displayed on several lines. Do not save the file in this configuration, just use it to verify the key is completely entered and accurate.

If that all checks out, go back into /etc/ssh/sshd_config and verify all settings were changed correctly.

If none of that works, check everything again (and possibly yet again), or restore the backup made of the original sshd_config file and edit the settings, as it is possible a setting was accidentally changed.

root@servername:~# mv /etc/ssh/sshd_config /etc/ssh/suspect.sshd_config
root@servername:~# cp /etc/ssh/original.sshd_config /etc/ssh/sshd_config
root@servername:~# nano /etc/ssh/sshd_config
root@servername:~# service ssh restart

Log out of root

After the SSH settings have been verified and username has logged in, it is no longer necessary to log in as root ever again.

root@servername:~# logout

Set up PuTTY to use SSH as proxy

It is possible to use SSH as a web proxy. This can protect a user's privacy when browsing public networks such as cafés, hotels and airports as all communications will be sent through the encrypted session.

To set up PuTTY to act as a proxy, open PuTTY and Load the Saved Session to be used as a proxy. In the Category menu in the left, navigate to Connection->SSH->Tunnels. In the Source Port field enter the local port to be used - any port not currently in use will work. Select the 'Dynamic' radio button then click 'Add'. Return to the 'Session' page, save the session, then open it. Browser configurations vary based on browsers to be used. Take care to make sure whatever proxy method is used, DNS lookups are also performed through SSH session as this may not be the default setting.