When SSH to Xserver suddenly stops working, it's fail2ban — the official confirmation and a safer reconnection check

If you run WordPress maintenance for clients on Xserver, sooner or later you hit this: SSH was working fine this morning, and now your connection dies the instant it touches the host. No key change on your side, no obvious server-side incident. Just Connection closed by ..., and the silence deepens every time you retry.

A recent escalation to Xserver support gave us an official answer about what's actually going on. Worth writing down what an operator needs to know.

What the symptom looks like

In our observation, the symptom moves through two stages.

• 
  Lighter: Connection closed by [Xserver IP] — connection killed at the sshd layer before it's established


• 
  Heavier: ssh: connect to host ... port 10022: Connection refused — escalated to a firewall reject

If you notice the lighter stage early, recovery is still in sight. If you keep retrying, you move into the heavier stage, and waiting is the only viable option for a while.

What Xserver support told us

While escalating an unrelated issue, we asked Xserver about this "source-IP gets blocked" behavior. The official response:

When the attempt count exceeds the threshold, fail2ban temporarily restricts the source IP. The specific threshold, bantime, findtime, and whether manual unbanning is supported are kept confidential for security reasons.

So Connection closed / Connection refused from Xserver is the protection mechanism doing its job — not a server-side fault. The confidentiality of the threshold is reasonable (publishing it would help attackers), but two things you can operate with:

• 
  There is no manual-unban support channel (you have to wait it out)


• 
  Self-recovery happens within roughly half a day to a day (verified against our own production setup)

What triggers it

Even without intentional brute force, normal operational patterns can structurally trigger it. The most common one we see is having multiple SSH keys available to the agent while a maintenance tool repeatedly opens connections to Xserver.

paramiko and the OpenSSH client try the host key, ~/.ssh/id_*, and any keys in the SSH agent in sequence. With three keys registered, a single connection costs three to four auth attempts. When a maintenance tool fires those connections in parallel across multiple sites, the cumulative MaxAuthTries overruns add up fast enough to trip fail2ban's threshold.

The application-side fix (forcing look_for_keys=False / allow_agent=False in paramiko to constrain which keys are tried) is covered in covers the design angle.

The half-second of "did the server break?" panic settles a lot faster once you can name the protection mechanism by sight. It's a small piece of operational vocabulary that meaningfully changes how an agency carries the surprise.