Sometimes SSH stops working even though the server is reachable, the website still opens, and the SSH service itself is active.
In that situation, the cause may not be a server failure at all, but a firewall protection rule.
One practical scenario is an automatic SSH tunnel that tries to reconnect too frequently after losing its connection. If the server uses UFW with a LIMIT rule for SSH, repeated attempts can cause new connections from the same IP address to be rejected.
1. Check UFW Limit Blocks
sudo journalctl -k --since "1 hour ago" --no-pager \ | grep 'UFW LIMIT BLOCK' \ | grep 'DPT=22' \ | tail -20[UFW LIMIT BLOCK] entries for port 22 confirm that the firewall is rejecting new connections because the rate limit has been triggered.
This is an important diagnostic boundary: the server has not failed. Its protection layer is deliberately refusing some new attempts.
2. Inspect Automatic SSH Tunnels
systemctl --user show my-ssh-tunnel.service \ -p ActiveState \ -p NRestarts \ -p RestartUSecA high restart count combined with a very short delay can explain the repeated SSH connection attempts.
Each attempt is legitimate on its own, but a rapid sequence of reconnects can conflict with the server-side protection rule.
Automatic Recovery Can Become the Problem Itself
An automatic tunnel exists for reliability: if the connection drops, the service should establish it again.
Without enough delay, however, a short network problem can create a loop: the tunnel fails, systemd immediately starts SSH again, connectivity has not recovered yet, the service fails again, and another attempt follows seconds later.
After enough attempts, UFW LIMIT may start blocking manual administrative SSH access as well.
3. Increase the Reconnect Delay
[Service]Restart=on-failureRestartSec=90sThe important point is not the exact value of 90 seconds. The principle is that reconnect attempts should not happen so frequently that they conflict with the server-side rate limit.
Reload Configuration Without an Unnecessary Tunnel Restart
systemctl --user daemon-reloaddaemon-reload lets systemd re-read changed unit files without forcing an active tunnel to restart immediately.
The new RestartSec value will apply the next time the service restarts automatically.
Verify the Result
After increasing the delay, verify two separate things: new administrative SSH connections work again, and the automatic tunnels remain active.
The fix should not simply disable the reliability mechanism the tunnels were created to provide.
systemctl --user is-active \ my-ssh-tunnel.service ss -lntDo Not Start by Weakening the Firewall
If UFW LIMIT was triggered by an aggressive reconnect loop, weakening the firewall treats the symptom rather than the cause.
In this scenario, there is no need to disable UFW, remove the protective rule, or reboot the server simply to restore SSH.
First reduce retry frequency and verify the result.
For More Complex Retry Logic, Use Progressive Backoff
A fixed RestartSec works well for a simple tunnel.
If connectivity may remain unavailable for longer, increase the delay after each failed attempt, for example 10, 30, 60, and 120 seconds with a maximum cap.
This reduces pressure during a prolonged outage and avoids an endless stream of new SSH connection attempts.
The Main Lesson
Automatic connection recovery needs limits too.
Overly aggressive retries can conflict with server protection and effectively lock out the administrator.
SSH tunnels should use a sufficient delay between attempts, and more complex scenarios should use progressive backoff.
An automatic recovery mechanism should not generate more reconnect attempts than the server protection layer is designed to accept.
