Le forme di questo messaggio
kex_exchange_identification: read: Connection reset by peer
Connection reset by 203.0.113.10 port 22kex_exchange_identification: Connection closed by remote host
Connection closed by 203.0.113.10 port 22I client recenti possono stampare solo l'ultima riga, Connection closed by 203.0.113.10 port 22, a meno che tu non aggiunga -v. Reset e closed differiscono solo per il modo in cui la connessione è terminata. Trattali come lo stesso problema, perché la stessa causa può mostrare l'uno o l'altro a seconda di cosa c'è in mezzo.
Parti da qui
ssh -v user@server trueQuesta riga nell'output è un indizio molto utile:
debug1: kex_exchange_identification: banner line 0: Not allowed at this timeQuel testo viene da sshd stesso. Significa che il server è attivo e ti sta scartando di proposito, quindi vai alla causa 1 e alla causa 2. Per leggere il motivo, usa una console o un'altra connessione sul server:
sudo journalctl -u ssh -u sshd --since "1 hour ago" | grep -iE 'maxstartups|penalty'Se sei rimasto chiuso fuori, prova anche da un'altra rete, come l'hotspot del telefono. Se funziona, il blocco è legato al tuo indirizzo.
Causa 1: penalità di sshd
Da OpenSSH 9.8, sshd penalizza gli indirizzi che falliscono il login, ed è attivo per impostazione predefinita. Finché dura la penalità, le nuove connessioni da quell'indirizzo vengono scartate. Il log del server mostra:
drop connection #0 from [203.0.113.10]:41056 on [203.0.113.20]:22 penalty: failed authenticationBasta aspettare: il massimo predefinito è 10 minuti. È più probabile che ti capiti dietro un indirizzo di ufficio condiviso, o con uno script o un job di monitoraggio che continua a fallire, quindi correggi prima ciò che fallisce. Per un indirizzo fidato, aggiungi questo a sshd_config:
PerSourcePenaltyExemptList 203.0.113.10Un client che offre molte chiavi può fallire più volte in un solo accesso. Vedi Too many authentication failures per limitarlo alla chiave giusta.
Causa 2: MaxStartups
MaxStartups limita le connessioni che non hanno ancora fatto il login. Il valore predefinito è 10:30:100: da 10 di queste connessioni in poi, sshd scarta le nuove a caso con una probabilità del 30%, che sale finché a 100 le scarta tutte. I bot che scansionano un server pubblico possono riempirlo. Il log mostra:
drop connection #1 from [203.0.113.10]:37954 on [203.0.113.20]:22 MaxstartupsLe versioni più vecchie registrano exceeded MaxStartups. Controlla l'impostazione e le connessioni attuali:
sudo sshd -T | grep -iE '^(maxstartups|persourcemaxstartups|logingracetime)'
ss -tn state established '( sport = :22 )'Il guasto è spesso intermittente: un nuovo tentativo funziona. Per fare spazio, alza il limite e riduci il traffico dei bot con una lista di indirizzi consentiti nel firewall o un LoginGraceTime più breve:
MaxStartups 30:30:100Verifica e applica. Il servizio si chiama ssh su Debian e Ubuntu e sshd sui sistemi in stile Red Hat:
sudo sshd -t && sudo systemctl reload sshCausa 3: TCP wrappers
OpenSSH upstream ha abbandonato questa funzione da tempo, ma alcune distribuzioni la compilano ancora. Debian 13 sì, e una riga sshd: ALL in /etc/hosts.deny ha prodotto il messaggio di reset nella nostra prova. Da OpenSSH 9.8 la libreria è collegata a sshd-session, non a sshd, quindi controllali entrambi:
ldd /usr/sbin/sshd /usr/lib/openssh/sshd-session 2>/dev/null | grep libwrap
grep -v '^#' /etc/hosts.deny /etc/hosts.allowRimuovi la regola, oppure consenti il tuo indirizzo in /etc/hosts.allow:
sshd: 203.0.113.10Causa 4: un firewall o fail2ban
Un firewall, un load balancer o un dispositivo di prevenzione delle intrusioni che invia un reset TCP dopo l'apertura della connessione dà questa famiglia di messaggi. L'abbiamo riprodotto con questa regola, dove SSH ha stampato Connection reset by peer:
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate ESTABLISHED -j REJECT --reject-with tcp-resetfail2ban è una causa meno probabile di questo messaggio di quanto si pensi. Le sue azioni predefinite rifiutano le nuove connessioni, che il client segnala come Connection refused, non come reset. Vale comunque la pena guardarlo se hai fallito più login:
sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 203.0.113.10Vedi fail2ban per SSH per saperne di più.
Causa 5: un tunnel con un vicolo cieco
Se ti connetti attraverso un tunnel o un inoltro di porta, il primo salto accetta la tua connessione e poi non riesce a raggiungere la vera destinazione. Il client vede il reset. Con ssh -L, il terminale dove gira il tunnel mostra il vero motivo:
channel 3: open failed: connect failed: Connection refusedGuarda lì, o nel log del tuo proxy. Controlla che indirizzo e porta della destinazione siano giusti e che sshd sia in esecuzione sulla destinazione.
Causa 6: sshd stesso ha un problema
Quando i casi sopra non corrispondono, prova la configurazione ed esegui una copia di debug su una porta libera. Il tuo servizio normale continua a funzionare:
sudo sshd -t
sudo /usr/sbin/sshd -d -p 2200Poi connettiti con ssh -p 2200 user@server e leggi cosa stampa la copia di debug. Consenti prima quella porta nel firewall e chiudila dopo.
Domande
Cosa significa kex_exchange_identification: Connection reset by peer?
La connessione TCP si è aperta ma è stata interrotta prima del saluto SSH. Il server, o qualcosa nel mezzo, ti ha respinto prima di controllare chiavi o password.
Quanto dura una penalità di sshd?
Da OpenSSH 9.8 le penalità crescono con i fallimenti ripetuti, fino a 10 minuti di base. Basta aspettare, e PerSourcePenaltyExemptList esclude gli indirizzi fidati.
Perché il reset capita solo a volte?
Un reset intermittente indica spesso MaxStartups: quando troppe connessioni stanno ancora facendo l'accesso, sshd scarta a caso quelle nuove.
Fonti
- sshd_config(5), MaxStartups e PerSourcePenalties
- Note di rilascio di OpenSSH 9.8
- sshd(8), manuale OpenBSD
- hosts_access(5), manuale Debian