Initialize VPS UNPM Server

Now that the server is booted 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 (e.g. new or restored image, but same IP address or domain), a server it has never connected to, or connecting to a server in a new way, such as different subdomain or different port. 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 intended 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 the VPS provider assigned by right-clicking anywhere in the PuTTY window. 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
The firewall is disabled on the default server install. Uncomplicated Firewall (UFW) is a reasonably secure tool for managing firewalls and comes installed with every version Ubuntu.

For the server's initial setup, it is best to enable a complete firewall. However, if the SSH session is interrupted before setup spteps below are completed, 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 provider's terminal to complete the remaining steps, or start all over again by reinstalling the server.

root@servername:~# ufw enable

Ubuntu will ask to verify that  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  settings are changed in a later step.

Create new user and add to groups
It is very insecure to log in as, 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 root@servername:~# adduser username adm

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. The  group is still used by some legacy applications.

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 being successful. As an additional measure, a non-default port will be enabled in the firewall to allow access to SSH while the default port is disabled, reducing log noise.

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

The following commands will improve the quality of encryption:

root@servername:~# rm /etc/ssh/ssh_host_*key* root@servername:~# ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N "" < /dev/null root@servername:~# ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N "" < /dev/null root@servername:~# awk '$5 > 2000' /etc/ssh/moduli > "${HOME}/moduli" root@servername:~# wc -l "${HOME}/moduli" root@servername:~# mv "${HOME}/moduli" /etc/ssh/moduli root@servername:~# mv /etc/ssh/sshd_config /etc/ssh/original.sshd_config root@servername:~# nano /etc/ssh/sshd_config

Add:

Port randomunassignedportnumber KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256 Protocol 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_ed25519_key UsePrivilegeSeparation yes KeyRegenerationInterval 3600 ServerKeyBits 1024 SyslogFacility AUTH LogLevel INFO LoginGraceTime 120 PermitRootLogin no StrictModes yes Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com RSAAuthentication yes PubkeyAuthentication yes IgnoreRhosts yes RhostsRSAAuthentication no HostbasedAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication no PasswordAuthentication no ChallengeResponseAuthentication no X11Forwarding yes X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive yes AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server UsePAM yes AllowUsers username
 * 1) Package generated configuration file
 * 2) See the sshd_config(5) manpage for details
 * 1) What ports, IPs and protocols we listen for
 * 1) Use these options to restrict which interfaces/protocols sshd will bind to
 * 2) ListenAddress ::
 * 3) ListenAddress 0.0.0.0
 * 1) HostKeys for protocol version 2
 * 1) HostKey /etc/ssh/ssh_host_dsa_key
 * 2) HostKey /etc/ssh/ssh_host_ecdsa_key
 * 1) Privilege Separation is turned on for security
 * 1) Lifetime and size of ephemeral version 1 server key
 * 1) Logging
 * 1) Authentication:
 * 1) AuthorizedKeysFile    %h/.ssh/authorized_keys
 * 1) Don't read the user's ~/.rhosts and ~/.shosts files
 * 1) For this to work you will also need host keys in /etc/ssh_known_hosts
 * 1) similar for protocol version 2
 * 1) Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
 * 2) IgnoreUserKnownHosts yes
 * 1) To enable empty passwords, change to yes (NOT RECOMMENDED)
 * 1) Change to yes to enable challenge-response passwords (beware issues with
 * 2) some PAM modules and threads)
 * 1) Change to no to disable tunnelled clear text passwords
 * 1) Kerberos options
 * 2) KerberosAuthentication no
 * 3) KerberosGetAFSToken no
 * 4) KerberosOrLocalPasswd yes
 * 5) KerberosTicketCleanup yes
 * 1) GSSAPI options
 * 2) GSSAPIAuthentication no
 * 3) GSSAPICleanupCredentials yes
 * 1) UseLogin no
 * 1) MaxStartups 10:30:60
 * 2) Banner /etc/issue.net
 * 1) Allow client to pass locale environment variables
 * 1) Set this to 'yes' to enable PAM authentication, account processing,
 * 2) and session processing. If this is enabled, PAM authentication will
 * 3) be allowed through the ChallengeResponseAuthentication and
 * 4) PasswordAuthentication.  Depending on your PAM configuration,
 * 5) PAM authentication via ChallengeResponseAuthentication may bypass
 * 6) the setting of "PermitRootLogin yes
 * 7) If you just want the PAM account and session checks to run without
 * 8) PAM authentication, then enable this but set PasswordAuthentication

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 the comment symbol isn't displayed in the change, then remove the comment tag (and associated closing tags, as with HTML and PHP, when present). However, if there appears a misspelling or incorrect punctuation, case, etc., it may be wise to do a quick web search and verify that the guide being used is correct as 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 impace of brute force attacks hitting the server.

Verify new SSH settings
In the following steps it is important to keep track of the PuTTY window that contains the initial  session, as additional SSH sessions are created and closed in new PuTTY windows, do not to accidentally close the   session.

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  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 state that a public key is required for login.

Create another new session. Load the saved session, and in the menu in the left column, 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 a .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

Create and configure swap
Servers running on small amounts of RAM, such as the 512 MB and, depending on use case, 1 GB, may not have enough swap space or probably no swap configured at all. This can cause problems if applications are requiring more memory than the system provides, which typically results in system crash.

To check if there is any swap, type the following:

root@servername:~# swapon --show root@servername:~#

If nothing is displayed before the new command prompt, then swap has not been configured (as demonstrated in the above example), as can also be verified with the  command:

root@servername:~# free -h total       used        free      shared  buff/cache   available Mem:          487M        194M         36M         10M        256M        245M Swap:           0B          0B          0B

Verify that ample space exists in storage to support a swap partition:

root@servername:~# df -h Filesystem     Size  Used Avail Use% Mounted on udev            234M     0  234M   0% /dev tmpfs           49M  5.5M   43M  12% /run /dev/xvda1      20G  2.2G   18G  11% / tmpfs          242M     0  242M   0% /dev/shm tmpfs          5.0M     0  5.0M   0% /run/lock tmpfs          242M     0  242M   0% /sys/fs/cgroup tmpfs           49M     0   49M   0% /run/user/1001

Create a swap file that will use 1GB of space:

root@servername:~# fallocate -l 1G /swapfile root@servername:~# chmod 600 /swapfile root@servername:~# mkswap /swapfile root@servername:~# swapon /swapfile root@servername:~# swapon --show NAME     TYPE  SIZE USED PRIO /swapfile file 1024M  0B   -1 root@servername:~# free -h total       used        free      shared  buff/cache   available Mem:          487M        194M         36M         10M        256M        245M Swap:         1.0G          0B        1.0G

Configure swapiness and cach-pressure
The  and   can be adjusted to improve overall web server performance.

To see the current settings:

root@servername:~# cat /proc/sys/vm/swappiness 60 root@servername:~#

Improve performance by adjusting swappiness and cache pressure settings:

root@servername:~# sysctl vm.swappiness=10 root@servername:~# sysctl vm.vfs_cache_pressure=50

Make the changes permanent:

root@servername:~# cp /etc/fstab /etc/fstab.bak root@servername:~# echo '/swapfile none swap sw 0 0' | tee -a /etc/fstab root@servername:~# nano /etc/sysctl.conf

Add these two lines to the bottom of the file:

vm.swappiness=10 vm.vfs_cache_pressure=50

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 VPS is initialized, it's time to configure and learn about Ubuntu 18.04.