Strano problema: connessione ripristinata dal peer


10

Sto riscontrando dei problemi con SSH sul mio server Linux con CentOS. Posso connettermi bene al mio server usando PuTTY o ssh da Windows cmd. Lo stesso vale per l'utilizzo di FTP sicuro. Posso collegarmi al server, ottenere un elenco di file e tutto è a posto. Il problema si verifica quando provo a inviare qualsiasi quantità di dati attraverso la rete.

Ogni volta che tento di trasferire qualcosa oltre una determinata soglia, la connessione non riesce e viene visualizzato il messaggio "Connessione reimpostata dal peer". Ho un file sql che è di circa 3 MB nella mia directory home. Se provo a FTP, inizierà il trasferimento e morirà dopo che sono stati trasferiti circa 48k. Quindi avvierà una nuova connessione e trasferirà un altro 48k. Se utilizzo PuTTY e apro una sessione, posso collegarmi e accedere correttamente. Se provo di cat file.sqlnuovo, la connessione viene interrotta e viene visualizzato il messaggio "Connessione ripristinata dal peer". Passare dalla mia workstation locale al server è la stessa situazione. Ho un bel po 'di codice sorgente che devo impegnare nel mio repository svn ospitato sul server, ma appare lo stesso messaggio "Connessione reimpostata dal peer".

So che il problema si trova sulla mia workstation locale perché posso usare il macbook e ssh di mia moglie sul server senza problemi. Posso ssh nel box Linux di un amico (usando la stessa installazione putty) e sftp sul mio server dal loro e scaricare il file, aprire un'altra sessione ssh dal suo box sul mio server e catalogare il file. Quindi, qualcosa sta succedendo, ma non sono sicuro di cosa. Qualcuno ha qualche idea?

Aggiornare

Ho cercato di capirlo un po 'di più, e sembra che ci sia un limite rigido alla quantità di dati che posso trasferire in una singola sessione SSH. Se lo faccio immediatamente, cat file.sqlma posso anche continuare a digitare ls -lun numero consistente di volte e visualizzerò anche il messaggio "Connessione reimpostata dal peer". Ho provato:

  • generare nuove chiavi ssh
  • riavvio del mio router
  • riavviare il mio computer
  • riavvio del server remoto

Ho scritto un tcpdump sul server remoto, ma non capisco il TCP a un livello così dettagliato che per me ha molto senso. Ho attivato il debug in ssh ed ecco la parte del registro che porta alla reimpostazione della connessione:

Jul 24 23:10:56 server sshd[4507]: debug1: permanently_set_uid: 500/503
Jul 24 23:10:56 server sshd[4507]: debug1: Entering interactive session for SSH2.
Jul 24 23:10:56 server sshd[4507]: debug1: server_init_dispatch_20
Jul 24 23:10:56 server sshd[4507]: debug1: server_input_channel_open: ctype session rchan 256 win 16384 max 16384
Jul 24 23:10:56 server sshd[4507]: debug1: input_session_request
Jul 24 23:10:56 server sshd[4507]: debug1: channel 0: new [server-session]
Jul 24 23:10:56 server sshd[4507]: debug1: session_new: init
Jul 24 23:10:56 server sshd[4507]: debug1: session_new: session 0
Jul 24 23:10:56 server sshd[4507]: debug1: session_open: channel 0
Jul 24 23:10:56 server sshd[4507]: debug1: session_open: session 0: link with channel 0
Jul 24 23:10:56 server sshd[4507]: debug1: server_input_channel_open: confirm session
Jul 24 23:10:56 server sshd[4507]: debug1: server_input_channel_req: channel 0 request pty-req reply 1
Jul 24 23:10:56 server sshd[4507]: debug1: session_by_channel: session 0 channel 0
Jul 24 23:10:56 server sshd[4507]: debug1: session_input_channel_req: session 0 req pty-req
Jul 24 23:10:56 server sshd[4507]: debug1: Allocating pty.
Jul 24 23:10:56 server sshd[4505]: debug1: session_new: init
Jul 24 23:10:56 server sshd[4505]: debug1: session_new: session 0
Jul 24 23:10:56 server sshd[4507]: debug1: session_pty_req: session 0 alloc /dev/pts/2
Jul 24 23:10:56 server sshd[4507]: debug1: server_input_channel_req: channel 0 request shell reply 1
Jul 24 23:10:56 server sshd[4507]: debug1: session_by_channel: session 0 channel 0
Jul 24 23:10:56 server sshd[4507]: debug1: session_input_channel_req: session 0 req shell
Jul 24 23:10:56 server sshd[4508]: debug1: Setting controlling tty using TIOCSCTTY.
Jul 24 23:10:59 server sshd[4507]: Read error from remote host <my-ip>: Connection reset by peer
Jul 24 23:10:59 server sshd[4507]: debug1: do_cleanup
Jul 24 23:10:59 server sshd[4505]: debug1: do_cleanup
Jul 24 23:10:59 server sshd[4505]: debug1: PAM: cleanup
Jul 24 23:10:59 server sshd[4505]: debug1: PAM: deleting credentials
Jul 24 23:10:59 server sshd[4505]: debug1: PAM: closing session
Jul 24 23:10:59 server sshd[4505]: pam_unix(sshd:session): session closed for user <me>
Jul 24 23:10:59 server sshd[4505]: debug1: session_pty_cleanup: session 0 release /dev/pts/2

