Justin Franks

Web Development, Linux Administration, Firearms, and Photography

Upgrade OpenVZ VPS from Debian 7 (wheezy) 64-bit to Debian 8 (jessie) 64-bit

Debian 8.0 (jessie) has been released! But there is no official OpenVZ template for jessie yet, and past experience indicates that it could be a long wait. In the meantime, here is how I upgraded an OpenVZ VPS with a fresh install of the official Debian 7 (64-bit) minimal template to Debian 8. It is just a little bit tricky, since the official OpenVZ Debian 7 minimal template uses upstart, not sysvinit (the default for Debian 7) or systemd (the default for Debian 8). Since upstart is now deprecated with the adoption of systemd, these instructions include replacing upstart with systemd.

NOTE: This guide is intended only for a fresh reinstallation of the 64-bit Debian 7 minimal template. These procedures have been tested on a BuyVM OpenVZ VPS with the 64-bit Debian 7 template (BuyVM offers the minimal template only). If you are using a different Debian 7 template, or are trying to upgrade an existing system, certain commands may need to be modified in order to ensure a successful upgrade. Proceed at your own risk.

1. Open an SSH connection to your VPS and log in as root.

2. Update the Apt sources.list to point to the Jessie repositories.

rm /etc/apt/sources.list
cat > /etc/apt/sources.list << EOF
deb http://ftp.us.debian.org/debian/ jessie main non-free contrib
deb-src http://ftp.us.debian.org/debian/ jessie main non-free contrib
deb http://security.debian.org/ jessie/updates main contrib non-free
deb-src http://security.debian.org/ jessie/updates main contrib non-free
deb http://ftp.us.debian.org/debian/ jessie-updates main contrib non-free
deb-src http://ftp.us.debian.org/debian/ jessie-updates main contrib non-free
EOF

3. Verify that the sources.list was properly created.

cat /etc/apt/sources.list

It should look like this.

deb http://ftp.us.debian.org/debian/ jessie main non-free contrib
deb-src http://ftp.us.debian.org/debian/ jessie main non-free contrib
deb http://security.debian.org/ jessie/updates main contrib non-free
deb-src http://security.debian.org/ jessie/updates main contrib non-free
deb http://ftp.us.debian.org/debian/ jessie-updates main contrib non-free
deb-src http://ftp.us.debian.org/debian/ jessie-updates main contrib non-free

4. Grab the new lists of packages.

apt-get update

5. Reinstall the debian-archive-keyring package if you see any missing public key warnings.

apt-get install --reinstall debian-archive-keyring

6. Install dialog (shows nice dialog windows, used by the locales configuration and many package installations which require user input).

apt-get -y install dialog

7. Set your system locales.

dpkg-reconfigure locales

7a. In most cases, the UTF-8 version of the language you are using is the best locale to generate. For American English, this would be en_US.UTF-8.

7b. Select en_US.UTF-8 (or the UTF-8 version of the language you are using) by scrolling down in the list, hitting the spacebar to select it, and pressing enter to move on.

7c. The next dialog box will ask you to choose the default locale for the entire system. Press the up or down arrow keys to highlight “en_US.UTF-8″ or the language you selected in the previous step, then press enter to finish locale generation and configuration.

8. Perform the upgrade! (This will take a while, but don’t leave, because there are a few things you need to do during the process).

apt-get -y dist-upgrade

8a. When you reach the message “Configuration file ‘/etc/bash.bashrc’ has been modified since installation”, choose ‘Y’ to install the new version.

8b. When you reach the message “Configuration file ‘/etc/init/networking.conf’ has been modified since installation”, again choose ‘Y’ to install the new version.

8c. When you reach the dialog box warning you about logging in as root over SSH using password authentication, choose “No” to keep SSH password authentication for root enabled. You will disable this later, once you have added your own user account with sudo privileges.

9. Verify that you are now running Debian 8 (it should show 8.x).

