How to Secure SSH Access on a Linux Server

Introduction

Secure Shell (SSH) provides an encrypted connection for administrators to manage Linux servers. SSH can be easily exploited to gain access and manage server resources. Compromised SSH credentials can result in the unauthorized modification of server configuration, installation of unauthorized software, and access to secured files.

Misconfigured SSH can be exploited to gain unauthorized access to a server, but securing SSH does not require deploying overly complex configuration to a server. Securing SSH can be achieved with appropriate restriction of access to the service, strengthening of access control and authentication, and auditing of access to the service.

What is SSH?

Secure Shell (SSH) is a communication protocol that allows users to connect to other computers and access command-line interfaces for management. SSH is used for management of systems over unsecured or insecure networks.

On a Linux server, SSH provides a secure channel for remote control. It provides a secure environment for the execution of commands, transfer of files using Secure Copy (SCP) or Secure File Transfer Protocol (SFTP), and building VPN tunnels.

Public key cryptography is an available mode of SSH administration. This mode does not transfer the user’s private key across the network. The server stores the public key and validates the user against the public key.

The protection provided by SSH for the tunneled connection does not provide security for the server. Other factors like insecure or default administrative accounts, open or unrestricted administrative accounts, and unsecured/administrative SSH tunnels provide other vulnerable attack vectors.

For a deeper understanding of SSH, its authentication methods, and how secure remote connections work, read our guide on What Is SSH?

How Does an SSH Connection Work?

An SSH connection is initiated when an SSH client communicates with an SSH server on a target machine. After connection establishment and session setup, the server gets the client’s login credentials and verifies them against a valid method.

If public key authentication is enabled, the server only gets the user’s public key. The user keeps the private key secret. The server’s role here is to only validate that the client has the private key corresponding to the user’s public key.

Upon successful validation, the user gets the level of access the account has per the SSH daemon configuration. Because the access is restricted based on the account, the real layer of security of SSH is in defining which accounts can be authenticated and what those accounts can do.

What is SSH Port 22?

By default, SSH servers listen on port 22. From a security perspective, it is a good practice to move SSH to a different port. While moving SSH to a different port may potentially reduce the number of automated connection attempts, it’s not enough to secure the service.

One can secure the SSH service by implementing a number of different controls. For example, if administrators are allowed to access the service only from the office network or VPN, controls can be put in place to deny all SSH traffic and only allow it from the office network/VPN.

What is SSH Tunneling?

Administrators can access private services by routing network traffic through an encrypted SSH tunnel. SSH supports port forwarding. Port forwarding provides secure access to private services and resources.

Unauthorized users of the SSH service can also create remote tunnels. Tunnels can bypass network policy. Forwarding should be disabled to avoid an unauthorized user creating a network bypass.

Where is SSH Configured?

On most Linux systems running OpenSSH, the server configuration is found at:

/etc/ssh/sshd_config

This file contains configuration options for the SSH server. You can change options such as the port number, what authentication methods are permitted, restrictions on the root account, permitted users, and other options.

It is easy to lock yourself out of a system by incorrectly modifying these settings. Always test the new configuration and be certain you can still connect via SSH before you stop or restart the SSH daemon.

How to Secure SSH Access

There are three principles of securing a Linux server via SSH. These are limiting access, authenticating users, and removing unnecessary access. This article lists the more common SSH configuration options.

1. Use SSH Keys Instead of Passwords

With public key authentication, SSH does not depend on reusable server passwords, and thus it is well-suited for both human and automated SSH login. Each private key should be safeguarded with a passphrase and provided to each administrator. NIST also suggests the same for the lifecycle management of SSH keys.

2. Disable Direct Root Login

The root account has the potential to create unlimited confusion. Exposing the root account via SSH increases the impact of compromised credentials. Use an administrative account for normal tasks and use sudo to get elevated privileges when needed.

PermitRootLogin no

3. Disable Password Authentication

After key-based login has been successfully implemented, password authentication can be disabled by adding the following line to the configuration file:

PasswordAuthentication no

Check what other authentication methods are available on the server. In particular, keyboard-interactive authentication may allow a path to unintended password-based authentication to be left open.

