Strictly following security best practices is the first step to cybersecurity. Although SSH is the industry standard for both security and efficacy for remote server access, as with any software, SSH is only as secure as configurations applied to the server and client configurations.
In this article, we’ll explore five SSH best practices you should observe to boost the security of your infrastructure.
In second factor authentication, sometimes called two-factor authentication, a system requires two different forms of authentication to gain access. One of the most common second factor authentication examples is a combination of a passphrase the user knows and a one-time password sent to their mobile device. While one-time passwords sent to a mobile device are subject to Man-in-the-Middle(MITM) attacks, using any second factor is better than no second factor. More secure second factors include YubiKey and Apple TouchID.
By enabling the second factor authentication feature, system administrators ensure that any user logging into a remote system via SSH must authenticate with more than a single credential that can be easily stolen, making this authentication method more secure than a password or SSH key alone.
As organizations often use SSH to create a secure connection to remote systems, implementing another layer of security is a critical practice to ensure complete security coverage.
SSH default options are controlled via the config file located in /etc/ssh/sshd_config. The default options are common knowledge in most computing environments, so it’s a good practice to change some settings to protect your systems.
By default, SSH servers run on port number 22. However, probing through default ports is usually the first step attackers take when seeking open SSH server ports. The main advantage of switching to a non-standard port is limiting brute force attacks and port scanner access to your server.
Secondly, users can SSH to the server as root user by default. An SSH root access or superuser access is an incredibly hazardous feature because it allows full access to and control over the entire system. By disabling SSH root logins on the servers, you can control what each user can access. Instead, you can create individual logins which are much easier to track and audit. To disable root user login, update SSH config file (/etc/ssh/sshd_config) and set option “PermitRootLogin” to “no” as below:
To address the requirement of a root privilege, configure sudo users so that root tasks can be accomplished by system administrators even when root login is disabled.
You may also want to change the default password-based authentication. Although this type of authentication might be convenient for users, stolen passwords are the most common cause of security breaches. You should completely remove password-based auth and opt instead for at least SSH keys. The best and recommended solution to replace passwords is with short-lived certificates. To disable password-based authentication, update SSH config file (/etc/ssh/sshd_config) and set option “PasswordAuthentication” to “no” as below:
AllowUsers” to restrict accessAdditionally, by default, all system users can login via SSH using their passwords or public keys. Not all the system users require remote login via SSH. Limiting SSH access for specific users greatly enhances security.
Although SSH key-based authentication is a better alternative to passwords, strengthening your remote login process’s security, it has its own security risks including the complexity of SSH key management. SSH keys are really just a password by another name since they are text that can be copied and passed “as is” from a client to a service on the wire for authentication.
SSH certificate-based authentication is an even better alternative. SSH certs secure the login process by using public keys while also providing a certificate to verify each key’s identity. OpenSSH has a built-in way to generate certificates using ssh-keygen.
A bastion host is a computer specifically designed to withhold malicious traffic and attacks from a network. The bastion is exposed on a public network and hosts a single application. Other services are limited to reduce the threat to the computer.
The bastion hosts are highly exposed to the public, and their existence is well-known on the Internet. A bastion host is often the first point in the network, right before the firewall. It protects the systems behind it.
Setting up a bastion host may help boost security and safeguard your system when two channels establish an SSH connection.
A firewall’s primary job is to inspect incoming and outgoing traffic using predefined rules. Depending on the computing needs, the firewall can also inspect traffic within a private network, significantly improving the server’s security.
Linux system administrators may use iptables, the user interface to the netfilter firewall. This packet-filtering system accepts or rejects packets (or takes other action) to protect systems from attack.
Using iptables, you can define rules that accept incoming SSH traffic from safelisted sources by IP address, port, or protocol. You can also track recent SSH port connections. You can block IP addresses based on the rate they connect to the SSH by using rate-limit connections too.
Using a firewall, and adjusting its configurations, can help reduce the chance of SSH attacks. You may also implement port knocking so that it becomes much harder to detect open SSH ports.
The best practices presented above are not the definite list, and there indeed are other best practices that depend on organizational and compliance requirements. However, it is also important to note that it is often challenging to follow best practices and implement all of them correctly. For example, it would take at least two different solutions to implement two-factor authentication and certificate-based authentication for SSH. And you’ll probably need to maintain a dedicated server for bastion hosts. Implementing and maintaining these products might create complexity for small teams.
At Remoteler, we understand that complexity is the evil twin of security. As such, Remoteler Server Access includes two-factor authentication, certificate-based authentication, and a modern bastion service that allows single sign-on and role-based access control for SSH, all bundled into a single product. Remoteler is open source and automates CA management for certificate-based authentication. Along with the SSH protocol, Remoteler also supports RDP, database wire protocol and HTTP. Try Remoteler today!