Connessione ripristinata dal peer usando sshfs

32

Sto usando un innesto fuse / sshfs che ha funzionato bene finora. Ora ho dovuto reinstallare il sistema server e improvvisamente ottenere il classico read: Connection reset by peererrore. Sto utilizzando l'autenticazione con chiave pubblica e ho copiato la mia chiave sul sistema appena installato. Il normale login ssh funziona bene. Ho modificato il log in debug ma purtroppo questo non mi dà alcuna informazione utile:

sshd[2077]: debug1: Forked child 2198.
sshd[2198]: Set /proc/self/oom_score_adj to 0
sshd[2198]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
sshd[2198]: debug1: inetd sockets after dupping: 3, 3
sshd[2198]: Connection from 192.168.1.6 port 47991
sshd[2198]: debug1: Client protocol version 2.0; client software version OpenSSH_6.1p1 Debian-4
sshd[2198]: debug1: match: OpenSSH_6.1p1 Debian-4 pat OpenSSH*
sshd[2198]: debug1: Enabling compatibility mode for protocol 2.0
sshd[2198]: debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
sshd[2198]: debug1: permanently_set_uid: 103/65534 [preauth]
sshd[2198]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
sshd[2198]: debug1: SSH2_MSG_KEXINIT sent [preauth]
sshd[2198]: debug1: SSH2_MSG_KEXINIT received [preauth]
sshd[2198]: debug1: kex: client->server aes128-ctr hmac-md5 none [preauth]
sshd[2198]: debug1: kex: server->client aes128-ctr hmac-md5 none [preauth]
sshd[2198]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
sshd[2198]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
sshd[2198]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
sshd[2198]: Connection closed by 192.168.1.6 [preauth]
sshd[2198]: debug1: do_cleanup [preauth]
sshd[2198]: debug1: monitor_read_log: child log fd closed
sshd[2198]: debug1: do_cleanup
sshd[2198]: debug1: Killing privsep child 2199

Qualcuno ha un'idea di ciò che mi manca qui?

AGGIORNARE

Il auth.logcon livello di debug 3:

sshd[2455]: debug3: fd 5 is not O_NONBLOCK
sshd[2455]: debug1: Forked child 2456.
sshd[2455]: debug3: send_rexec_state: entering fd = 8 config len 751
sshd[2455]: debug3: ssh_msg_send: type 0
sshd[2455]: debug3: send_rexec_state: done
sshd[2456]: debug3: oom_adjust_restore
sshd[2456]: Set /proc/self/oom_score_adj to 0
sshd[2456]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
sshd[2456]: debug1: inetd sockets after dupping: 3, 3
sshd[2456]: Connection from 192.168.1.6 port 50037
sshd[2456]: debug1: Client protocol version 2.0; client software version OpenSSH_6.1p1 Debian-4
sshd[2456]: debug1: match: OpenSSH_6.1p1 Debian-4 pat OpenSSH*
sshd[2456]: debug1: Enabling compatibility mode for protocol 2.0
sshd[2456]: debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
sshd[2456]: debug2: fd 3 setting O_NONBLOCK
sshd[2456]: debug2: Network child is on pid 2457
sshd[2456]: debug3: preauth child monitor started
sshd[2456]: debug3: privsep user:group 103:65534 [preauth]
sshd[2456]: debug1: permanently_set_uid: 103/65534 [preauth]
sshd[2456]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
sshd[2456]: debug1: SSH2_MSG_KEXINIT sent [preauth]
sshd[2456]: debug1: SSH2_MSG_KEXINIT received [preauth]
sshd[2456]: debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se [preauth]
sshd[2456]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth]
sshd[2456]: debug2: kex_parse_kexinit:  [preauth]
sshd[2456]: debug2: kex_parse_kexinit:  [preauth]
sshd[2456]: debug2: kex_parse_kexinit: first_kex_follows 0  [preauth]
sshd[2456]: debug2: kex_parse_kexinit: reserved 0  [preauth]
sshd[2456]: debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss [preauth]
sshd[2456]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se [preauth]
sshd[2456]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib [preauth]
sshd[2456]: debug2: kex_parse_kexinit:  [preauth]
sshd[2456]: debug2: kex_parse_kexinit:  [preauth]
sshd[2456]: debug2: kex_parse_kexinit: first_kex_follows 0  [preauth]
sshd[2456]: debug2: kex_parse_kexinit: reserved 0  [preauth]
sshd[2456]: debug2: mac_setup: found hmac-md5 [preauth]
sshd[2456]: debug1: kex: client->server aes128-ctr hmac-md5 none [preauth]
sshd[2456]: debug2: mac_setup: found hmac-md5 [preauth]
sshd[2456]: debug1: kex: server->client aes128-ctr hmac-md5 none [preauth]
sshd[2456]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
sshd[2456]: debug3: mm_key_sign entering [preauth]
sshd[2456]: debug3: mm_request_send entering: type 5 [preauth]
sshd[2456]: debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth]
sshd[2456]: debug3: mm_request_receive_expect entering: type 6 [preauth]
sshd[2456]: debug3: mm_request_receive entering [preauth]
sshd[2456]: debug3: mm_request_receive entering
sshd[2456]: debug3: monitor_read: checking request 5
sshd[2456]: debug3: mm_answer_sign
sshd[2456]: debug3: mm_answer_sign: signature 0x7f9b687c7680(100)
sshd[2456]: debug3: mm_request_send entering: type 6
sshd[2456]: debug2: monitor_read: 5 used once, disabling now
sshd[2456]: debug2: kex_derive_keys [preauth]
sshd[2456]: debug2: set_newkeys: mode 1 [preauth]
sshd[2456]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
sshd[2456]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
sshd[2456]: Connection closed by 192.168.1.6 [preauth]
sshd[2456]: debug1: do_cleanup [preauth]
sshd[2456]: debug3: PAM: sshpam_thread_cleanup entering [preauth]
sshd[2456]: debug1: monitor_read_log: child log fd closed
sshd[2456]: debug3: mm_request_receive entering
sshd[2456]: debug1: do_cleanup
sshd[2456]: debug3: PAM: sshpam_thread_cleanup entering
sshd[2456]: debug1: Killing privsep child 2457

AGGIORNARE

Ho provato un sshfsmontaggio manuale e ottengo anche read: Connection reset by peer. Ho quindi aggiunto le opzioni di debug e ho anche ottenuto Permission denied (publickey).. Questo è strano poiché la chiave pubblica è presente e funziona bene altrimenti. Uso anche il mio utente per la connessione ssh e specifica manualmente il file della chiave privata. Potrebbe trattarsi di un problema con l'account root che non è in grado di accedere alla chiave pubblica corretta sul server da qualche parte? Sto eseguendo

sudo sshfs myuser@myserver:/mnt/foo /mnt/foo -o IdentityFile=/home/myuser/.ssh/id_rsa

e la relativa parte del registro è

debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/myuser/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).
read: Connection reset by peer

ssh sshfs

— André Stannek
fonte

1

L'output appare esattamente come quello di una sessione ssh che si rifiuta di connettersi a causa della mancata corrispondenza dell'impronta digitale della chiave del server (o di una chiave sconosciuta). Il sftpserver funziona correttamente?

— peterph,

Ho provato sftp sia con Nautilus ( Connect to Server...opzione) che con Filezilla. Funziona bene Sebbene Filezilla mi abbia chiesto di una chiave host sconosciuta.

— André Stannek,

Prova sftpdirettamente - questo è quello che usa SSHFS.

— peterph,

4

Mi sembra lo stesso. Hai provato a ottenere alcune informazioni di debug dal client? sshfs -odebug,sshfs_debug,loglevel=debug ...potrebbe fare il trucco (tratto da sourceforge.net/apps/mediawiki/fuse/index.php?title=SshfsFaq ).

— peterph,

1

@peterph ha già avuto questa idea ;-) Vedi il mio secondo aggiornamento. Ho appena omesso i parametri di debug nel comando pubblicato qui, ma l'ho eseguito con essi.