cat /etc/debian_version

10. Swap out upstart for systemd.

apt-get -y install systemd systemd-sysv

11. Force a reboot to start using the new init.

reboot -f

12. Log back in to your VPS via SSH as root.

13. Verify that systemd is running, not upstart (you should see only systemd processes, no upstart processes).

ps aux | grep -E "(systemd)|(upstart)" | grep -v "grep -E"

14. Purge upstart (it was not automatically removed when systemd was installed since it was running at that time).

apt-get -y purge upstart
rm -r /var/log/upstart

15. Remove the 32-bit packages from the package lists (just an annoyance, there is no need to see both the 32-bit and 64-bit versions of packages on a 64-bit system).

dpkg --remove-architecture i386

16. Install some more essential or handy packages.

apt-get -y install nano apt-rdepends aptitude curl sudo

17. Install one more essential package (cron), but without installing recommended packages. Cron recommends a mail server be installed, and the default mail server for Debian is the full-featured Exim package. If you plan on using Exim, do not include the “–no-install-recommends” option.

apt-get -y install --no-install-recommends cron

18. Verify that no other essential packages are missing.

aptitude search "?essential" | grep -v "^i"

19. If no results are shown, then all essential packages are already installed. If any results are found, then essential packages are missing and you need to install them. Insert the package names, each separated by a space.

apt-get -y install package_name package_name_2 package_name_3 . . .

20. Add your own user account for day-to-day administration of the server (inserting in your own username of course).

adduser justin

20a. Enter in your desired password twice. The rest of the information is optional, but I like to at least put in my full name, leaving all other fields blank. Verify that all of the information is correct, then choose “Y”.

21. Add your user account to the “sudo” group to obtain sudo privileges. I also advise adding yourself to the “adm” group, because many log files are not readable unless you are a member of that group. It just makes things easier, since you don’t have to “sudo cat /var/log/log_name” each time you want to view one of these log files.

usermod -a -G sudo,adm justin

22. Verify that your account has been added to the correct groups (you should see “justin : justin adm sudo”).

groups justin

23. Secure SSH by switching the port from the default (port 22), disabling root logins entirely, and only allowing logins by your user account you just created.

nano /etc/ssh/sshd_config

23a. Change “Port 22″ to an unused port over 1024. Check this Wikipedia page to find a port that will not be used by any services you plan to run on your VPS.

23b. Under “Authentication”, change “PermitRootLogin yes” to “PermitRootLogin no” to disable root logins.

23c. Also under “Authentication”, add the following line, inserting your username, not mine of course.

AllowUsers justin

23d. If you have multiple users that need to access this VPS via SSH, use a comma to separate each username.

AllowUsers justin,brad,danielle,tom

23e. Save the file and exit by hitting Control + X, typing ‘Y’, then pressing Enter.

24. Reload the SSH daemon so the new port and security settings are applied.

systemctl reload ssh.service

25. Open a new terminal window. (Do NOT close this terminal window just yet, because if you messed up the SSH configuration, you may have inadvertently blocked yourself from opening a new SSH connection).

26. Login to your VPS using your new account and the new SSH port.

ssh -l justin -p <port_number> <server_ip_address>

27. Verify that your sudo privileges are working properly. Enter in your password when prompted after the “With great power comes great responsibility” spiel.

sudo w

28. If the ‘w’ command runs properly, you can safely close the other terminal window where you were logged in as root.

29. You’re done! You now have a fresh minimal install of Debian 8 on your VPS.

Debian 6 (“Squeeze”) server initial setup

NOTE: Not yet complete!

This is a step-by-step guide on the initial setup and configuration of an unmanaged VPS or dedicated server running Debian 6 (“Squeeze”). It will include detailed explanations of all of the concepts and commands being run, and as such is written for people new to Linux administration. More advanced users can skim through the guide and simply enter in the commands (or write a script to automate this setup process).

