Restricting the number of authentication attempts on SSH reduces exposure to password guessing and credential stuffing attacks against remote entry points. Enforcing a strict limit per connection makes brute-force activity noisy, slow, and easier to detect in logs.

In OpenSSH, the MaxAuthTries directive in the daemon configuration controls how many failed authentication attempts are permitted for a single network connection before the server terminates the session. Each unsuccessful use of a method such as password, public key, or keyboard-interactive increments the counter, and when the configured threshold is reached, the connection is closed even if the account itself is not locked.

Choosing an appropriate MaxAuthTries value balances security against usability, especially where multiple authentication factors or methods are required in one session. On typical Linux systems running OpenSSH under systemd, the setting is defined in /etc/ssh/sshd_config and changes only take effect after the ssh or sshd service is reloaded. Administrative access with sudo or the root account is required, and a misconfigured file can prevent new remote logins until corrected from a console.

Steps to limit SSH authentication attempts:

  1. Open a terminal on the server with an account that has sudo privileges.
    $ whoami
    admin
  2. Create a timestamped backup of the current SSH daemon configuration file.
    $ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup.$(date +%F-%H%M)

    Incorrect edits in /etc/ssh/sshd_config or a failed reload can block new SSH sessions until the file is fixed from console access.

  3. Open the SSH daemon configuration file in a text editor.
    $ sudo nano /etc/ssh/sshd_config

    /etc/ssh/sshd_config is the main configuration file read by sshd for global and per-connection authentication settings.

  4. Locate an existing MaxAuthTries directive or append one in the global options section.
    # Limit authentication attempts per connection
    MaxAuthTries 3

    Each failed authentication method consumes one attempt; multi-factor flows that try keys and passwords in one connection may need a slightly higher MaxAuthTries value than single-password logins.

  5. Ensure the chosen MaxAuthTries value matches security policy and typical user workflows, such as single password prompts or combined key and password prompts.

    Values between 3 and 5 are common to reduce brute-force noise while still allowing occasional typing mistakes.

  6. Validate the modified configuration syntax using the sshd -t check.
    $ sudo sshd -t

    No output indicates that the configuration syntax is valid; any error will mention the first problematic line and must be corrected before proceeding.

  7. Reload the SSH daemon to apply the new configuration.
    $ sudo systemctl reload ssh

    On distributions where the service is named sshd instead of ssh, use sudo systemctl reload sshd.

  8. Confirm that the SSH service is active and reports no recent errors.
    $ sudo systemctl status ssh
    ● ssh.service - OpenBSD Secure Shell server
         Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
         Active: active (running) since Thu 2025-12-11 10:15:01 UTC; 5s ago
    ##### snipped #####
  9. Verify the effective MaxAuthTries value reported by the running daemon.
    $ sudo sshd -T | grep -i maxauthtries
    maxauthtries 3

    Output from sshd -T reflects the final configuration after all includes and Match blocks, confirming the value actually in use.

  10. From a separate client, test that the connection is terminated after the configured number of failed attempts.
    $ ssh user@server.example.com
    user@server.example.com's password:
    Permission denied, please try again.
    user@server.example.com's password:
    Permission denied, please try again.
    user@server.example.com's password:
    Permission denied (publickey,password).
    Connection closed by 203.0.113.10 port 22

    Testing from a trusted client confirms behavior, but repeated failed attempts from untrusted networks can still trigger upstream intrusion detection or blocklists.

Discuss the article:

Comment anonymously. Login not required.