agent timed out on ssh banner and the sweep failed

TL;DR

A banner timeout means sshd accepted the connection (or a middlebox did) but the greeting and key exchange did not complete in time. On loaded hosts sshd can be starved; DNS reverse lookups on connect (a common sshd behavior) can stall each new connection; and some network devices proxy the connection and delay the banner. Diagnose with a verbose ssh -vvv timing run, raise the agent ConnectTimeout moderately, reduce connection burst rate, and fix server-side causes (reverse DNS, host load) where they are yours to fix.

agent timed out on ssh banner and the sweep failed

Use this when

• Agent logs show Timeout while waiting for the SSH banner or Connection timed out during banner exchange.
• Manual SSH to the same hosts works, but slowly.
• Failures spike when many connections start at once.

Not for this skill when

• Connections refuse immediately. That is a closed port or down host, not a banner stall.
• Authentication itself times out after a fast banner. Different stage; look at PAM and auth backends.

Steps

1. Reproduce with ssh -vvv and timestamps against a failing host and note the pause point (banner read, kex, auth). Verify: the stall stage is identified from the debug output
2. Check the host load and sshd responsiveness at sweep time, and whether sshd does reverse DNS lookups that hang on your DNS. Verify: load or DNS delay is confirmed or ruled out with evidence
3. Adjust the agent: raise ConnectTimeout to cover the observed worst case (commonly 30 to 60 seconds), and add connection pacing so bursts do not create the overload. Verify: the agent config carries both changes
4. Fix server-side contributors fleet-wide where applicable: working DNS for client addresses or sshd settings per your standard, and MaxStartups sized for sweep bursts. Verify: the change is applied via config management
5. Re-run the sweep and compare banner timeout counts. Verify: banner-stage failures drop to near zero and remaining ones name specific hosts

Variant phrasings

timeout waiting for ssh banner agent sweep fix

The error-string phrasing.

ssh connect slow reverse dns lookup sshd delay

The common root-cause phrasing.

kex exchange stalls loaded host maxstartups banner

The overload phrasing.

Compatibility: Compatibility: OpenSSH client and server; verbose debugging identical across Linux and macOS clients.

Why it happens

The SSH banner is the first bytes after connect, so a stall there implicates everything before authentication: server CPU to fork and run sshd, the server resolver doing a reverse lookup of your agent address, and any middlebox holding the connection. Because interactive users connect once and wait, this stage degrades invisibly until an agent connects hundreds of times and starts timing out.

Edge cases / pitfalls

• An agent address range missing from reverse DNS is a fleet-scale tax on every connection; fix the zone or the sshd lookup behavior deliberately, knowing the logging tradeoff.
• Entropy starvation on old VMs can stall key exchange; check the platform if only ancient hosts stall at kex.
• Very high ConnectTimeout values hide dying hosts for minutes per sweep; pair any raise with pacing and per-host deadlines.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstckqsBKkt0paIWi0O3MDSQ