What is covered in this guide

  • Initial updating of all software currently installed
  • Creation of a new user account with sudo privileges in order to run commands as root to administer the server
  • Securing SSH by switching the default port, disallowing direct root logins, and specifically allowing only certain users access (generating SSH keys for added security will be covered in a separate article)
  • iptables (firewall) setup and configuration
  • Creating a custom shell prompt that is much more informative and useful than the standard prompt
  • Creating aliases for commonly-used commands and options
  • Setting the correct time zone
  • Generating and selecting the correct locale
  • Installing essential tools for adding software, including build tools for software for which there are no pre-built packages

Initial Login via SSH

As soon as you have the IP address and root password for your new server, log in via SSH (replace 1.2.3.4 with the server’s IP address).

ssh -l root 1.2.3.4

Debian should have already set up the proper $PATH environment variable to run the commands in the rest of this guide, but we will first verify this. The $PATH environment variable defines a list of directories to search through when looking for a command to execute.

To check the current $PATH, run the following command:

echo $PATH

You should see the following:

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

If you do not, this command will set the correct path:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

With the path properly set, we can now begin setting up your new server. 

Changing the root password

You should immediately change the root password by using the passwd command.

passwd

You will be prompted to enter the root password twice. After completing this setup guide, logging on as the root user is not recommended for security reasons. In fact, later on we will be removing the ability to log in directly as root via SSH. Instead, an additional user account will be created with the ability to run commands as root with a tool called sudo.

Package managers and updating the server

The Debian operating system is frequently updated with new versions of installed software, security updates, and bug fixes. There is a good chance that the version which is installed on your server is out of date, so we will use the aptitude tool to update the system.

Aptitude is a package manager — a tool that allows you to easily install, update, or remove various software packages on your server. Often, a certain piece of software requires other software packages to be present on your system in order to run. These additional pieces of software are called dependencies, and in the past (before package managers existed) it could be a difficult and time-consuming task to find and install all of the dependencies. Often, one piece of software would depend on several other software packages, each of which had dependencies of their own, and so forth. Keeping track of all of the dependencies could quickly become close to impossible.

Things got even more complicated when you needed to remove a piece of software. It is never good to have pieces of software on your server that you do not need, because every piece of software is a potential security vulnerability or source of bugs. So when removing software packages, it is best to remove its dependencies as well. But more often than not, a dependency of abc is also a dependency of xyz, and removing that dependency will break xyz. So the trick is to only remove what are known as orphaned depedencies — dependencies that are only required by the package that is to be removed.

It should be obvious that keeping track of dependencies can quickly become overwhelmingly difficult and prone to errors. This is the reason why package managers such as Debian’s aptitude tool are essential to the system administrator. Package managers keep track of the dependencies of each piece of software installed on the system. When you install a new piece of software with a package manager, all of its dependencies (and all of each dependency’s own dependencies) are installed automatically. Similarly, package managers allow you to remove a piece of software without accidentally removing one of its dependencies required by other packages installed on your system.

So now that you know what a package manager does, let’s use Debian’s aptitude package manager to automatically update all of the software packages already installed on your server.

First, we need to update the package manager’s own list of available packages.

aptitude update

If you get a command not found error, it means that your system does not have the aptitude package manager already installed. This is not a major issue, because all Debian systems come with an additional package manager called apt-get. Just run the following command to install aptitude:

apt-get -y install aptitude

Why two different package managers (apt-get and aptitude)? Aptitude is a newer addition to Debian than apt-get, and offers several advantages over the older tool. Both tools can be used through the command line, but aptitude also includes a text-based user interface that allows you to easily browse through all of the available packages, while apt-get is strictly a command line-only tool. Aptitude also has (according to Debian) a more advanced dependency resolver than apt-get.

