ssh_exchange_identification: read: connessione ripristinata dal peer

107

Sono su OS X che prova a ssh in un server Ubuntu 12.04. Sono stato in grado di entrare in SSH - fino a quando le cose improvvisamente non hanno smesso di funzionare. Ho letto online per usare il -vdebug di questo. L'output è mostrato di seguito. Se ho SSH in una casella diversa e quindi SSH da quella casella al server sono in grado di accedere. Non ho idea di come eseguire il debug di questo problema, ma vorrei imparare.

$ ssh -v me@server
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug1: Connecting to server [IP] port 22.
debug1: Connection established.
debug1: identity file /Users/me/.ssh/id_rsa type 1
debug1: identity file /Users/me/.ssh/id_rsa-cert type -1
debug1: identity file /Users/me/.ssh/id_dsa type -1
debug1: identity file /Users/me/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: read: Connection reset by peer

Finora (su consiglio delle bacheche dei messaggi) ho cercato un file di negazione degli host , ma sulla mia macchina non è presente alcun file.

$ cat /etc/hosts.deny 
cat: /etc/hosts.deny: No such file or directory

Ho accesso come amministratore sul computer client ma non sul server.

ssh

— bernie2436
fonte

Consiglierei di iniziare un sshdascolto su una porta alternativa, con output dettagliato, e di fornire l'output quando si tenta di connettersi ad esso. $(which sshd) -d -p 23. Se non hai la possibilità di farlo, le tue opzioni sono piuttosto limitate. La cosa migliore è ottenere qualcuno che abbia i diritti di amministratore sul server.

— Patrick,

Potrebbe essere che l'amministratore sul server abbia limitato l'accesso per qualche motivo? In ogni caso, potrei contattare quella persona.

— mdpc,

12

Il file hosts.deny e hosts.allow deve essere verificato sul server , non sul client. Inoltre, è necessario controllare i registri di sistema sul server . Se non hai accesso neanche a questi, ti consigliamo di contattare l'amministratore del server per dare un'occhiata.

— ckujau,

hai trovato una soluzione? qual'era il problema?

— MeV,

2

Elenco di host.deny compilato dall'amministratore con uno script automatico. Dato che a un certo punto ho dimenticato la password, ho avuto alcuni tentativi di accesso non riusciti, quando il mio IP è stato inserito nell'elenco hosts.deny. Questo per quanto riguarda la produttività della sicurezza troppo zelante.

— K.-Michael Aye,

25

La modifica improvvisa potrebbe essere il risultato di una modifica nel file di configurazione sulla sshdconfigurazione del server , ma si indica che non è possibile verificarlo o modificarlo senza il diritto di amministratore. Puoi comunque provare quanto segue se non è possibile raggiungere gli amministratori del server (in tempo).

Il registro indica solo la stringa di versione locale, è necessario controllare le versioni in sshdesecuzione sul server e sul computer intermedio.

Se queste versioni differiscono (specialmente tra la macchina locale e il server e meno tra la macchina intermedia e il server), potrebbe esserci qualche incompatibilità di negoziazione, questo è successo prima in ssh. La soluzione consisteva nell'accorciare le voci di Cipher, HostKeyAlgorithms e / o MAC, sulla riga di comando ( ssh -c aes256-ctr, ecc.) O su nel tuo /etc/ssh/ssh_config.

Dovresti cercare nelle informazioni di debug (dalla connessione via intermedia al server) i valori appropriati come argomento per la risp. -c/ Ciphers, -o HostKeyAlgorithms/ HostKeyAlgorithmsE -m/ MACscommandline. modifiche ssh_config.

Non ho avuto questo problema da un po 'di tempo, ma IIRC, quando l'ho fatto, è stato sufficiente per forzare manualmente l'impostazione di Ciphers e HostKeyAlgorithms, dopo di che ho potuto aggiornare la sshdversione del server e il problema è scomparso.

— Anthon
fonte

3

Nel mio caso, il sshdpacchetto del server è stato aggiornato a una versione più recente e ha comportato l'incompatibilità con la mia sshconfigurazione client corrente , come hai detto. Eliminare i miei vecchi sshfile di configurazione ha funzionato. Questa dovrebbe essere la risposta accettata.

— chakrit,

2

@chakrit come hai ripulito i tuoi vecchi file di configurazione ssh?

— Jonathan,

@Jonathan Ho montato un disco di ripristino per farlo.

— Chakrit,

16

Potresti essere stato bannato da fail2bano denyhosts. In tal caso (e anche per verificarlo), se non si desidera preoccuparsi dell'assistenza del proprio provider di server, è necessario accedere al proprio server da un altro indirizzo IP: ad esempio un altro server o la connessione di casa di un amico o un hot spot wifi o utilizzo di SSH con TOR.

Una volta effettuato l'accesso, verifica che il tuo indirizzo IP sia effettivamente visualizzato /etc/hosts.deny(sul lato server). Se è così, allora fail2bano denyhostsdeve essere davvero il colpevole.

Vedi le risposte a questa domanda per la procedura per impedire il denyhostsblocco continuo del tuo indirizzo. Per fail2bantrovare il tuo IP iptables -L --line-numbere sbloccarlo iptables -D <chain> <chain number>, controlla i dettagli su howtoforge .

