Problema SSH - Lettura dal socket non riuscita: connessione reimpostata dal peer

23

Posso SSH in una direzione senza problemi:

OK:

ssh user@computerA

ma nell'altro modo:

ssh user@computerB

Ho capito Read from socket failed: Connection reset by peer.

Non comincio nemmeno a sapere dove cercare per risolvere questo.

Qualcuno ha qualche indizio?

ssh

— boehj
fonte

Qual è la tua configurazione di rete? C'è qualche macchina dietro un firewall / router?

— NorTicUs

Entrambi appena collegati tra loro tramite cavo Ethernet tramite un router. Hanno SSH in entrambe le direzioni in passato.

— Boehj,

Hai controllato che entrambi i demoni SSH siano in esecuzione? Qualcosa nei registri?

— NorTicUs

Buone e cattive notizie: ho risposto alla mia domanda. Lo scrivo di seguito. Grazie per l'aiuto comunque.

— Boehj,

13

iniziare a monitorare il file di registro del server

tail -f /var/log/auth.log
aggiungere -v per ottenere un output dettagliato all'estremità del client

ssh user@computerB -v

Questo potrebbe darti maggiori dettagli sulla causa. se sul server mancano le chiavi rsa e dsa, correggerle mediante:

ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_rsa_key
ssh-keygen -t dsa  -f /etc/ssh/ssh_host_dsa_key

— antrace
fonte

Questo ha funzionato per me. Anche se dovevo essere root per eseguire quanto segue: ssh-keygen -t dsa -f / etc / ssh / ssh_host_dsa_key

— StarDust

La rigenerazione delle chiavi funziona sicuramente. Nel mio caso stava cambiando l'indirizzo IP della macchina dopo aver installato openssh (e le chiavi generate durante l'installazione).

— Alfishe,

Dopo aver fatto ciò, ho perso qualsiasi possibilità di connettermi al mio server. Ho dovuto chiedere l'aiuto del provider di hosting. Aspetto ancora la loro risposta. Centos 7 con cPanel.

— Tomas Gonzalez,

8

Ho reinstallato i bit SSH facendo:

sudo apt-get --reinstall install openssh-server openssh-client

Ciò ha risolto tutti i miei problemi.

— boehj
fonte

8

Potrebbe essere una coincidenza. Il fatto che il problema non si sia verificato al momento della reinstallazione di ssh non è una garanzia ermetica di causa ed effetto. A proposito, da che parte hai reinstallato? O entrambi? In ogni caso, "è improbabile che questa domanda aiuti i futuri visitatori".

— Kaz,

5

Il metodo di änthräX è molto utile. Per me funziona!

Fondamentalmente penso che, dopo aver installato ssh, siano necessari file chiave.

L'unica revisione che ho fatto è stata utilizzare rsainvece di rsa1:

ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key 
ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key

Quel metodo modificato ha funzionato per me.

— Alan_04
fonte

Questo è stato il problema nel mio caso. Il pacchetto server ssh con l'attuale versione di Ubuntu per la macchina ARM Utilite installata con il sintomo dell'OP. Dopo aver eseguito questi due comandi (che ho fatto come root), posso finalmente entrare. Grazie mille. +1

— James T Snell

1

È perché in qualche modo le autorizzazioni dei file all'interno /etc/sshsono cambiate ... Quindi modifica le autorizzazioni dei file come nell'esempio riportato di seguito:

uso:

chmod 644 ssh_config
chmod 600 moduli

e così via...

Infine, i permessi dei file dovrebbero apparire come qualcosa di seguito,

[root@hostname ssh]# ls -latr
total 172

-rw-r--r--.   1 root root   2047 Aug 12  2010 ssh_config
-rw-------.   1 root root 125811 Aug 12  2010 moduli
-rw-------.   1 root root    963 Mar  1 16:02 ssh_host_key
-rw-r--r--.   1 root root    627 Mar  1 16:02 ssh_host_key.pub
-rw-r--r--.   1 root root    382 Mar  1 16:02 ssh_host_rsa_key.pub
-rw-------.   1 root root   1675 Mar  1 16:02 ssh_host_rsa_key
-rw-r--r--.   1 root root    590 Mar  1 16:02 ssh_host_dsa_key.pub
-rw-------.   1 root root    668 Mar  1 16:02 ssh_host_dsa_key
-rw-------.   1 root root   3845 May  7 11:52 sshd_config

Dopo aver modificato le autorizzazioni, prova a connetterti da Putty, dovrebbe funzionare correttamente.

— Varun Joseph
fonte

1

Perché Putty è rilevante? E considera di chiedere all'OP quali sono le autorizzazioni sui file prima di avvisare che le modifica.

— Clive van Hilten,

Estremamente dispiaciuto per aver pubblicato la risposta in modo errato. Ora ecco la cosa, durante l'installazione di un'app qualcuno ha cambiato le autorizzazioni di questi file in 777. Questo l'ho capito mentre passavo attraverso / var / log / messages (connessione seriale al macchina). Quindi ha cambiato i permessi e indovina un po '? dopo ha funzionato bene.

— Varun Joseph,

1

Abbiamo avuto un problema simile, ma si è verificato solo durante la registrazione da Ubuntu a Solaris. Assicurati che tutte queste linee siano presenti /etc/ssh/ssh_config nell'host Ubuntu risolto il problema (dovresti trovare alcune di queste linee già presenti):

Host *
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
HostKeyAlgorithms ssh-rsa,ssh-dss
MACs hmac-md5,hmac-sha1,hmac-ripemd160

Nel caso di Xubuntu avevo bisogno solo degli ultimi due.

— Philip Kearns
fonte

0

Questo messaggio può anche derivare da più tentativi di attacchi ssh. Se visualizzi questo messaggio nei tuoi registri, una fonte dannosa potrebbe tentare di immetterti nel tuo computer utilizzando i tentativi di password con forza bruta.

Per rallentare i tentativi, installare il pacchetto "fail2ban":

sudo apt-get install fail2ban

Dalla pagina wiki di fail2ban :

Fail2ban esegue la scansione dei file di registro (ad es. / Var / log / apache / error_log) e vieta gli IP che mostrano segni dannosi - troppi errori di password, ricerca di exploit, ecc. Generalmente Fail2Ban viene quindi utilizzato per aggiornare le regole del firewall per rifiutare gli indirizzi IP per un periodo di tempo specificato

— Liloulinx
fonte

1

Spiega la tua risposta con maggiori dettagli sul perché questo dovrebbe funzionare

— DnrDevil,