If aptitude is “better” than apt-get, why is apt-get still included? The major reason is that old habits die hard. Apt-get was released prior to aptitude, and people tend to use what they are most comfortable with. While both package managers can be used interchangeably, some Debian users suggest that you choose one and stick with it.

For new users, I would recommend using aptitude over apt-get. However, if you already have experience with Debian and want to use apt-get, that is perfectly fine. Simply replace any aptitude commands in this guide with the appropriate apt-get command.

With the matter of package manager preference settled, we now will update the system itself.

aptitude -y full-upgrade

The -y option will install the updates automatically without further prompting from you.

Creating a new user account with sudo privileges

Now that your server is up to date, we will create a new user account.

adduser justin

You will be asked to enter a password twice for the new account. Afterwards, you will be prompted to enter in information about the new user, all of which are optional — you can simply press enter until you are brought back to the SSH prompt.

Next, we need to give your next user account the ability to run administrative tasks as the root user, via the sudo command. A file called the sudoers file controls this access, and it is located at /etc/sudoers. However, this file need not (and should not) be edited directly. Instead, we will use the visudo command.

visudo

If you get a command not found error, the sudo tool might not be installed. This is rare, but still possible depending on the specific Debian image used by your VPS or dedicated server provider. Install the sudo package with the following command:

aptitude -y install sudo

Visudo launches the standard Debian text editor nano to edit the /etc/sudoers file. Add the following line at the end of the file:

justin ALL=(ALL) ALL

Exit the editor by pressing Ctrl-X, making sure to save the changes by pressing Y.

Configuring and securing SSH

SSH is a common target for attacks, because every server uses it, and it gives direct access to the filesystem. Therefore, there are measures that need to be taken to improve security. These include changing the default SSH port (22), disallowing direct root logins, and explicitly allowing direct logins using only the user account we just created.

There is another recommended security measure which requires user to use a key pair for authentication rather than a typical password. While this is more secure than using passwords, it is a bit more complex to set up and will be explained in a separate article.

To secure SSH, we need to edit its configuration file, which is located at /etc/ssh/sshd_config.

nano /etc/ssh/sshd_config

We will be searching for various configuration options and changing the values. In the event that your particular installation does not have one or more of the lines we are searching for, you can simply add it in a new line at the bottom of the file.

To change the SSH port, locate the following line:

Port 22

Change the 22 to a number of your choice between 1024 and 65535. Be careful not to use a port that will be used by any services you plan to run on your server (for example, the MySQL database server uses port 3306 by default). If you are not sure which port to use, you can reference this list of commonly-used ports on Wikipedia — simply choose a port between 1024 and 65535 not present on that list.

For this example, we will use port 3456, so the line in the SSH configuration file should look like this:

Port 3456

To disable direct root logins, locate the following line:

PermitRootLogin yes

And change it to:

PermitRootLogin no

Finally, we will restrict access to the server to only the user account we created earlier. Add the following line to the SSH configuration file:

AllowUsers justin

If you have additional user accounts that require SSH access, you can grant access by adding multiple usernames to the same line. For example, to give the user accounts justin and bob access, enter the following:

AllowUsers justin bob

Exit and save the new configuration by pressing Ctrl-X, then Y.

Now that the new, more secured SSH configuration is saved, we must reload the service to apply our changes. In Debian, there are scripts stored in the /etc/init.d directory which allow you to start, stop, and reload services — the SSH daemon, web server, database server, and so forth — installed on the system.

To reload the SSH configuration, run this command:

/etc/init.d/ssh reload

If you see the following message, the new configuration has been applied:

Reloading OpenBSD Secure Shell server's configuration: sshd.

Very important: We must test the new configuration before closing the terminal window. If you’ve made an error in the SSH configuration, you may lock yourself out of the system.

In a new terminal window, try to connect to your server with the new port and username. Replace 3456 with the alternative SSH port you chose above, justin with the new account username, and 1.2.3.4 with the IP address of your server.

ssh -p 3456 -l justin 1.2.3.4

