MaxAuthTries and LoginGraceTime directives within your server configuration file. These settings restrict the number of connection attempts allowed per session and define the window of time a user has to complete authentication, respectively. Implementing these constraints prevents brute-force attacks and reduces the attack surface for unauthorized access.
Understanding Authentication Limits
OpenSSH provides several mechanisms to control how clients interact with the authentication subsystem. While there is no single directive named MaxAuthAge that exists in standard OpenSSH releases, administrators often look for a way to expire an authentication attempt after a certain duration or limit the total time spent trying to log in. The correct approach involves combining two specific parameters: LoginGraceTime and MaxAuthTries.
The LoginGraceTime directive specifies the time limit in seconds for successful authentication. If a user does not authenticate successfully within this period, the server disconnects them. This is crucial for preventing resource exhaustion attacks where an attacker opens many connections but never completes the login process. The default value is typically 120 seconds, but this can be adjusted based on your security requirements.
Complementing this is MaxAuthTries, which limits the number of authentication attempts permitted per connection. If a client exceeds this number, the server terminates the connection. This helps mitigate dictionary attacks and automated credential stuffing tools that rely on rapid-fire login attempts.
Configuring Login Grace Time
To set the maximum time allowed for authentication, you need to edit the main SSH daemon configuration file. On most Linux distributions, this file is located at /etc/ssh/sshd_config. You should open this file using a text editor with root privileges.
- Locate the line containing
#LoginGraceTime. It may be commented out by default. - Remove the hash symbol (
#) to uncomment the directive if it exists. - If the line does not exist, add
LoginGraceTime 60(or your desired number of seconds) to the file.
For example, setting LoginGraceTime 30 ensures that any user who fails to provide valid credentials within 30 seconds will be disconnected. This aggressive timeout is suitable for environments with high-security requirements where users are expected to have their keys ready.
Setting Maximum Authentication Attempts
The MaxAuthTries directive works in tandem with the grace time. By limiting the number of tries, you ensure that even if a user has enough time, they cannot spam the authentication service indefinitely.
- Find or add the
MaxAuthTriesdirective in/etc/ssh/sshd_config. - Set it to a low integer, such as
3or4.
A value of 3 means that after three failed attempts, the connection is closed. This forces attackers to reconnect from a new IP address or wait for the ban mechanism (if configured via fail2ban or similar tools) to activate. For more information on securing your host after establishing an SSH connection, consider reading our guide on Securing Host After Connecting Through OpenSSH.
Applying Changes and Verification
After modifying the configuration file, you must restart the SSH service for the changes to take effect. The command varies depending on your init system.
On systems using systemd, run:
sudo systemctl restart sshdOn older SysVinit systems, use:
sudo service ssh restartTo verify that your settings are active, you can check the running configuration without restarting the service again by using the -T flag with sshd:
sudo sshd -T | grep -E 'logingracetime|maxauthtries'This output will display the effective values currently enforced by the daemon. Ensure that the numbers match your intended configuration. Additionally, reviewing Persistently configure the OpenSSH daemon on Linux can help you understand other persistent settings that complement these authentication limits.
Security Implications and Best Practices
Enforcing strict authentication limits is a fundamental layer of defense-in-depth. However, it is important to balance security with usability. Setting LoginGraceTime too low might disconnect legitimate users who are typing slowly or dealing with network latency. Similarly, restricting MaxAuthTries too aggressively could lock out users who mistype their passwords frequently.
Combine these settings with key-based authentication to further enhance security. Password authentication is inherently weaker than public-key authentication. By disabling password logins entirely and relying on SSH keys, you eliminate the risk of brute-force password attacks altogether. For tips on strengthening your authentication methods, see How to Make Your SSH Password More Secure.
Additionally, monitor your logs for repeated disconnections due to these limits. Tools like auditd or centralized logging solutions can alert you to potential scanning activity targeting your SSH port. Regularly updating your OpenSSH version ensures you benefit from the latest security patches and feature improvements.
Frequently Asked Questions
Is there a MaxAuthAge option in OpenSSH?
No, there is no directive named MaxAuthAge in standard OpenSSH configurations. Administrators should use LoginGraceTime to limit the duration of the authentication phase and MaxAuthTries to limit the number of attempts instead.
What happens if a user exceeds MaxAuthTries?
If a client exceeds the specified number of authentication attempts, the SSH daemon immediately terminates the connection. The client must establish a new connection to try again, which resets the counter.
Can I set different timeouts for different users?
OpenSSH does not support per-user timeout configurations directly in sshd_config. You would need to use external tools like PAM modules or wrapper scripts to implement granular, user-specific authentication timing policies.
Does changing LoginGraceTime affect existing sessions?
No, LoginGraceTime only applies to new connection attempts during the authentication phase. Existing established sessions are not affected by this setting and will continue until the user disconnects or the session times out due to idle inactivity.
Should I disable password authentication when using these limits?
Yes, it is highly recommended to disable password authentication (PasswordAuthentication no) when enforcing strict limits. Key-based authentication is faster and more secure, reducing the likelihood of accidental lockouts while providing stronger protection against brute-force attacks.