Stop SSH brute-force attacks on your Linux servers

Yes. The agent only reads the auth log of its own operating system and blocks inbound connections to the protected ports on that same machine. It makes outbound HTTPS requests only and opens no inbound ports.

Yes. The decision to block an attacker is made locally on the agent, so protection keeps working with the last applied policy even when the cloud is unreachable.

The agent detects the actual SSH port automatically from sshd_config and listening sockets, and rebuilds its rules when the port changes. The FTP port is detected the same way.

No. During installation your current IP address is added to the whitelist, and whitelisted sources always take priority over any block.

Any modern systemd-based distribution - Debian, Ubuntu, RHEL/CentOS/Alma/Rocky, Fedora - on x86-64 and ARM64. One static binary with no additional runtimes to install.

International payments go through PayPro Global, payments in Russia through YooKassa, with cryptocurrency available as a fallback. The Free plan is permanent and requires no card.

With SSH Protector I install the agent as a systemd service: it reads the authentication log locally, determines the actual sshd port, and after a threshold of a window of time, blocks the source network in the system firewall. I add my address or VPN to the whitelist in advance, control the history in the panel and save the latest policy when I lose the Internet.

As a free alternative to SSH Protector, I disable PasswordAuthentication and PermitRootLogin, leave the keys to Ed25519, limit AllowUsers/AllowGroups and only allow the port from VPN or trusted CIDRs. If a password is temporarily required, I configure fail2ban using journald/auth.log, check nftables/iptables, set findtime, maxretry and bantime, and regularly test exceptions from the backup console.

With SSH Protector I block the source on actual failed logins no matter what name it tries, and can extend the ban to the attacker's network. I check the SSH port found, add the administrative VPN to the whitelist, and use a local agent solution so that protection does not depend on panel availability.

For free, I disable password and root logins, create a separate user with sudo, upload a unique key via cloud-init, and close the Security Group to the VPN/my networks. I remove unused authorized_keys, enable MFA on bastion, configure fail2ban and Accepted password/publickey alerts for unknown sources; I consider changing the port only to reduce noise.

With SSH Protector I install a static agent that reads local events and blocks the source in the firewall until the account is compromised. I use free first server protection, whitelist my channel, and make sure the agent continues to work offline; I leave backup and least privilege as separate layers.

For free, I lock SSH behind WireGuard/Tailscale, disable passwords and root, require a key with passphrase, and limit to sudo. I store backups outside of the VPS with separate credentials, enable automatic security updates, fail2ban and audit of successful logins; I check the provider's emergency console before tightening the firewall.

With SSH Protector I use a supported static binary for the appropriate architecture and systemd, enable local log parsing and firewall blocking without an incoming control port. I check OS and firewall compatibility before installation, set up a management whitelist, and make sure the agent doesn't overwhelm limited device resources.

For free, I don’t publish SSH externally at all: I connect the device via VPN, disable password and root, allow one key and one control subnet. I update the firmware, disable unused services, set the minimum fail2ban only if there is enough memory and save the firewall configuration; For an unsupported OS, I choose an external gateway rather than an unknown binary.

With SSH Protector, I enable reading of supported SSH and FTP logs, let the agent determine the ports, and apply a single local rule to the source network. I add trusted integrations to the whitelist, check the history in the dashboard, and take into account that advanced FTP protection and additional features may depend on the selected plan.

For free, I replace regular FTP with SFTP over SSH or FTPS, if the protocol is really needed, and close the service from the entire Internet. I create separate fail2ban jails for sshd and FTP, direct them to one nftables set with timeout, check the log format after updates and disable shared accounts.

With SSH Protector, I leave automatic network blocking on all external sources and whitelist only the controlled VPN, and not every home IP. I use the panel for attacks, but I save the identity in separate Unix accounts and keys: the agent protects the perimeter, and I revoke access by deleting a specific key.

For free, I manage authorized_keys centrally through Ansible, issue one key per person and device with a clear comment, disable shared accounts and limit sudo. I enable VPN/MFA on the bastion, set the access period in inventory, collect Accepted publickey with fingerprint in SIEM and automatically delete the key at the end of the contract.

With SSH Protector, I separate trusted runner addresses through a precise whitelist, and leave all other sources blocked by failed logins. I don't consider this to be a replacement for key control: the agent reduces the brute force from the outside while the restrictions of the service account itself contain the consequences of successful authentication.

For free, I use a separate Ed25519 key for the job, store it in a secret store, restrict it in authorized_keys via from=, command=, no-port-forwarding, no-agent-forwarding and no-pty. I only allow SSH from the runner network, issue minimal sudo commands, rotate the key regularly, and record a fingerprint in the deployment log.

With SSH Protector, I first install an additional protective layer and whitelist the current administrative address while I perform the migration. The agent blocks active brute force, automatically takes into account the actual port and leaves the policy offline, but after successfully verifying the keys, I still disable the password login.

For free, I open a second SSH session and the provider console, add a unique key, check ~/.ssh 700 and authorized_keys 600 permissions, run sshd -t and reload without closing the first session. Then I set PasswordAuthentication no, KbdInteractiveAuthentication no and PermitRootLogin no, check the new login and save the emergency key separately.

