ssh_exchange_identification: connessione chiusa dall'host remoto (non usando hosts.deny)

Sto Non utilizzare hosts.allowo hosts.deny, avanza più SSH funziona dal mio finestre-macchina (stesso portatile, disco rigido diverso), ma non la mia macchina Linux.

ssh -vvv root@host -p port dà:

OpenSSH_6.6, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to host [host] port <port>.
debug1: Connection established.
debug1: identity file /home/torxed/.ssh/id_dsa type -1
debug1: identity file /home/torxed/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6
ssh_exchange_identification: read: Connection reset by peer

Sul computer Windows tutto funziona bene, quindi ho controllato i registri di sicurezza e le linee sono identiche, il server tratta le due diverse "macchine" non diverse e sono entrambe consentite tramite autenticazione a chiave pubblica.

Questo porta alla conclusione che questo deve essere un problema con il mio laptop ArchLinux locale .. ma cosa?

[torxed@archie ~]$ cat .ssh/known_hosts 
[torxed@archie ~]$ 

Quindi non è questo il problema ...

[torxed@archie ~]$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

Nessun conflitto con le impostazioni del firewall (per ora) ..

[torxed@archie ~]$ ls -la .ssh/
total 20
drwx------  2 torxed users 4096 Sep  3  2013 .
drwx------ 51 torxed users 4096 May 11 11:11 ..
-rw-------  1 torxed users 1679 Sep  3  2013 id_rsa
-rw-r--r--  1 torxed users  403 Sep  3  2013 id_rsa.pub
-rw-r--r--  1 torxed users  170 May 11 11:21 known_hosts

Le autorizzazioni sembrano andare bene (lo stesso sul server). Provato anche senza eseguire la configurazione /etc/ssh/ssh_configcon lo stesso risultato, tranne che per molta configurazione automatica in corso nel client che finisce con lo stesso errore.

Se hai escluso qualsiasi fattore "esterno", la seguente serie di passaggi di solito aiuta a restringerlo. Quindi, sebbene ciò non risponda direttamente alla tua domanda, può aiutarti a rintracciare la causa dell'errore.

Risoluzione dei problemi sshd

Ciò che trovo generalmente molto utile in questi casi è iniziare sshdsenza lasciarlo demonizzare. Il problema nel mio caso è stato che né syslogné auth.logha mostrato qualcosa di significativo.

Quando l'ho avviato dal terminale ho ottenuto:

# $(which sshd) -Ddp 10222
/etc/ssh/sshd_config line 8: address family must be specified before ListenAddress.

Molto meglio! Questo messaggio di errore mi ha permesso di vedere cosa c'è che non va e risolverlo. Nessuno dei file di registro conteneva questo output.

NB: almeno su Ubuntu $(which sshd)è il metodo migliore per soddisfare i sshdrequisiti di un percorso assoluto. In caso contrario, si otterrà il seguente errore: sshd re-exec requires execution with an absolute path. Le -p 10222marche sshdascolto su quella porta alternativa, sovrascrivendo il file di configurazione - è così che non si scontra con potenzialmente in esecuzione sshdistanze. Assicurati di scegliere una porta libera qui.

Infine: connettiti alla porta alternativa ( ssh -p 10222 user@server).

