--- title: "Protect a Linux server from SSH brute force | StreetHosting" description: "Layered SSH brute force defense: keys only, passwords off, root blocked, AllowUsers in sshd_config.d, a second-session test, Fail2Ban and a VPN." url: "https://streethosting.com.br/en/guides/infrastructure/protect-ssh-from-brute-force" type: "page" language: "en-US" --- Infrastructure · 8 min · Intermediate Published on Jun 11, 2026 · Updated on Sep 28, 2026 # How to protect SSH from brute force attacks on a Linux server Minutes after an IP goes live, bots start trying root and leaked passwords on SSH. This guide builds the defense in layers, from sshd\_config to a VPN, without locking your team out of the server. By [Equipe StreetHosting](https://streethosting.com.br/en/autores#equipe-streethosting) · StreetHosting infrastructure and support team [Security and hardening](https://streethosting.com.br/en/guides/topics/security) [Linux administration](https://streethosting.com.br/en/guides/topics/linux) [Network, DNS and domains](https://streethosting.com.br/en/guides/topics/networking) Summarize with: [](https://chat.openai.com/?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fprotect-ssh-from-brute-force.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "ChatGPT") [](https://claude.ai/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fprotect-ssh-from-brute-force.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Claude") [](https://www.google.com/search?udm=50&aep=11&q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fprotect-ssh-from-brute-force.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Google AI Mode") [](https://x.com/i/grok?text=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fprotect-ssh-from-brute-force.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Grok") [](https://www.perplexity.ai/search/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fprotect-ssh-from-brute-force.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Perplexity") Share: [](https://x.com/intent/tweet?text=Protect%20SSH%20from%20brute%20force%3A%20a%20layered%20strategy&url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fprotect-ssh-from-brute-force "Share on X") [](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fprotect-ssh-from-brute-force "Share on Facebook") [](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fprotect-ssh-from-brute-force "Share on LinkedIn") [](https://wa.me/?text=Protect%20SSH%20from%20brute%20force%3A%20a%20layered%20strategy%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fprotect-ssh-from-brute-force "Share on WhatsApp") For agents: Copy as Markdown [.md](https://streethosting.com.br/en/guides/infrastructure/protect-ssh-from-brute-force.md) In this guide 7 sections * [What SSH brute force is](https://streethosting.com.br/en/guides/infrastructure/protect-ssh-from-brute-force#o-que-e-brute-force-ssh) * [Signs of an attack in the logs](https://streethosting.com.br/en/guides/infrastructure/protect-ssh-from-brute-force#sinais-ataque-logs) * [Choose an exposure model](https://streethosting.com.br/en/guides/infrastructure/protect-ssh-from-brute-force#estrategia) * [Harden sshd with your own file](https://streethosting.com.br/en/guides/infrastructure/protect-ssh-from-brute-force#camadas-defesa-praticas) * [Test in a second session](https://streethosting.com.br/en/guides/infrastructure/protect-ssh-from-brute-force#segunda-sessao) * [Fail2Ban, firewall and VPN](https://streethosting.com.br/en/guides/infrastructure/protect-ssh-from-brute-force#fail2ban-ufw-hardening) * [Ongoing operation on a VPS and a dedicated server](https://streethosting.com.br/en/guides/infrastructure/protect-ssh-from-brute-force#operacao-vps-dedicado) Quick answer To **protect SSH from brute force**, log in with a **key** only, turn off passwords and root login in a file of your own in `/etc/ssh/sshd_config.d/`, limit the allowed users with AllowUsers and test in a second session before closing the first. Then reduce the exposure: Fail2Ban for the noise and, if possible, accept SSH only from known IPs or through the VPN. ## What SSH brute force is[](https://streethosting.com.br/en/guides/infrastructure/protect-ssh-from-brute-force#o-que-e-brute-force-ssh) SSH brute force is the automated attempt to guess a username and password until one weak or reused combination works. You do not have to be a famous target: any IP with port 22 open lands on scanning lists within a few minutes. There are three common variations. * **Dictionary:** common names like root, admin, ubuntu and test, with obvious passwords. * **Leaked passwords:** real combinations from breaches at other services, tried because so many people reuse passwords. * **Distributed password spraying:** thousands of IPs, each trying one or two passwords so it never trips per-IP limits. This is the pattern that slips past Fail2Ban. A successful guess usually turns into a cryptocurrency miner, spam sending, attacks on third parties from your IP or data hijacking. The goal of the defense is not to bring the attempts to zero, because they never stop, but to make success impossible and shrink the exposed surface. ## Signs of an attack in the logs[](https://streethosting.com.br/en/guides/infrastructure/protect-ssh-from-brute-force#sinais-ataque-logs) On Ubuntu 24.04 the service is called ssh, and the events live in the journal and in `/var/log/auth.log`. Three queries give you the picture: `# password failures in the last hour sudo journalctl -u ssh --since "1 hour ago" | grep -c "Failed password" # IPs that tried the most nonexistent users today sudo journalctl -u ssh --since today | grep "Invalid user" | awk '{print $(NF-2)}' | sort | uniq -c | sort -rn | head # successful logins sudo journalctl -u ssh | grep "Accepted"` | Typical line | What it means | Action | | -------------------------------------------------------- | -------------------------------------- | --------------------------------------------------- | | Failed password for root | A bot trying the superuser by password | Confirm PermitRootLogin no and passwords turned off | | Invalid user oracle | Dictionary of service account names | Expected noise; watch the volume | | Connection closed by authenticating user ... \[preauth\] | Attempt ended before authenticating | Nothing, if login is key-only | | Accepted password for deploy | Successful password login | Investigate right away if passwords should be off | | Accepted publickey from an unknown IP | Valid key used from a strange origin | Review authorized\_keys and replace the key | Many different IPs in the same minute point to a botnet. Late-night spikes are normal, because scanners do not respect time zones. The signal that really matters is an Accepted line you do not recognize. ## Choose an exposure model[](https://streethosting.com.br/en/guides/infrastructure/protect-ssh-from-brute-force#estrategia) With passwords turned off, guessing your way in is no longer practical: the bot would need your private key. The risk that remains is a stolen key or a flaw in the SSH server itself. In 2024, the flaw known as regreSSHion allowed remote code execution before authentication on several OpenSSH versions. Servers with SSH closed to the internet were out of its reach. That is why the strategic question is who can reach the port. | Model | How it looks | When to use it | | ---------------- | ------------------------------------------------------ | ---------------------------------------------------------------- | | Open, keys only | Public port, passwords off, Fail2Ban against the noise | Team without a fixed IP; the acceptable minimum | | Restricted by IP | Firewall accepts SSH only from known addresses | Office with a fixed IP or a jump server | | VPN only | Port closed to the internet, access through WireGuard | Production with sensitive data; you have to keep the VPN running | | Alternate port | Same exposure, fewer log lines | A complement, never the main defense | Whichever model you pick, the next two sections are mandatory: harden sshd and test without locking yourself out. ## Harden sshd with your own file[](https://streethosting.com.br/en/guides/infrastructure/protect-ssh-from-brute-force#camadas-defesa-praticas) First, the key must be installed and working for a user with sudo. The step-by-step is in [passwordless SSH key login](https://streethosting.com.br/en/guides/vps/passwordless-ssh-login-vps) and, if you use Windows, in [SSH keys on Windows](https://streethosting.com.br/en/guides/vps/set-up-ssh-key-windows). Instead of editing the main sshd\_config, create a file of your own: `# /etc/ssh/sshd_config.d/00-hardening.conf PasswordAuthentication no KbdInteractiveAuthentication no PermitRootLogin no AllowUsers deploy MaxAuthTries 3 LoginGraceTime 30` The name starting with 00 is not decoration. Ubuntu's sshd\_config includes the files in that folder right at the top, in alphabetical order, and for each option the first value read wins. Cloud images often ship a `50-cloud-init.conf` with PasswordAuthentication yes; a file of yours with a higher number would lose to it. Check what exists and validate: `grep -ri passwordauthentication /etc/ssh/sshd_config /etc/ssh/sshd_config.d/ sudo sshd -t sudo sshd -T | grep -Ei 'passwordauthentication|kbdinteractive|permitrootlogin|allowusers|maxauthtries' sudo systemctl reload ssh` * **sshd -t** prints nothing when the configuration is correct. **sshd -T** shows the effective values, after all the includes, and it is the proof that passwords are really turned off. * **AllowUsers** also accepts a source: `AllowUsers deploy@203.0.113.10` lets deploy in only from that IP. * **MaxAuthTries 3** can block you if your SSH agent offers too many keys before the right one. The message is Too many authentication failures; fix it with IdentitiesOnly yes and the right key in the client configuration file. ## Test in a second session before closing the first[](https://streethosting.com.br/en/guides/infrastructure/protect-ssh-from-brute-force#segunda-sessao) The reload does not drop the session you are in, and that session is what saves the day if something goes wrong. Keep that window open and run the tests from another terminal: 1. Normal login with the key: `ssh deploy@IP_DA_VPS`. It has to work. 2. Login forcing a password: `ssh -o PubkeyAuthentication=no deploy@IP_DA_VPS`. It has to be refused with Permission denied (publickey), without even asking for the password. 3. Login as root: `ssh root@IP_DA_VPS`. It has to be refused. 4. Only when all three results are right, close the first session. If a test fails, fix it from the session you left open: delete or adjust the file, run sudo sshd -t and reload. If both sessions drop, your way back in is the VPS console in the client area, which requires the user's local password. Set that password with sudo passwd before you start. ## Fail2Ban, firewall and VPN[](https://streethosting.com.br/en/guides/infrastructure/protect-ssh-from-brute-force#fail2ban-ufw-hardening) With sshd hardened, the next layers cut noise and exposure. **Fail2Ban.** On Ubuntu 24.04, the SSH jail is already enabled when you install the package and it reads the journal. With passwords off, it does not stop any intrusion that the key does not already stop, but it cleans up the log, saves CPU and takes the most persistent IPs out of circulation. Against distributed password spraying, each IP fails only a little and stays under the limit. The full configuration, with progressive bans and recidive, is in [setting up Fail2Ban on a VPS](https://streethosting.com.br/en/guides/vps/fail2ban-ssh-vps-setup). Newer OpenSSH versions, from 9.8 on, ship native per-source penalties, but Ubuntu 24.04 uses 9.6, so Fail2Ban is still the tool. **Restriction by IP or VPN.** This is the layer that shrinks the surface the most: `# SSH only from a fixed IP sudo ufw allow from 203.0.113.10 to any port 22 proto tcp # SSH only through the WireGuard VPN interface sudo ufw allow in on wg0 to any port 22 proto tcp # after testing through the new rules, close the open rule sudo ufw status numbered sudo ufw delete NUMERO_DA_REGRA_ABERTA` The syntax and the precautions to avoid losing access are in the guide to [the UFW firewall on a VPS](https://streethosting.com.br/en/guides/vps/ufw-firewall-ubuntu-vps), and the VPN setup is in [WireGuard VPN on a VPS](https://streethosting.com.br/en/guides/vps/wireguard-vpn-vps). With a dynamic home IP, prefer the VPN: the IP list breaks the next time your address changes. **Changing the port.** It cuts log lines, because simple bots only try 22, but full scans find any port. On Ubuntu 24.04 SSH is socket-activated, so changing the port requires reloading systemd and restarting ssh.socket, always with the new port opened in the firewall first. * Key-only login, with PasswordAuthentication and KbdInteractiveAuthentication set to no * PermitRootLogin no; if root is unavoidable, key only * AllowUsers with the smallest possible list of human accounts * Configuration checked with sshd -T after every change * Fail2Ban active on the real SSH port * Firewall with SSH restricted by IP or VPN whenever possible ## Ongoing operation on a VPS and a dedicated server[](https://streethosting.com.br/en/guides/infrastructure/protect-ssh-from-brute-force#operacao-vps-dedicado) SSH security is not a one-day task. A short routine keeps the configuration from degrading: 1. Every quarter, review each user's authorized\_keys and remove keys from people who left the team or from retired machines. 2. After major system upgrades, run sshd -T again and confirm that passwords are still turned off. 3. Set up an alert for unusual Accepted lines and for spikes in failures per hour. 4. Once every six months, test the login through the panel console. 5. After any incident, replace all keys and review the history of accepted logins. Keep a copy of `00-hardening.conf`, of jail.local and of the list of authorized keys outside the server. Rebuilding access on a new machine takes minutes when the configuration is ready. The general hardening walkthrough is in the guide to [secure SSH on a Linux VPS](https://streethosting.com.br/en/guides/vps/secure-ssh-linux-vps). The Anti-DDoS included in the network of [StreetHosting VPS](https://streethosting.com.br/en/vps) stops volumetric attacks, but not brute force, which is low traffic and looks legitimate. That layer is yours, and root access and KVM virtualization let you apply everything in this guide, with the panel console as a safety net. The VPS plans are in São Paulo and start at R$ 26.00 on the Xeon line and R$ 40.00 on the Ryzen 9 9950X. For larger operations, the [dedicated servers](https://streethosting.com.br/en/dedicated) have exclusive hardware, 10 Gbps and Anti-DDoS, starting at R$ 1,499.00, delivered within 6 days. Exclusive hardware does not replace a hardened SSH setup. In this guide * [What SSH brute force is](https://streethosting.com.br/en/guides/infrastructure/protect-ssh-from-brute-force#o-que-e-brute-force-ssh) * [Signs of an attack in the logs](https://streethosting.com.br/en/guides/infrastructure/protect-ssh-from-brute-force#sinais-ataque-logs) * [Choose an exposure model](https://streethosting.com.br/en/guides/infrastructure/protect-ssh-from-brute-force#estrategia) * [Harden sshd with your own file](https://streethosting.com.br/en/guides/infrastructure/protect-ssh-from-brute-force#camadas-defesa-praticas) * [Test in a second session](https://streethosting.com.br/en/guides/infrastructure/protect-ssh-from-brute-force#segunda-sessao) * [Fail2Ban, firewall and VPN](https://streethosting.com.br/en/guides/infrastructure/protect-ssh-from-brute-force#fail2ban-ufw-hardening) * [Ongoing operation on a VPS and a dedicated server](https://streethosting.com.br/en/guides/infrastructure/protect-ssh-from-brute-force#operacao-vps-dedicado) ## Frequently asked questions Is changing the SSH port enough? No. It cuts the volume of generic bots and keeps your logs cleaner, but any full port scan finds the new port. Real protection comes from key-only login, remote passwords turned off, and reduced exposure by IP or VPN. Can Fail2Ban lock me out? Yes, if someone on your team fails several times or if many people share the same IP, as in offices and CGNAT networks. Add stable IPs to ignoreip and document how to unban from the VPS console. Can I keep password login on SSH for emergencies? You do not need to. The emergency exit is the VPS console in the client area, which works through the hypervisor and accepts the user's local password even with SSH passwords turned off. That way the emergency path is not open to the whole internet. How long until the attempts start? On a new VPS with a public IP, automated attempts usually show up within minutes. That is why hardening SSH should be the first step after creating the server, before you install a game, a bot or an application. Does the hosting Anti-DDoS protect against brute force? No. Anti-DDoS filters abnormal traffic volume, and a brute force attack is low traffic made of connections that look legitimate. What stops it is your SSH configuration, Fail2Ban and access restrictions, which are your responsibility on the VPS. Next step See VPS plans Root VPS in Brazil with NVMe and Anti-DDoS. [See VPS plans](https://streethosting.com.br/en/vps) [See Ryzen VPS Ryzen 9 9950X VPS in São Paulo with root access, NVMe and gamer Anti-DDoS.](https://streethosting.com.br/en/vps/ryzen) [See dedicated servers Exclusive hardware in São Paulo with NVMe and Anti-DDoS.](https://streethosting.com.br/en/dedicated) ## Related guides [VPS Intermediate How to secure SSH on a Linux VPS: keys, passwords, fail2ban SSH is usually the first target on any VPS with a public IP. This guide walks through a practical routine that cuts the risk without complicating your day: an ED25519 key, password-free login, admin access through sudo, blocking of automated attempts and a periodic review of authorized keys. 4 min Read guide](https://streethosting.com.br/en/guides/vps/secure-ssh-linux-vps) [VPS Intermediate How to set up Fail2Ban on a VPS: SSH, Nginx and repeat offenders Fail2Ban reads your logs, spots the IPs that fail too often and bans them in the firewall. Learn how to set it up on Ubuntu 24.04, where the package defaults change how jails behave, and how to manage bans day to day. 8 min Read guide](https://streethosting.com.br/en/guides/vps/fail2ban-ssh-vps-setup) [VPS Beginner UFW on Ubuntu VPS: firewall rules without losing SSH UFW makes the Ubuntu firewall simpler, but one rule in the wrong order locks you out of your VPS. Learn how to enable it without losing SSH, open only what you need, deal with Docker, and get back in through the console if something goes wrong. 10 min Read guide](https://streethosting.com.br/en/guides/vps/ufw-firewall-ubuntu-vps) [← Back to the Guide Center](https://streethosting.com.br/en/guides)