4. Restrict Which Users Can Connect

OpenSSH allows you to configure access control lists for SSH. For instance, you can control the AllowUsers and AllowGroups directives to see who can log in to SSH.

This simplifies access control lists because you know the reason for each entry on the list.

5. Restrict SSH at the Firewall

SSH (Secure Shell) allows secure remote access to a computer from anywhere on the internet. SSH is designed to be secure, but using other mechanisms to secure SSH is best practice.

Limit SSH to management networks or VPNs. This provides better security than changing the default SSH port of 22. If the source of the connections is restricted, then it doesn’t matter what port SSH is on.

Learn more about what a software firewall is and how it helps restrict unauthorized network access.

6. Limit Repeated Authentication Attempts

Repeated unsuccessful logins are a common sign of an SSH attack. Among other configurable options, OpenSSH provides MaxAuthTries. In addition, there are tools, such as Fail2Ban, which also assist in blocking offending IP addresses.

These controls reduce the chances of a brute-force attack without changing the root issue of invalid authentication.

7. Disable Unused SSH Forwarding

Port forwarding allows administrators to access protected services. However, if SSH users can perform port forwarding, then they can access services that they are not authorized to use.

If forwarding has no legitimate purpose on the server, consider disabling it:

AllowTcpForwarding no

NIST mentions disabling port forwarding as part of the consideration of hardening SSH.

8. Set an Inactivity Timeout

Server sessions can remain open and usable by a remote user long after the administrator has ended the session. Some limits on session inactivity can be configured by the server.

Once these limits are configured, OpenSSH can be instructed to close a client session after the conditions are met by using the ClientAliveCountMax and ClientAliveInterval directives.

9. Keep OpenSSH Updated

SSH hardening is more than just tweaking configuration files. The operating system and SSH server should be up-to-date with the latest software versions and security patches.

An old or outdated SSH implementation may contain known vulnerabilities, despite the presence of restrictions in the configuration file. NIST suggests that SSH client and server implementations be updated to the latest version.

10. Review SSH Logs and Keys

Configuration controls what can be done. Logs show what is actually happening. Monitor authentication logs for invalid access attempts, unexpected successful access, and source addresses that are unfamiliar. Additionally, monitor for access by accounts that should not be active. Finally, remove old SSH keys if the associated account is no longer used.

SSH keys are often provisioned and then forgotten. In truth, SSH key provisioning should be considered key pairing, and access management should be continued. Access should be removed when no longer needed.

Conclusion

Securing SSH is not just about changing one setting. Security should be designed into the overall architecture. Every pathway into the server should be deliberately designed. SSH provides a secure route into a server for a user to gain access to a service.

Design secure routes into a server. Implement features and functionalities to restrict access. Disable or remove features that are not needed. Monitor access and adjust settings based on changes to user and device access.

From an attacker’s perspective, securing SSH is difficult. Securing SSH is not a challenge for an experienced system administrator.

FAQs

Does changing the SSH port 22 help secure SSH?

Changing the SSH port does very little to improve the security of the service. It may obfuscate some scans and attacks. The security of the service can be improved by other means. These other means include but are not limited to access control lists, firewall and IPS rules, as well as managing user accounts and SSH host keys.

Should SSH password authentication be disabled?

Yes. Key-based authentication allows for SSH key authentication but removes password authentication. With password authentication removed, an attacker can simply bypass SSH’s login mechanism and repeatedly attempt to guess the SSH key. It is recommended that you test your SSH key from a different session to ensure that you can still access the server with your SSH key.

Should root SSH login be disabled?

Yes, it is recommended to disable root login. Superuser permissions can be used by a separate account with the sudo command. Thus, it is not necessary to use the root account.

Is SSH tunneling secure?

Understanding SSH tunneling poses little threat to the average user; however, SSH can generate pathways that could pose a threat. Let’s say SSH tunneling is not required. In these situations, you should restrict or disable the feature.

Can a firewall protect SSH?

Firewalls often limit SSH access to trusted networks or VPNs. This limits what networks are able to connect via SSH. Firewalls shouldn’t be used to fully protect an SSH connection. The primary means of protecting an SSH connection should be the authentication of users.