Questo metodo mi ha aiutato molte volte a trovare problemi, siano essi problemi di autenticazione o altri tipi. Per ottenere un output davvero dettagliato stdout, utilizzare $(which sshd) -Ddddp 10222(notare l'aggiunta ddper aumentare la verbosità). Per ulteriori controlli di bontà di debug man sshd.

Puoi anche avere un host la cui memoria è così gravemente frammentata che non può allocare una pagina di memoria contigua per fork il processo per l'hosting di una sessione SSH.

In tal caso, è possibile ottenere uno dei messaggi:

ssh_exchange_identification: read: Connection reset by peer

o:

Connection closed by aaa.bbb.ccc.ddd

a seconda di quanto arriva l'host prima che salti fuori.

Se la frammentazione della memoria è la causa apparente, la soluzione è accedere al server con altri mezzi e riavviare alcuni dei servizi pertinenti. Ho scoperto che Apache e MySQL sono i colpevoli delle VM poiché le VM non hanno una partizione di swap. In caso contrario, riavviare l'host.

Per ogni evenienza, perché mi è successo. Assicurati di avere sshd in esecuzione nell'host!

È un fallimento stupido, ma potrebbe essere davvero il tuo problema.

Ho scoperto che questo errore era dovuto al superamento delle sessioni ssh sul server. Ho trovato gli host che cercavano di connettersi e ho ucciso tutte le sessioni di tutti i client. Il problema è stato risolto dopo aver chiarito tutte le sessioni.

Ho riscontrato il ssh_exchange_identification: read: Connection reset by peerproblema in uno script che avvia 16 o più sessioni ssh in un ciclo. sshd apparentemente non riesce a tenere il passo; l'aggiunta di un breve sonno risolto il mio problema:

for i in $(seq 32)
do
    ssh -f root@$HOST "./test_server -p $(expr $BASE_PORT + $i)" > svr${i}.out
    # for > 8 connections, ssh has ssh_exchange_identification issues
    sleep 0.1
done

Oppure potresti aver fatto quello che ho fatto, ieri sera, e cancellato / var / vuoto. Apparentemente quella directory e le sue autorizzazioni sono essenziali per il funzionamento di sshd e non rifarà la directory quando riavviata /etc/init.d/sshdnon si riavvierà e nulla di systemd ti dirà perché.

Ho riscontrato il problema eseguendo sshd in primo piano:

# /usr/sbin/sshd -Dd
  Missing privilege separation directory: /var/empty/sshd

Ricostruire le directory ha risolto il problema nel mio caso:

drwxr-xr-x. root root  /var/empty
drwx--x--x. root root  /var/empty/sshd

Nota per i programmatori Linux: cose di fondamentale importanza in /var/empty... davvero ???

Ho riscontrato l'errore ssh_exchange_identification: Connection closed by remote hostdurante il tentativo di connessione a SSH: ho eseguito un port forwarding remoto per la porta SSH 22 del mio computer locale in modo da potervi accedere temporaneamente da un server remoto su Internet.

In realtà l'errore è stato appena visualizzato perché non mi ricordo che ho disabilitato il servizio SSH all'avvio quindi ho dovuto avviare il servizio SSH sul mio computer locale: sudo service ssh start.

Per prima cosa; telnet all'indirizzo IP host per verificare se la porta 22 è effettivamente in ascolto (aperta) su quell'host:

telnet x.x.x.x 22

(in caso contrario, è possibile collegare un cavo della console per accedere)

Nel mio caso, non funzionava e ho collegato un cavo console per accedere. Una volta effettuato l'accesso, ho scoperto che tutte e 5 le linee VTY erano occupate su quell'host (un router Cisco).

Ho cancellato le vecchie connessioni che erano appese lì per liberare le linee VTY, ha funzionato. Ho aggiunto il comando "exec-timeout 15" sotto le righe VTY. Quindi ho rimosso il cavo della console.

Lezione:

Assicurati di impostare un timeout di 5-10 minuti su tutti i tuoi dispositivi - (se non viene rilevata alcuna attività).

Il mio caso è stato erroneamente impostato proxy socket (che non funziona). Ho ottenuto esattamente lo stesso output ssh -vvv e il registro sshd vuoto.

L'errore ssh_exchange_identification: Connection closed by remote hostpuò verificarsi per alcuni motivi sconosciuti. Quando stavo usando il codice di Visual Studio . Lo stesso errore si è verificato quando ho provato a estrarre dal repository remoto utilizzando il git pullcomando.

Ho appena chiuso il terminale integrato e aperto del terminale di Ubuntu e tirato di nuovo. E ebbe successo

Da con CentOS Linux release 7.4.1708 (Core)with OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017behind una connessione che non filtrava le porte che avevo:

ssh_exchange_identification: connessione chiusa dall'host remoto

E si è scoperto che il mio Raspberry Pi era spento!

Pensavo che un host non acceso avrebbe prodotto l'errore "Nessun percorso verso l'host". Il Raspberry Pi è dietro il mio router ISP, quindi è probabilmente quello che stava chiudendo la connessione.

Quindi ho ripetuto l'esperimento (tentando la connessione a un Raspberry Pi spento) da un'altra connessione Internet anche senza filtrare le porte con Debian Stretch OpenSSH_7.4p1 Debian-10+deb9u3, OpenSSL 1.0.2l 25 May 2017e questa volta ho avuto l'atteso:

Nessun percorso verso l'host