The cybersecurity landscape is constantly changing and evolving, and that is perhaps best represented by SSH – even as recently as a few years ago, we all thought SSH keys were the best way to implement SSH, when now we know that SSH keys are bad! With that said, just because SSH is considered a standard in the industry for both security and effectiveness in accessing remote servers does not mean it is infallible. Like all software, its success relies heavily on the configurations set up on both the client and server sides. In this blog, we will run through the best practices you can follow to secure SSH.
You have spent a lot of time and effort securing your Entra ID identity with unphishable credentials, conditional access, and manage RBAC through AD groups. Instead of reinventing the wheel, we should transfer that same security to SSH. You might be thinking about domain joining your Linux machine to AD; however, this will just add more problems. Instead, we recommend using a tool like EZSSH to use your AAD credentials to create a short term SSH certificate and grant you access to your SSH endpoint.
SSH keys are not considered MFA, much to the chagrin of security practitioners everywhere. Why is this? SSH keys are not MFA because most people don’t protect them with a password; as such, any competent hacker can steal them. Yep, it’s as simple as that! This is why we highly recommend switching from SSH keys to SSH certificates (we dive deeper into this subject in a couple of paragraphs).
The default settings for SSH are controlled by the configuration file found at /etc/ssh/sshd_config. Since these default options are widely known in many computing environments, it is smart to alter some of them as a precautionary measure to safeguard your systems. The two things that we recommend doing are changing your default port and removing password-based authentication.
SSH servers are set to operate on port 22 by default; unfortunately, attackers often start their search for open SSH server ports by scanning these default ports. Changing to a non-standard port can significantly reduce the likelihood of brute force attacks and restrict the accessibility of your server to port scanners.
While passwords may seem convenient and are the way we’ve done authentication for decades, password theft is a leading cause of security breaches. Passwords simply are not secure enough anymore. A more secure alternative is to eliminate password-based authentication entirely and use SSH certificates!
In order to disable password-based authentication, update the SSH configuration file (once again, /etc/ssh/sshd_config) and change the “PasswordAuthentication” option to “no”.
We actually wrote a whole blog on why you should use SSH certificates that you can check out for a true deep dive into the topic, but here’s the gist of why you should use them over SSH keys:
1) With SSH certificates, only one key per server needs to be added, simplifying server access management.
2) The user’s SSH keys are assigned expiration dates, ensuring that they don’t remain active indefinitely (which is a crucial security measure).
3) The CA can provide JEA (Just Enough Access) for each access request, enhancing controlled and secure access.
4) The ease of associating each key with its respective owner significantly improves the traceability and accountability of access.
5) The use of short-term certificates greatly reduces the risk associated with SSH key theft, a common problem stemming from SSH key mismanagement.
6) The streamlined process of SSH certificates significantly accelerates user onboarding, making it a more efficient and secure system for managing server access.
Firewalls are more than just a popular buzzword in movies about hackers – they’re actually key players in ensuring the security of SSH. Did you know that if you expose your SSH port to the internet you will have over 2 million connection attempts a year? The main function of a firewall is to inspect both inbound and outbound network traffic through specific, predetermined rules. Tailored to specific computing requirements, firewalls can also monitor traffic within a private network, enhancing server security significantly (say that last bit five times fast!). Moreover, firewalls can be used to limit the rate of connections from specific IP addresses to the SSH port, thereby blocking potentially harmful access.
All in all, effectively managing a firewall and its settings can substantially reduce the risk of SSH-related cyberattacks.