— André Stannek,

21

Stavo usando l' -F /path/to/configopzione. La risposta era nel mio file di configurazione dove avevo

IdentityFile ~/.ssh/id_rsa

che non ha funzionato. È richiesto il percorso assoluto:

IdentityFile /home/user/.ssh/id_rsa

— Sanchke Dellowar
fonte

man ssh-configconsente esplicitamente tilde perIdentityFile

— CharlesB

4

@CharlesB L'ho provato in entrambi i modi e ti assicuro che la mia risposta è valida. E vedo a cosa ti riferisci nelle pagine man. Forse è un bug quando si esegue con sudo? (perché lo sono)

— Sanchke Dellowar,

7

certo, se stai eseguendo sshfs con sudo, tilde è la casa dell'utente root. quindi è necessario specificare il percorso assoluto.

— Charles B

1

Anche se usi percorsi assoluti nel tuo ~/.ssh/configfile, in esecuzione sudo sshfsleggerà per impostazione predefinita il /root/.ssh/configfile root (se presente). È necessario passare il percorso esplicito al file di configurazione tramite -F.

— Dan Dascalescu il

14

Dopo molte più prove, risulta che il mio utente client non era nel fusegruppo. Dopo averlo aggiunto con sudo usermod -a -G fuse myuseril supporto funziona di nuovo bene. Non chiedermi come avrebbe potuto funzionare prima di reinstallare il server. Grazie per tutto il tuo aiuto!

— André Stannek
fonte

2

è questo l'utente sul file system locale o remoto?

— Woodrow Barlow

1

@WoodrowBarlow a dire il vero non lo so più: D La mia ipotesi migliore sarebbe locale, poiché è qui che usi la miccia.

— André Stannek il

oppuregpasswd --add USER fuse

— deceleratedcaviar

Nel mio caso, avevo semplicemente bisogno del numero di porta. Questo è stato aggiunto con l' -popzione.

— Paradox

11

Poiché questo messaggio di errore è quello predefinito quando la connessione ssh non riesce, la risposta più generica (per commento di @peterph) è investigare utilizzando almeno -odebug:

sshfs -odebug,sshfs_debug,loglevel=debug ...

per esempio

sshfs -odebug,sshfs_debug,loglevel=debug -o Ciphers=arcfour -o Compression=no -o allow_root -o transform_symlinks localhost:/ /mnt/your_mount_point

Come detto altrove, le cause comuni includono mancante allow_otherin fuse.confo manca fusel'appartenenza al gruppo (anche se questo potrebbe non essere più necessario su Ubuntu 18.04?)

Nel mio caso questo ha stampato:

SSHFS version 2.8 FUSE library version: 2.9.7 nullpath_ok: 0 nopath: 0 utime_omit_ok: 0 executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-ologlevel=debug> <-oIdentityFile=~/.ssh/id_rsa> <-oCiphers=arcfour> <-oCompression=no> <-2> <localhost> <-s> <sftp> command-line line 0: Bad SSH2 cipher spec 'arcfour'. read: Connection reset by peer

... indicando un'opzione Cipher non supportata (lavorando su fedora ma non su Ubuntu)

— eddygeek
fonte

Usando -o debug, ho ottenuto la riga di comando 0: specifica di cifratura SSH2 errata 'arcfour'.

— Salathiel Genèse,

8

Ho avuto lo stesso problema oggi. sshla connessione è OK, sshfsnon lo è. Il mio server SSH è Qnap NAS (TS-228).

Il problema è stato risolto abilitando SFTP sul dispositivo NAS.

Altre impostazioni sono apparse in sshd_config:

Subsystem sftp /usr/libexec/sftp-server

— Geom
fonte

1

Quella soluzione non funziona per me. Quindi apprezzo avere qualcos'altro da provare.

— Demented Hedgehog

L'abilitazione di SFTP sul mio Synology NAS ha risolto anche l'errore per me. MA il contenuto visualizzato nella cartella montata non è lo stesso del collegamento diretto tramite ssh. Mancano le cartelle e non è possibile accedere alla radice. Bummer.

