Linux SSH login – a good starting point

The steps below were included in a later article I wrote, regarding new Linux server installations, here which includes much more information from that aspect. The information below is still valid, useful, educational information which should be read if intending to start the process of hardening a Linux server. I apologize for the sloppiness of this, but I see no reason to copy and paste the same information into this article when it flows very naturally in the new article. You will thank yourself for reading both articles, however!

My environment:
Ubuntu Server 18.04 hosted in a datacenter, with a public IP used for administration and public use.
Windows client computer with SSH terminal program. (I highly suggest WinSSHTerm v2 for higher level usage)

The goal:
To run a server with SSH key login only.
To use password authentication for privilege escalation only.
To prevent unauthorized access, login and escalation, through various methods.

The server software:
OpenSSH (sshd – ssh daemon service)
fail2ban (intrusion prevention service)
Linux PAM (Pluggable Authentication Module)
UFW (Uncomplicated FireWall, in lieu of IPTables)

Additional software used for demonstration puroses:
MariaDB (A fork of MySQL, with some enhancements)
HAProxy (A layer 4 and 7 routing service (HTTP(S) and TCP-only proxy)
Hiawatha (HTTP daemon akin to Apache, with simpler configs, and a security focus)

The method:
Using the above software services, the GNU/Linux installation will be secure from intrusion from unauthorized and unauthenticated users (and user-like software). This process will include allowing TCP port 22 incoming access, and denying incoming access to all other ports (opening 22, closing everything else), until such time as additional ports are needed for access into the machine. All outbound connections will be allowed in this tutorial. Once UFW is enabled, external clients may connect only to port 22/TCP. Being OpenSSH will run on port 22, SSH is the only thing that can connect to the server. The next step will be to allow SSH key logins, ensure this is working correctly, and then disable password authentication on SSH. After getting the server to a point where only SSH with a key pair can connect to the server, fail2ban and PAM will be utilized to help mitigate brute-force attacks for login and privilege escalation (i.e. sudo and su usage).

The end result:
We’ll be using 5 pieces of software (Linux, SSH, fail2ban, PAM and UFW) as a starting point to secure a Linux server installation. These instructions are based around Ubuntu 18.04 LTS, but may be applicable to other distros and version. 18.04 is a SystemD based system, and some differences will occur for older, non-SysD installations. Before a Linux server can be of any use, it must be accessible. This can be through a local console (keyboard & monitor), through a remote console (such as many hosting companies provide for direct access, or which can be set up using a serial cable and terminal (often using a laptop connected to the server) – or by remote terminal access, via SSH (at this time, I do not know any other ways to access the main console or terminals of a Linux host) For this tutorial, we will assume SSH access will be used, even if console access is also used.

Users (potentially just the server admin, you, the reader perhaps) will gain access to the server with an SSH compatible client. This client will connect to TCP port 22 (possibly changed, will go over later in this article) The server will go through various methods of authenticating the connect, the supplied account, and credentials (SSH key). Upon successful connection and authentication, the user will have access to the server. If the user is granted sudoers privileges, the user can then use ‘su’ and ‘sudo’ to gain escalated (root) privileges. If, however, authentication fails, the user’s connection will be terminated. Multiple failures will invoke the user being banned, and from connecting at all. The user information will be added to a fail2ban jail, with configurable ban time (or permanent – but this is dangerous as if the admin somehow fails to login properly multiple times, the admin will have to gain direct console access to resolve the issue)

There will be a minimalized guide at the bottom with the basic information needed as a refresher for admins who understand the software and steps needed, but lack the confidence in blindly following memory to achieve this basic setup.

A synopsis of the steps needed:
Step 1 – Install and setup the Linux server, and accounts. This is the only time the root user account will be used to gain access to the system.

Step 2 – Install and set up UFW. This will include choosing to use the default SSH port, or modifying it. Changing the SSH port is “security by obscurity” – which can help mitigate SSH probing attempts, causing a lack of interest in your server to any hackers. Using the default port is still highly suggested, and though probes may find the port to be open, it will be very difficult for hackers to gain access. (Warning: These methods do not encompass software exploits which may exist in the SSH daemon, Linux, or any other software being used – This covers conventional, brute-force and guessing-game type attacks only)

Step 3 – Secure the SSHd to use SSH keys, and to then disable password login. Passwords will still be used by the system for authenticated users to gain su/sudo access.

Step 4 – Use PAM to mitigate authenticated user brute-force and guessing-game password escalation attempts, and to assist with SSH key login.

Step 5 – Ensure fail2ban is set up to ban malicious connections, and mitigate attacks on connection and escalation.

Step 6 – To use some commonly used user-accessible software services to demonstrate how to allow access to these services, including non-authentication public access (HAproxy and Hiawatha) and secure, private access (MariaDB) These demonstrations will provide a basis for understanding how to grant access to nearly any hosted service in a secure manner.

These 6 steps will give a BASE LINE level of security, and should not be counted on for 100% of a system’s security. There are many additional methods which can be utilized to harden a server system. Some options are additional software, replacement software, hardware firewalls, VPNs (Software and hardware) The extensiveness of advanced security and hardening is beyond the scope of this guide, but should be understood and researched as needed.

BluntAboutIT.com and I, the author do NOT make any guarantee to any end, and CANNOT be held accountable for security failure for any system which is set up using this guide. Again, this is a base line guide, but the admin must ensure that ALL security needs are met, including ensuring that every security measure needed is in use and properly functioning and using the latest available software. With that said, this guide can provide a good starting point for admins to secure their servers.

(At this time, I am publishing this page, with it incomplete and lacking any actual instructions. The information here is enough for a smart person to do some research and be able to begin the process, if not complete it. This tutorial will be updated at a later time to include instructional steps for installing, setting up and utilizing the software mentioned thus far. There may also be additions to what is currently published)

Leave a Reply

Your email address will not be published. Required fields are marked *