Setting up secure remote support options (Simple)

Most DevOps manage their servers remotely using SSH. Of course there are other options, such as web-based management interfaces (like Webmin) and graphical interface management options, such as Virtual Network Computing (VNC), Remote Desktop Protocol (RDP), and TeamViewer. In this recipe, we'll go through SSH as a more secure and productive way that we suggest for secure remote management and support.

Getting started

Consistent with the practice of reducing the attack surface by shutting down unused services, graphical user interfaces and remote desktop services are usually considered bad practice on web servers. That's why SSH is king. Web-based management interfaces might be useful, but they can also pose security risks. If you decide to implement any of these solutions, you should have clear firewall restrictions in place and keep your software up-to-date.

Also, there's an important consideration regarding identity management on production servers. When your support team grows, you'll want to have audit capabilities built-in for your employees (and it might also be required by your company's security policies/practices as well as industry regulations), so this recipe will cover it as well.

How to do it…

1. Install the OpenSSH server by using the command apt-get install ssh; among other things, this will generate a set of keys for your OpenSSH server. You should take note of them the first time you connect to the server as they will help you verify whether you're remotely connecting to the right server (and OpenSSH clients will warn you if those fingerprints change).

2. Now, from a remote server or client (including PuTTY or Cygwin on Windows) run [e-mail]; you should receive a fingerprint warning (which you should double-check and accept if correct), and then you will be presented with a prompt.

3. The defaults for OpenSSH are OK for most setups. You might want to change banners or ports as necessary. The reason why people change SSH's default port (TCP 22) is because it's widely known and scanned on IPv4 subnets. If you have a dedicated security hardware in place and/or will not expose the port to globally routable IPv4 networks, you might as well leave the default.

4. There is one exception though. OpenSSH is allowing root to login, which is not considered a good practice.

5. Fire up your editor and make changes to /etc/ssh/sshd_config; search for the PermitRootLogin directive and change it to no.

6. Then restart OpenSSH by using the command service ssh restart.

7. Actually, using root for administrative purposes is also not seen as a good practice. You should use sudo, which will enhance your audit capabilities and eventually allow better privilege separation using the command apt-get install sudo.

8. We will make a simple change with the existing non-privileged user we created that goes a long way for security in terms of audit and skill building.

9. To do so, use the command usermod –aG sudo devops.

10. By adding devops to the sudo group, they will be able to use sudo to escalate. This is only a first step that provides better insights and practices for audit, but you need to granularize sudo per user as necessary and not see it as a drop-in root replacement—in which case you would only have achieved minimal auditing capabilities and no real positive security outcomes.

11. Now type exit (or press Ctrl+D) to exit the root login, and login as devops.

12. Prepend sudo to the commands that need administrative privileges from now on. You will be asked for your password once in a while for added security. You can now change the root password to a very long, unique, and complex password and hopefully never login as root again. From now on, the book will use the sudo command when needed to specify that administrative rights are needed.