Tools: Latest: Top SSHD Hardening Tricks I Use to Keep My Server Safe from Brute Force Attacks
1. Change the Default Port
2. Disable Root Login
3. Enforce Key-Based Authentication (No Passwords)
4. Restrict Which Users Can SSH
5. Limit Authentication Attempts per Connection
6. Disable Features You Don't Use
7. Enforce Strong Ciphers and Key Exchange Algorithms
8. Use tools like fail2ban or crowdsec
9. Restrict SSH Access at the Firewall Level
Apply the Changes
Final Thoughts The moment you expose your server to the internet with a public IP, if you check the /var/log/auth.log file, you will be in a complete panic within a moment. Numerous bots and attackers will start brute-forcing your server to gain access. This is very alarming if your server is not protected with proper SSHD hardening, as attackers might compromise your system at any moment. Fortunately, there is an exact sshd_config hardening process you can apply to every new server to make brute-force attacks a non-issue. Here are nine straightforward steps to lock down your server. Warning: Always keep a backup SSH window open for your server. Never forget to test the configuration with the sshd -t command before applying changes to avoid getting locked out. The single biggest drop in noise. Automated scanners and attackers almost exclusively target port 22. So, if you move to a high, non-standard port that will eliminate almost ~99% of bot traffic overnight. Remember to update your firewall rules and use ssh -p <your_port> user@host going forward. Never allow direct root SSH access. That's like opening your server's main door to the attackers. If an attacker gets in, they can do almost anything on your servers. You may want them to at least need to escalate privileges separately. Always log in as a regular user and then use sudo. If you still really need direct root ssh login then you can use the config mentioned below to strictly enforce key based login for the root user Tip: Always confirm you have sudo access before disabling root login. Password auth is a significant attack surface. So, you should kill it entirely. SSH keys are the minimum bar. Then you can also pair with a strong passphrase on the key itself. You can apply the following settings to enforce strict key based access on your server and restrict password based logins. What it does?
PasswordAuthentication no completely disable password based authenticationPubkeyAuthentication yes only allowed key based authenticationAuthenticationMethods publickey enforce key based authentication method onlyChallengeResponseAuthentication no disables keyboard interactive authenticationUsePAM yes enables pluggable authentication module Whitelist the exact users (or groups) that need SSH access. It can significantly reduce the attack surface since only users you explicitly allow can now login. Everyone else is denied at the sshd level even if they have valid credentials. If you use the AllowGroups directive then you can add any user to the sshusers group Reduce how many tries an attacker gets before the connection is dropped. What it does?MaxAuthTries 3 will drop the connection after the failure attempt count reach to 3LoginGraceTime 20 will disconnect if not authenticated within 20 secondsMaxStartups will throttle unauthenticated connection attempts Every enabled feature is a potential attack vector. Disable anything you don't actively need. Strip out legacy ciphers. Attackers can downgrade your connection to weak crypto if you leave old algorithms enabled. Even with all the above, bots will keep trying. fail2ban watches your auth logs and auto-bans IPs after repeated failures. Pair it with the custom port from tip #1.
If you need to setup fail2ban then I have covered it in a separate article here: Guide to Secure Your Self-Hosted Stacks like Nginx, SSH, & Vaultwarden with Fail2ban About crowdsec I will cover it on a separate article. If you connect from a static IP or a VPN, whitelist that IP in your firewall. This is the hardest gate of all, the port never even responds to unauthorized sources. Always test your config before reloading because one syntax error locks you out: If the above command didn't show any error then run the following command to reload your sshd config None of these tricks is a silver bullet on its own, but defense in depth is the main goal. My standard stack for any new VPS: With all of this in place, brute-force attacks become background noise that you never have to think about again. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse