Repeated failed logins need investigation and layered access controls, not a promise to stop all attacks permanently. First identify the targeted service, failed and successful authentication events, source addresses and affected accounts. Distinguish internet scanning from successful unauthorized access before changing the server.
Preserve access and evidence
Save relevant log intervals and timezone. Check whether any unexpected login succeeded and whether accounts, keys or privileges changed. Suspected compromise requires incident response, not just banning the latest source IP. Keep a working administrative session and tested console recovery before changing SSH or firewall rules.
Reduce who can reach the login service
Where operationally appropriate, restrict administration to approved networks or a controlled access gateway. Test from an allowed and a disallowed source. Account for IPv4 and IPv6, monitoring and emergency access; a rule on only one path may leave another exposed.
A non-default SSH port may reduce some automated noise but does not make the service undiscoverable or replace authentication. Leaving a required service on its standard port is not itself evidence of a security failure.
Verify the authentication policy
Use the OpenSSH manuals for the installed release. Protect keys, use appropriate multifactor controls where supported, and review allowed users and administrative privileges. Before disabling a currently used login method, validate configuration and successfully open a new authorized session through the intended replacement.
Keys and MFA reduce particular credential risks; neither guarantees that a compromised endpoint, stolen session or misconfiguration is harmless. Revoke compromised credentials and investigate their use.
Make Fail2ban observable
Fail2ban's project documentation explains its service-specific filters, jails and ban actions. Installation alone does not prove protection. Confirm that the jail reads the correct logs or journal, matches real failed attempts and applies the expected action through the active firewall backend.
Test in an authorized controlled setting with recovery access. Confirm detection, enforcement and unbanning; check that legitimate shared-address users are not being locked out. Distributed or slow attempts may not cross a per-source threshold, and an incorrect source-address configuration can block the wrong client.
Measure the outcome
Compare attempted and successful unauthorized logins, false positives and administrative availability after the change. Keep alerts for unexpected successful access, not only high failure counts. Review controls when networks, authentication or server software change.
For account ownership, permissions and revocation, use the separate Linux user-access lifecycle guide. WebCare360 is the hosting provider publishing this article; the checks do not certify a server as secure or promise included management.