— Heinrich Ulbricht,

5

Ho riscontrato che il mio problema, che era simile, riguardava il file di configurazione dei fusibili in:

/etc/fuse.conf

Ho dovuto annullare il commento:

user_allow_other

— cennings
fonte

5

Nel caso in cui qualcuno si imbattesse in questo thread: ho avuto questo read: Connection reset by peererrore perché il nome host non era risolvibile (non stavo usando un host completo). L'uso del nome host corretto ha risolto il problema: il messaggio di errore è quindi completamente fuorviante.

Un buon test è quello di inviare ssh alla macchina prima di eseguire il comando sshfs, se neanche questo funziona sshfs non funzionerà.

— Bob Lauer
fonte

sshfs server-ssh-alias: / some / dir / mnt non ha funzionato per me, ma sshfs real.servername.org:/some/dir / mnt ha funzionato per me. (combinato con user_allow_other)

— Brian C.

2

Ho riscontrato questo errore, ho provato i metodi precedenti e non sono riuscito a farlo funzionare.

Il problema era che il server non accettava ssh sulla porta 22. Ho usato:

$sshfs -p 2222 user@server:/path/to/folder ~/local/path

e ha risolto il problema.

— Arashr
fonte

1

Per favore, non sottovalutare senza dire perché. Questa è una cosa ragionevole da verificare.

— Demented Hedgehog

2

Il mio errore era sul lato server. Il sottosistema sftp per sshd è apparentemente predefinito non disponibile su centos 7.6.xx più recenti. risolto rimuovendo "#" da davanti al seguente in / etc / ssh / sshd_config

Subsystem sftp /usr/libexec/openssh/sftp-server

grazie a eddygeek per la ricetta -odebug per aiutare a trovare questo problema. Come sopra GEOM ma non specifico per Qnap.

— J.Bravo
fonte

2

Ho riscontrato lo stesso errore durante l'esecuzione sudo sshfs [...] myhost: /mnt/myhost, dove myhostè definito nei miei ~/.ssh/configfile.

Il problema è che l'esecuzione sudo sshfsnon ha cercato nella mia directory home ~/.ssh/config, ma in roots. La soluzione era passare esplicitamente il file di configurazione tramite -F:

sudo sshfs -F /home/dandv/.ssh/config [...] myhost: /mnt/myhost

— Dan Dascalescu
fonte

1

Ho cancellato l'impronta digitale dell'host da /home/user/.ssh/known_hosts (effettivamente eliminato l'intero file) e l'ho risolto ... perché l'impronta digitale era cambiata. l'uso di ssh per connettersi all'host ha dato una chiara ragione del perché non si stava connettendo.

— mdxe
fonte

1

Per coloro che cercano una soluzione molto semplice: dopo aver eseguito sshfs in modalità debug, ho scoperto che la mia connessione era interrotta.

Attiva la modalità dettagliata con switch:

-o debug

— sandoval31
fonte

1

Ho avuto un problema simile e quando ho controllato la configurazione della rete, il sistema ha perso in qualche modo l'indirizzo del gateway. Quindi ho eseguito il comando seguente

route aggiungi gw 192.169.0.254 predefinito

e quindi riavvia il sistema.

Il problema è stato risolto dopo il riavvio.

— frastagliare
fonte

2

Hai "reset connessione da peer" con un gateway non valido?!?

— Jeff Schaller

1

Nel mio caso, l'interfaccia del server non si è accesa dopo molto tempo all'avvio. Il server è collegato a una porta dello switch Cisco con modalità trunk. Poiché qualsiasi porta trunk eseguirà vari controlli prima di diventare effettivamente UP (in genere più di 30 secondi), ciò ha comportato il messaggio di errore di reimpostazione della connessione sopra riportato.

La mia soluzione era cambiare la porta dello switch in modalità di accesso con spanning-tree portfast , poiché nel mio ambiente la modalità trunk non è necessaria per questo server.

Ho anche scoperto questo problema usando il parametro di debug su sshfs.

— afardana
fonte