Errore di connessione SSH: ssh_exchange_identification: read: connessione reimpostata dal peer


25

Quando ho provato a connettermi al server tramite SSH, viene visualizzato il seguente errore,

[root@oneeighty ~]# ssh -vvv -p 443 root@xxx.xxx.xxx
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to xxx.xxx.xxx [IP] port 443.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: loaded 3 keys
ssh_exchange_identification: read: Connection reset by peer

Ho verificato la configurazione SSH su server e client e non ci sono problemi.

Riavviato il servizio SSH sul server e quindi riavviato il server / client, ma i problemi non sono stati risolti.


Puoi consentire la connessione ssh tramite l'interfaccia utente del firewall (alcuni provider lo consentono) o Se hai un metodo alternativo per accedere (es. Digitalocean fornisce un pulsante console) puoi eseguire sotto il comando sudo ufw consentire ssh sudo ufw consentire 22
BSB

Risposte:


26

Questo può essere il risultato di un numero di cose.

Poche cose che puoi provare rapidamente sono le seguenti,

  • Cerca in /etc/hosts.deny qualsiasi voce simile sshd: ALL
  • Forse, aggiungi sshd: ALLa/etc/hosts.allow

  • È possibile che gli HostKey del tuo SSHD siano corrotti. Sono presenti nella directory / etc / ssh /. È possibile eliminarli e riavviare sshd e questi dovranno rigenerarli. Nel caso in cui dia un errore, si prega di utilizzare i seguenti comandi

    $ ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
    $ ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key
    $ ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key
    $ /etc/init.d/sshd start
    

sul file /etc/hosts.deny e /etc/hosts.allow, tutte le righe sono commentate.
Senthil G,

1
Aggiungi sshd: ALLa hosts.deny per verificare se ciò aiuta.
vagarwal

2

La riga successiva nel debug dovrebbe apparire come:

debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3p1 Debian-3ubuntu7

Hai confermato su StackOverflow che stai utilizzando NATing / port forwarding da un indirizzo IP esterno. Hai anche verificato che puoi ssh dalla casella locale a se stesso. Poiché lo smistamento locale sulla porta 443 funziona, è necessario verificare che la mappatura delle porte funzioni.

Provare:

  1. SSH da un'altra casella nella stessa sottorete
  2. Eseguire iptables -Le verificare che la porta 443 sia aperta o INPUT e OUTPUT sia impostato su ACCEPT
  3. Esegui tcpdump -A -s 0 port 443e quindi prova a scaricare l'IP esterno. Dovresti vedere arrivare i dati con l'indirizzo di origine del router

2

FWIW, sto eseguendo Ubuntu 14.04 su AWS. Il problema è stato risolto da SSHing tramite il proprio client Web Java e funzionante sudo service apache2 start. Volevo solo eseguire il backup del mio sito Web, ma ha anche risolto l'accesso SSH. Non ho idea del perché, ma non mi lamento.


stesso problema qui. la mia sessione non rispondeva senza motivo e non riuscivo a riconnettermi tramite stucco. l'utilizzo del client Web ha fatto tutto il necessario per consentire alla mia connessione tramite putty di funzionare di nuovo.
AndrewK,

Grazie, non so come, ma mi ha davvero aiutato. *** aws
Siarhey Uchukhlebau

1

Controlla gli host consentiti sul server a cui stai tentando di connetterti, anche tutte le regole di iptables in esecuzione.


1

Il problema è stato risolto.
Il problema è nei bilanciatori di carico che abbiamo sulla nostra rete. Il problema è stato risolto al riavvio dei bilanciatori di carico.


1

Ho affrontato un problema simile oggi poiché all'improvviso l'accesso ssh a una VM è stato negato con lo stesso messaggio. ssh -v (sul client) e sshd -d (sul server) non hanno aiutato molto. Il problema nel mio caso è iniziato a causa della modifica delle impostazioni del firewall / iptable che ho fatto per alcune demo sull'uso dello stack LAMP.

Ho usato system-config-firewall-tui per abilitare il firewall e da lì ho selezionato solo httpd che ha bloccato tutti gli altri servizi tranne httpd.

Quindi, come soluzione a questo, aggiungi le autorizzazioni a sshd da

  • aggiornamento delle impostazioni di configurazione iptable OPPURE
  • Selezionando sshd da system-config-firewall-tui OR
  • Disabilitazione firewall OR
  • Arresta il servizio iptable (rhel6, rimuovilo anche da chkconfig) il servizio iptables si ferma

ssh funziona perfettamente bene ora !!!


0

Per me, per consentire le connessioni sshd nel file / etc / hosts.

vi /etc/hosts.allow
and add 

sshd: ALL

0

Il modo in cui ho risolto il problema è che sono andato al computer host ed ho eseguito alcuni comandi

sudo mkdir / var / run / sshd

sudo chmod 755 -R / var / run / sshd

sudo service ssh restart

Dopo mi sono collegato alla macchina.


-3

Prima eliminazione openssh- * (openssh-server e openssh-client)

apt-get --purge remove openssh-*

rimozione della directory /home/username/.ssh

rm -rf /home/username/.ssh 

quindi installa openssh-server e openssh-client

apt-get install openssh-server openssh-client

3
No, nemmeno vicino, la risposta del PO dice quale fosse il problema. La tua risposta è specifica per le distro che usano apt, l'OP stava usando RHEL. Rimuovere e reinstallare un pacchetto non è quasi mai la soluzione.
user9517 supporta GoFundMonica il

Hai fatto tutto questo sul server locale o remoto?
Jonathan,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.