Tightening the SSH LoginGraceTime setting limits how long unauthenticated connections can linger before being dropped, shrinking the window for slow brute‑force attempts and hung clients. Shorter grace periods reduce idle SSH handshakes that tie up server resources and help keep interactive access responsive even under noisy scan traffic.
The LoginGraceTime directive in /etc/ssh/sshd_config controls the timeout between a client connecting and completing authentication; internally, sshd treats this as login_grace_time and enforces a disconnect once the limit is reached. Values are specified as a time interval (for example, seconds as plain integers), and OpenSSH defaults to roughly two minutes (120 seconds) if the option is left unset.
Setting LoginGraceTime too high leaves a larger attack surface for automated password guessing, while setting it too low can frustrate users on slow links or when multi‑factor prompts are involved; a common hardening pattern is to cap it at 60 seconds or less rather than disabling it with a value of zero, because zero removes the limit entirely.
$ whoami user
$ sudo sshd -T | grep logingracetime logingracetime 120
sshd -T prints the fully merged configuration that the running daemon would use without reloading it.
$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.$(date +%Y%m%d%H%M%S).bak
An invalid SSH configuration can block all remote logins; a backup allows quick rollback if authentication fails after changes.
$ sudoedit /etc/ssh/sshd_config
sudoedit edits the file with the invoking user’s editor while still applying root privileges to the saved result.
Most distributions place LoginGraceTime near other authentication directives such as MaxAuthTries.
LoginGraceTime 30
Values like 30 or 60 seconds reduce brute‑force exposure while remaining usable for legitimate users on typical networks.
Keep the current SSH session open until configuration validation and service restart complete successfully.
$ sudo sshd -t
No output from sshd -t indicates that the configuration parsed successfully; any error message must be resolved before restarting the service.
Related: How to test SSH server configuration
$ sudo systemctl restart ssh
Restarting the daemon does not drop existing sessions but can block new connections if the configuration is invalid, so avoid running this command from the only available access path.
$ 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:12:54 +08; 146ms ago
TriggeredBy: ● ssh.socket
Docs: man:sshd(8)
man:sshd_config(5)
Process: 13770 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
Main PID: 13771 (sshd)
Tasks: 1 (limit: 4546)
Memory: 2.6M (peak: 3.6M)
CPU: 43ms
CGroup: /system.slice/ssh.service
└─13771 \"sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups\"
##### snipped #####
$ sudo sshd -T | grep logingracetime logingracetime 30
The reported logingracetime value confirms that sshd is enforcing the new LoginGraceTime limit for incoming connections.
$ ssh user@host.example.net user@host.example.net's password:
Connections that do not complete authentication within the configured grace period are closed by sshd.