If all goes well, you will enter your password when prompted and be brought to the command prompt. Next, we must verify that the new user account has sudo access.

sudo ls

This will run the ls command (lists the files in the current directory). Enter in your password when prompted.

Your home directory, where you are brought when you log in via SSH, will most likely be empty so you may not see any output. All that really matters is that you do not get any error message such as Permission denied or User is not in the sudoers file. This incident will be reported, you are good to go and can close the first terminal window where you initially logged in as root.

If you do see an error message, go through the earlier parts of this guide again, verifying that your new user account is properly set up with sudo access and that your SSH configuration is correct.

Now that you have got this far, you will never need to log in as the root user (in fact, you won’t even be able to since we disabled direct root logins). Whenever you need to run a command which requires root access, such as installing new software packages or editing configuration files, simply preface the command with sudo.

The Linux firewall: iptables

(much, much more to come)

Things to come…

My name is Justin Franks and I am a web developer and database administrator from New Jersey.

This site will be focused on Linux server management (particularly CentOS and Debian, the two distributions I have the most experience with) and web development with PHP5, CakePHP, and WordPress.

Initial planned articles include guides targeted for the newcomer on setting up and securing a VPS or dedicated server, installing Apache/nginx, MySQL, and PHP, setting up a mail server with virtual users and automatic spam/virus protection, and getting WordPress sites and CakePHP apps running well, even with the limited resources of an entry-level VPS.

I will also include, from time to time, posts about my two main hobbies, photography and firearms. It might seem strange that a computer programmer from New Jersey is “into guns”, which is one of the reasons why I will be including my thoughts on the subject, including how (and why) I made the transition from staunch gun control supporter to legal firearms owner and Second Amendment supporter in the decidedly anti-gun state of New Jersey.

CentOS 5.x server initial setup

NOTE: Not yet complete!

This is a step-by-step guide on the initial setup and configuration of an unmanaged VPS or dedicated server running Centos 5. It will include detailed explanations of all of the concepts and commands being run, and as such is written for people new to Linux administration. More advanced users can skim through the guide and simply enter in the commands (or write a script to automate this setup process).

What is covered in this guide

  • Initial updating of all software currently installed
  • Creation of a new user account with sudo privileges in order to run commands as root to administer the server
  • Securing SSH by switching the default port, disallowing direct root logins, and generating SSH keys for added security
  • iptables (firewall) setup and configuration
  • Creating a custom shell prompt that is much more informative and useful than the standard prompt
  • Creating aliases for commonly-used commands and options
  • Setting the correct time zone
  • Generating and selecting the correct locale
  • Installing essential tools for adding software, including build tools for software for which there are no pre-built packages

Initial Login via SSH

As soon as you have the IP address and root password for your new server, log in via SSH.

ssh -l root 1.2.3.4

CentOS should have already set up the proper $PATH environment variable to run the commands in the rest of this guide, but we will first verify this. The $PATH environment variable defines a list of directories to search through when looking for a command to execute.

To check the current $PATH, run the following command:

echo $PATH

You should see the following:

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

If you do not, this command will set the correct path:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

With the path properly set, we can now begin setting up your new server. 

Changing the root password

You should immediately change the root password by using the passwd command.

passwd

You will be prompted to enter the root password twice. After completing this setup guide, logging on as the root user is not recommended for security reasons. In fact, later on we will be removing the ability to log in directly as root via SSH. Instead, an additional user account will be created with the ability to run commands as root with a tool called sudo.

Package managers and updating the server

The CentOS operating system is frequently updated with new versions of installed software, security updates, and bug fixes. There is a good chance that the version which is installed on your server is out of date, so we will use the yum tool to update the system.