Potresti voler aggiungere il tuo indirizzo IP fail2bane le denyhostswhitelist (rispettivamente /etc/fail2ban/jail.conf, riga ignoreipe /var/lib/denyhosts/allowed-hosts, se necessario, crearlo (ma fai attenzione che il percorso potrebbe essere diverso sulla tua distribuzione)) per evitare che il problema si ripeta.

— Skippy le Grand Gourou
fonte

9

Sul server host, rimuovere ssh pub.key che si trova qui: ~/.ssh/authorized_keysper il tuo mac. Quindi tail -f /var/log/auth.logmentre apri un altro terminale e prova di nuovo a ssh ssh -v me@server. Se viene richiesta una password, si è verificato un problema con la chiave ssh. Se stai ancora vedendo la risposta 'ssh_exchange_identification: leggi: connessione reimpostata dal peer', allora dovresti essere in grado di identificare quale sia il problema dalla voce di registro nel file '/var/log/auth.log' dopo il tuo tentativo fallito per accedere.

Se non riesci ancora a connetterti, pubblica qui la voce registrata dal file auth e rivedrò la mia risposta.

— devnull
fonte

Non è necessario eliminare la chiave SSH in alcuni casi. Vai direttamente a tail -f /var/log/auth.log e controlla i tentativi recenti.

— Jack Robson,

6

Ciò può accadere se nella rete sono presenti più macchine con lo stesso indirizzo MAC (ad esempio, se si esegue una copia di una macchina virtuale e si dimentica di modificare il MAC).

— elCapitano
fonte

4

Lo stavo ottenendo a causa dei nameserver del mio ISP in /etc/resolv.conf. Questi server dei nomi sono spesso sovraccarichi e se la ricerca DNS inversa non riesce sshd, la connessione verrà interrotta. Ho risolto il problema utilizzando server dei nomi più affidabili, ad es 8.8.8.8.

— njahnke
fonte

4

Ho dovuto affrontare lo stesso problema. Avrei aperto con successo la sessione ssh ma dopo qualche tempo sarebbe stato ripristinato. Quando ho provato a connettere immediatamente il guadagno, ho ricevuto l'errore "Connessione rifiutata". quando ho eseguito il debug della sessione ho ricevuto questo messaggio nel momento in cui la connessione veniva ripristinata

debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: channel 0: free: client-session, nchannels 1                             
debug3: channel 0: status: The following connections are open:                   
  #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)                              

debug3: channel 0: close_fds r 4 w 5 e 6 c -1                                    
Read from remote host 10.x.y.z: Connection reset by peer                    
Connection to 10.x.y.z closed.                                              
debug1: Transferred: stdin 0, stdout 0, stderr 100 bytes in 1029.9 seconds       
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.1                      
debug1: Exit status -1

A questo punto mi sono reso conto che c'era un conflitto di indirizzi IP sulla rete. Ho cambiato in un altro indirizzo e il problema è stato risolto

— David
fonte

2

Downvotes, cosa c'è di sbagliato nella risposta? Può ancora essere un caso valido da controllare quando si scende in un elenco, forse forse non comune tra gli altri.

— Pysis,

@Pysis: risposta corretta, migliorata

— Daniel

3

Il registro indica che il lato server interrompe la connessione. Per scoprire il motivo, è necessario consultare i registri sul lato server, che dovrebbero mostrare il motivo della disconnessione. Dovresti essere quasi sempre in grado di trovare i log in / var / log / messages

Potrei immaginare che, poiché la connessione è caduta subito dopo che il client ha inviato il numero di versione, il server in qualche modo considera il client incompatibile.

— gena2x
fonte

3

Ho avuto lo stesso problema ma si è scoperto che la causa era diversa: stavo usando una porta sbagliata.

Nelle versioni più recenti sshdell'errore fornito è Connection refusedo Bad port.

Nelle versioni precedenti l'errore indicato è ssh_exchange_identification: read: Connection reset by peer

Quindi, quando si ottiene tale errore, verificare se la porta è corretta.

— Mugoma J. Okomba
fonte

1

So che questa domanda è vecchia, ma volevo condividere alcuni risultati che ho avuto. Controlla se /var/empty/sshdsul server ha la proprietà e le autorizzazioni appropriate.

Avevamo uno script chef che è stato modificato per aggiornare alcune autorizzazioni della directory, ma inavvertitamente abbiamo aggiornato la directory sotto la destinazione prevista, cambiando la proprietà di / var in un utente / gruppo dell'applicazione e cambiando le autorizzazioni in 775.

— Andrew Boerema
fonte

1

Poiché non è stato menzionato esplicitamente in una risposta, un altro modo in cui questo errore può apparire è se un firewall basato sulla rete tra te e il server ha deciso di bloccare la connessione. Il firewall avrebbe potuto decidere che c'erano "troppe" connessioni dall'IP del sistema OS X e ha iniziato a bloccarlo. Non c'erano ancora "troppe" connessioni dall'altro sistema, e quindi era permesso.

L'ultimo messaggio che hai ricevuto dal server è quello che si verifica prima ancora di iniziare qualsiasi tentativo di autenticazione, il che esclude una grande classe di possibilità che circondano il tuo account, chiave o password.

Esempi di tali politiche di forza bruta da un campionamento casuale di venditori sono:

— Jeff Schaller
fonte