AGGIORNAMENTO 2:

Circa una settimana fa, ho modificato le mie impostazioni ssh sul mio server usando questo post wiki: http://wiki.centos.org/HowTos/Network/SecuringSSH

Poiché occasionalmente ho bisogno di accedere al mio server dal lavoro e poiché la porta 21 è aperta sul nostro firewall, ho cambiato la porta ssh a 21. Per diagnosticare ulteriormente questo problema, ho provato a ripristinare le mie impostazioni ssh e ho cambiato la porta ssh a 22 Basso ed ecco, non vedo l'errore quando uso la porta 22. Ritorna a 21, e come un orologio quando colpisco 48k di dati trasferiti - Connessione ripristinata dal peer.

Dato che posso ottenere la connessione iniziale e che in passato non ho avuto problemi a stabilire connessioni ftp sulla porta 21, non sembra che la mia configurazione del firewall sia il problema.

Almeno a questo punto, ho il problema ridotto alla porta ssh sul mio server. Capovolgilo su 21 e problemi istantanei, ripristinalo su 22, nessun problema ...

Qualcuno può pensare al perché la porta di ascolto farebbe la differenza? Ancora una volta, è solo sulla mia scatola di Windows XP che sta causando problemi. Fammi sapere se qualcuno ha qualche idea su cosa potrebbe causare questo.

Aggiornamento 2:

Ho appena ridotto il problema e io sono corretto - è un problema di firewall, ma un problema di firewall di Windows, non sul mio router. Se uso la porta 21 e disabilito il firewall di Windows non vedo il messaggio "Connessione reimpostata dal peer". Per rispondere alla domanda ovvia, sì, la porta 21 è aperta sul firewall di Windows.

Dato che questo computer è protetto dal firewall del mio router, per ora posso disabilitarlo, ma sarei interessato a capire cosa sta succedendo qui.


+1 Vedo lo stesso problema qui su un PC Windows 7 che tenta di connettersi a un server SSH sulla porta 21. La connessione va bene per l'accesso alla shell fino a quando non inizio a utilizzare il tunnel sulla stessa connessione per trasferire più dati. La risposta di Alessandro qui sotto l'ha risolta per me.
Wim Coenen,

Risposte:


10

Puoi risolvere usando la riga di comando con questo comando (digita questo come amministratore):

netsh advfirewall set global statefulftp disable


+1 questo risolto per me. Per chiarezza: questo comando deve essere eseguito sul PC Windows.
Wim Coenen,

Eccellente, ho avuto questo esatto problema da qualche tempo. Tutti relativi al firewall di Windows 7. Sia con Putty SSH su 21 sia con connessioni NXclient (nxshh) su 21. netsh advfirewall imposta global statefulftp disabilita Ciò consente alla mia connessione nxclient ora di connettersi e completare la connessione in modo da vedere il desktop.

1

Ciò potrebbe essere correlato al tuo router che prova a gestire automaticamente il tracciamento della connessione NAT FTP. Succederebbe solo sulla porta 21, non 22. Dai un'occhiata a http://www.faqs.org/docs/iptables/complexprotocols.html


Grazie, darò un'occhiata all'articolo e vedrò se fa luce su ciò che sta succedendo.
proflux,

Ricardo sembra essere corretto. Vedi la discussione su winscp.net/forum/viewtopic.php?t=9360 . Mi chiedo se c'è qualcosa di sfruttabile in qualunque problema questo si inneschi in ip_conntrack_ *
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.