Yum is a package manager — a tool that allows you to easily install, update, or remove various software packages on your server. Often, a certain piece of software requires other software packages to be present on your system in order to run. These additional pieces of software are called dependencies, and in the past (before package managers existed) it could be a difficult and time-consuming task to find and install all of the dependencies. Often, one piece of software would depend on several other software packages, each of which had dependencies of their own, and so forth. Keeping track of all of the dependencies could quickly become close to impossible.

Things got even more complicated when you needed to remove a piece of software. It is never good to have pieces of software on your server that you do not need, because every piece of software is a potential security vulnerability or source of bugs. So when removing software packages, it is best to remove its dependencies as well. But more often than not, a dependency of abc is also a dependency of xyz, and removing that dependency will break xyz. So the trick is to only remove what are known as orphaned depedencies — dependencies that are only required by the package that is to be removed.

It should be obvious that keeping track of dependencies can quickly become overwhelmingly difficult and prone to errors. This is the reason why package managers such as yum are essential to the system administrator. Package managers keep track of the dependencies of each piece of software installed on the system. When you install a new piece of software with a package manager, all of its dependencies (and all of each dependency’s own dependencies) are installed automatically. Similarly, package managers allow you to remove a piece of software without accidentally removing one of its dependencies required by other packages installed on your system.

So now that you know what a package manager does, let’s use the CentOS yum package manager to automatically update all of the software packages already installed on your server.

yum -y upgrade

The -y option will install the updates automatically without further prompting from you.

Creating a new user account with sudo privileges

Now that your server is up to date, we will create a new user account. For this command and all that follow, replace justin with the desired username.

adduser justin

Next we set the password for the new user.

passwd justin

You will be asked to enter a password twice for the new account.

Next, we need to give your next user account the ability to run administrative tasks as the root user, via the sudo command. A file called the sudoers file controls this access, and it is located at /etc/sudoers. However, this file need not (and should not) be edited directly. Instead, we will use the visudo command.

visudo

If you get a command not found error, the sudo tool might not be installed. This is rare, but still possible depending on the specific CentOS image used by your VPS or dedicated server provider. Install the sudo package with the following command:

yum -y install sudo

Visudo launches the standard CentOS text editor vi to edit the /etc/sudoers file. We need to add a line to the bottom of this file in order to give the new user the proper permissions to use the sudo tool.

  1. Scroll down to the end of the file by pressing Shift-G (a capital G).
  2. Press i to enter insert mode.
  3. Type or copy and paste the following text:

    ## Allow user 'justin' to run any commands anywhere
    justin    ALL=(ALL)       ALL
  4. Leave insert mode by pressing Esc.
  5. Save the file and quit by typing :wq (colon wq) then pressing Enter.

Configuring and securing SSH

SSH is a common target for attacks, because every server uses it, and it gives direct access to the filesystem. Therefore, there are measures that need to be taken to improve security.

Normally, you connect to a server via SSH with a username and password. An optional feature is the requirement to use a key pair for authentication instead of a password. A key pair consists of two keys (in simple terms, a very long and complex password) — a public key and a private key. The public key is stored on the server, and the private key on the computer you use to connect to the server. When you attempt to log in to your server, it uses a mathematic algorithm to match up the public and private keys.

The strength of this method of authentication is the fact that the algorithm used is one-way — it is very simple to verify that the private key stored on your computer matches the public key on the server, but extremely difficult to generate or guess the correct private key, even if you already know the public key.

Public key cryptography is commonly used for browsing the Internet using SSL — when you log in to your bank’s website to manage your account, public key cryptography is used to encrypt the data to protect it from prying eyes. It is a proven system, and makes your server much less vulnerable to attack via SSH.

The downside is that you must have the private key stored on the computer you want to use to access your server. This is only practical and secure if you only need to connect to your server from a single computer, and that you are the only user of that computer. If you need or want to be able to connect to your server from another location (when you are away from home, for example), or you are on a shared workstation, it would be best to simply use a normal password. Don’t worry, we will be taking additional steps to secure your server from SSH attacks.
(much, much more to come)