With SSH Protector I immediately block active sources and networks, check the history of attacks and leave access only through a trusted whitelist. Then I change the password/key, end the sessions and separately analyze the Accepted password/publickey; blocking reduces the attack window, but does not prove the absence of an already successful login.

For free, I temporarily close the SSH Security Group or nftables to the VPN, block the user, revoke the keys and change the associated secrets. I check last/lastlog, journalctl, sudo, new users/keys, cron/systemd units, processes and network connections, then restore key-only access and disable reused passwords.

With SSH Protector I continue to block external brute force and see suspicious sources, but do not rely on it against the correct stolen key. I immediately remove the fingerprint from all servers, issue a new key with passphrase and leave the whitelist only for VPN; I will investigate successful entries separately.

For free, I look up the old public key across all authorized_keys, revoke it by configuration management, and check the Accepted publickey by fingerprint and source. I issue a hardware FIDO2/ed25519-sk or key with passphrase and ssh-agent timeout, disable agent forwarding unless necessary, and keep a registry of owner, device, and rotation dates.

With SSH Protector I am attaching a history of attacks and blocking, policy settings, a list of protected services and approved exceptions. I document the agent's local solution, the outgoing TLS channel, and the lack of an incoming control port, then perform controlled bad logins and save the log lines, firewall rule, and notification.

For free, I export sshd_config, nftables/ufw, fail2ban jail and changelog from Git, and send auth.log/journald to a secure storage. I check PasswordAuthentication, PermitRootLogin, MFA/VPN and test key revocation monthly, sign the result and store evidence for the required period.

With SSH Protector I block the source in the firewall after a series of failures, so the next TCP connections don't reach sshd and don't create as many entries. I keep a system audit, separately control the size/retention of the journald, and use the attack history in the panel as an index, not as a replacement for the original log.

For free, I close SSH to VPN/allowlist, disable passwords and standard logins, and send fail2ban to nftables set with timeout. I configure SystemMaxUse and journald/rsyslog rotation, send Accepted and key Failed events to an external syslog, and do not reduce LogLevel below the value needed for investigation.

With SSH Protector I set the threshold and window once, after which the agent creates and releases locks locally and the whitelist takes precedence. I use a network ban where the attacker rotates neighboring addresses, check the changes in the panel and save a backup console before the first policy.

For free, I replace individual permanent iptables rules with nftables set with timeout or fail2ban action, set maxretry/findtime/bantime and ignoreip for VPN. I test the filter on real log lines, enable recidive carefully, limit the set size, and monitor for reload errors after a distribution update.

With SSH Protector I connect hosts with a supported agent, see detected ports and attacks from one panel, but keep exceptions and policies within the boundaries of the desired server/client. I apply baseline values, document deviations separately, and notify the customer responsible.

For free, I describe sshd, fail2ban and nftables in Ansible roles with a separate inventory and vault for each client, check for changes in CI and collect logs in Wazuh/central syslog with tenant tags. I automatically compare the config with the baseline and never combine keys, CIDRs and secrets from different customers.

With SSH Protector I enforce the policy on the agent in advance; it continues to read the local log and change the system firewall to the latest configuration when communication with the panel is lost. I sync the whitelist before the shutdown, check the accumulated history after the restore, and don't open the incoming agent control port.

For free, I make the control completely local: nftables/ufw allows SSH only from a VPN or the required subnets, and fail2ban works via journald without an external network. I save the rules for loading, set up a local queue for notifications, test a restart without DNS, and leave the physical/provider console to restore the erroneous rule.

I install the SSH Protector agent while fail2ban keeps running. The agent owns a dedicated nftables table of its own (inet sshprotector, or a prefixed ipset namespace on older hosts) and rebuilds only that table, so it never touches fail2ban's chains and neither tool reverts the other. I whitelist my own address at install time, then watch the panel for a day to see that the agent is catching the same sources the jail is. Only then do I stop fail2ban and remove its rules. If I change my mind, uninstalling the agent takes its own rules with it and leaves the firewall as it was.

Without any agent, a switch between two log-reading tools is done the same way. Leave the old one running, give the new one its own chain or table name so their rules cannot collide, compare what each one caught over a full day of real traffic, and disable the old one only once the new one's ban count has stopped being the lower of the two. Never remove the working tool first: a few unprotected minutes on an exposed SSH port is enough for a botnet that is already scanning you.

The two solve overlapping problems from different ends, and I pick on shape rather than on a score. CrowdSec is an engine with a scenario language, remediation components you install and wire up yourself, and a blocklist fed by everyone running it; its reach goes well past SSH. SSH Protector is one binary that does one thing: it reads the SSH, SFTP and FTP authentication log, bans the attacker's whole /24 in its own nftables table, keeps that ban across reboots, detects the real sshd port instead of assuming 22, and reports to a panel that tells me when a protected server has gone quiet. Reputation is shared between protected accounts rather than with the public internet.

So the decision is about what I actually have. If I need breadth - HTTP, databases, arbitrary log sources, detection scenarios of my own - CrowdSec has the room for that and costs nothing to run. If what I have is a handful of Linux boxes with an exposed SSH port and nobody to maintain a detection stack, I want the narrow thing that is correct with no configuration. I have not benchmarked the two against each other on the same host, so I do not choose on performance numbers, and neither should anybody quoting them at me.