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 the paramiko default that triggers IP blocks. This post stays on what to do once you’re already blocked.
What to do once you’re already blocked
Two real options.
1. Wait. No support channel for manual unban exists, so waiting half a day to a day is, in practice, the shortest path. If you have a scheduled maintenance window, tell the client “the server’s protection mechanism temporarily restricted access; we’ll resume after release.” Calling it an “outage” misses the truth.
2. Switch your source IP. If you can reach the server from a different network (mobile WiFi, phone tethering, a fixed-IP service), recovery is immediate. We keep a domestic fixed-IP service on hand (Interlink My IP) and have confirmed that even while the primary line is blocked, ssh layer2024@layer2024.xsrv.jp works fine from the fixed IP. fail2ban operates per source IP, so different IPs go through normally.
A reconnection-check command that minimizes re-trigger risk
Right after recovery, what you actually want is a command that uses the fewest possible auth attempts to verify the line is back. If you have multiple keys registered and you just type ssh user@host, the cascading attempts can drop you right back into the same block.
ssh -i ~/.ssh/layer2024_xserver.key \
-o IdentitiesOnly=yes \
-o IdentityAgent=none \
-p 10022 \
layer2024@layer2024.xsrv.jp 'echo ok'
IdentitiesOnly=yes— only the key specified with-iis tried (no auto-tries on~/.ssh/id_*)IdentityAgent=none— keys held in the SSH agent are not tried at all'echo ok'— checks the connection without opening a shell, then exits immediately
Make this your standard “first touch” command for Xserver. If your maintenance tooling carries the same posture (paramiko’s look_for_keys=False / allow_agent=False), the structural cause stops recurring.
Wrap-up
If SSH to Xserver suddenly stops working, suspect fail2ban first, not a server fault. No manual-unban path exists; the choice is wait or switch source IPs. After recovery, run your first connection with IdentitiesOnly=yes / IdentityAgent=none so the verification itself doesn’t re-trigger the block. For the application-side fix, paramiko’s default behavior 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.