ssh:manage-failed-logins

Limiting failed login attempts on SSH reduces exposure to brute-force attacks and keeps remote access predictable. Shorter authentication windows and stricter attempt limits make it harder for automated tools to cycle through passwords while still allowing normal administration tasks.

On most Linux systems, the OpenSSH server reads its configuration from /etc/ssh/sshd_config and enforces parameters such as LoginGraceTime and MaxAuthTries. LoginGraceTime controls how long a new connection may attempt to authenticate before being dropped, while MaxAuthTries defines how many failures are accepted on a single connection before termination.

Tighter values improve security but reduce the margin for typing mistakes or slow authentication methods. Root or sudo access on the server is required to adjust these directives, and configuration syntax should be validated before restarting the ssh service to avoid lockouts. For IP-based blocking and account lockout behaviour, pairing these settings with tools such as fail2ban or PAM-based controls provides additional protection.

Open a terminal on the server with access to sudo.
```
$ whoami
user
```
Create a backup of the current /etc/ssh/sshd_config file before changing any settings.
```
$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
```
Invalid syntax or values in /etc/ssh/sshd_config can prevent new SSH logins; a backup enables rollback from a console or out-of-band session.
Open the main SSH daemon configuration file in a text editor with elevated privileges.
```
$ sudo vi /etc/ssh/sshd_config
```
Any text editor such as nano or vim is suitable as long as it is run with sudo.
Locate the LoginGraceTime directive and set the time allowed for authentication after a connection is established.
```
LoginGraceTime 30
```
Remove # at the start of the line to uncomment the directive or add it if it does not exist.

Units such as s, m, or h are accepted, for example LoginGraceTime 30s or LoginGraceTime 1m; setting the value to 0 disables the grace timer and keeps connections open indefinitely during authentication.
Locate the MaxAuthTries directive and set the maximum number of authentication failures permitted per connection.
```
MaxAuthTries 3
```
Add the directive if it does not exist and remove any leading # to activate it.

Values between 2 and 4 are common for hardened servers; higher values tolerate more mistakes but provide more room for brute-force attempts.
Exit the editor after writing the configuration changes to disk.

In vi or vim, press :wq and Enter to save the file and quit.
Validate the sshd configuration syntax before restarting the service.
```
$ sudo sshd -t
```
No output indicates that the configuration is syntactically valid; any reported error includes a line number to correct.

Related: How to test SSH server configuration
Restart the ssh service to apply the updated login limits.
```
$ sudo systemctl restart ssh
```
Related: How to manage the SSH server service with systemctl in Linux
On some distributions the service name is sshd, in which case use sudo systemctl restart sshd instead.

Check that the ssh service is active after the restart.

$ sudo systemctl status ssh
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/usr/lib/systemd/system/ssh.service; enabled; preset: enabled)
     Active: active (running) since Sun 2026-01-11 05:42:55 +08; 139ms ago
TriggeredBy: ● ssh.socket
       Docs: man:sshd(8)
             man:sshd_config(5)
    Process: 15061 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
   Main PID: 15062 (sshd)
      Tasks: 1 (limit: 4546)
     Memory: 2.7M (peak: 3.7M)
        CPU: 35ms
     CGroup: /system.slice/ssh.service
             └─15062 \"sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups\"
##### snipped #####

The Active line should show active (running) and recent log lines should not report configuration errors.

Test the new limits by attempting authentication with incorrect credentials from a different session or host.

$ ssh invaliduser@host.example.net
invaliduser@host.example.net's password:
Permission denied, please try again.
invaliduser@host.example.net's password:
Permission denied, please try again.
invaliduser@host.example.net's password:
Received disconnect from 203.0.113.50 port 22:2: Too many authentication failures

The connection ends after the configured number of failures, and matching entries appear in /var/log/auth.log or the system journal via journalctl -u ssh.

How to manage failed login attempts in SSH

Steps to manage failed login attempts in SSH: