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 the 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  (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  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  command to create a user, a home folder will be created for the user at , a group will be created called  , and the user will be assigned to the group. The  group is only for users requiring   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  file allows the user to log in using that key. Create the  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  file, paste in the device's public key from the OpenSSH Public Key file on the local device, then save the file  and exit. Additional device keys may be added to the  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  directory and the   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  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,  ,  , and occasional unique, yet still fairly obvious variables such as   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  file:

root@servername:~# ufw limit randomunassignedportnumber/tcp

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

Verify new SSH settings
It is also important to keep track of the PuTTY window that contains the  session, as additional SSH sessions are created and closed in new PuTTY windows, do not to accidentally close the   session. This session can be identified by looking at the PuTTY window header, which will read.

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, and click 'Save' to save current settings to the 'Saved Session'. Click 'Open' and attempt to login as. Note that PuTTY will find a new key fingerprint with the new port. The server should reject the login attempt and that a public key is required for login.

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. The server should deny the attempt and close the session. 'Restart Session' using the drop-down menu and enter. The server should accept the credentials and open a session with.

username@servername:~$

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

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

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

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  is spelled correctly in PuTTY when logging in, then check that the path to   is correctly spelled and has correct ownership and permissions (easily done using the   command):

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

Next verify that the public key has been entered without error into. Everything needs to be precisely as PuTTY created it, and it should all be on one line. Note that  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  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  file and edit the settings as per above again, as it is possible a different 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,  has logged in and verified   membership, it is no longer necessary to log in as   ever again.

root@servername:~# logout

Next step
Now that the Rackspace service is initialized, it's time to configure and learn about Ubuntu 12.04.