Verbindung von Peer mit sshfs zurückgesetzt

32

Ich verwende eine Sicherung / sshfs Einfassung, die bis jetzt fein arbeitete. Jetzt musste ich das Serversystem neu installieren und bekam plötzlich den klassischen read: Connection reset by peerFehler. Ich verwende die Authentifizierung mit öffentlichem Schlüssel und habe meinen Schlüssel auf das neu installierte System kopiert. Normaler SSH-Login funktioniert einwandfrei. Ich habe das Protokoll geändert, um Fehler zu beheben, aber leider gibt mir dies keine nützlichen Informationen:

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

Hat jemand eine Idee was mir hier fehlt?

AKTUALISIEREN

Das auth.logmit Debug Level 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,[email protected] [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,[email protected] [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,[email protected] [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,[email protected] [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: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],[email protected],[email protected],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,[email protected] [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,[email protected] [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,[email protected],zlib [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,[email protected],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

AKTUALISIEREN

Ich habe versucht, eine manuelle sshfsHalterung und ich bekomme auch read: Connection reset by peer. Ich habe dann die Debug-Optionen hinzugefügt und auch bekommen Permission denied (publickey).. Dies ist seltsam, da der öffentliche Schlüssel vorhanden ist und ansonsten einwandfrei funktioniert. Ich verwende meinen Benutzer auch für die ssh-Verbindung und gebe die private Schlüsseldatei manuell an. Könnte dies ein Problem sein, bei dem das Root-Konto nicht in der Lage ist, irgendwo auf den richtigen öffentlichen Schlüssel auf dem Server zuzugreifen? Ich führe aus

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

und der relevante Protokollteil ist

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
quelle
1
Die Ausgabe sieht genauso aus wie in einer SSH-Sitzung, bei der die Verbindung aufgrund einer Nichtübereinstimmung der Fingerabdrücke des Serverschlüssels (oder eines unbekannten Schlüssels) nicht hergestellt werden kann. Funktioniert sftpder Server korrekt?
Peterph
Ich habe sftp sowohl mit Nautilus ( Connect to Server...Option) als auch mit Filezilla ausprobiert. Es funktioniert gut. Obwohl Filezilla mich nach einem unbekannten Hostschlüssel fragte.
André Stannek
Versuchen Sie sftpdirekt - das ist , was sshfs Anwendungen.
Peterph
4
Sieht für mich genauso aus. Haben Sie versucht, Debugging-Informationen vom Client abzurufen? sshfs -odebug,sshfs_debug,loglevel=debug ...könnte den Trick machen (entnommen aus sourceforge.net/apps/mediawiki/fuse/index.php?title=SshfsFaq ).
Peterph
1
@peterph hatte schon diese Idee ;-) Siehe mein zweites Update. Ich habe nur die Debug-Parameter in dem hier veröffentlichten Befehl weggelassen, aber ich habe es mit ihnen ausgeführt.
André Stannek

Antworten:

21

Ich habe die -F /path/to/configOption genutzt. Die Antwort war in meiner Konfigurationsdatei, wo ich hatte

IdentityFile ~/.ssh/id_rsa

was nicht funktioniert hat. Der absolute Pfad ist erforderlich:

IdentityFile /home/user/.ssh/id_rsa
Sanchke Dellowar
quelle
man ssh-configerlaubt ausdrücklich Tilde fürIdentityFile
CharlesB
4
@CharlesB Ich habe es auf beide Arten getestet und versichere Ihnen, dass meine Antwort gültig ist. Und ich sehe, worauf Sie in den Manpages verweisen. Vielleicht ist es ein Fehler beim Laufen mit sudo? (weil ich bin)
Sanchke Dellowar
7
Wenn Sie sshfs mit sudo ausführen, ist Tilde die Heimat des Root-Benutzers. Dann müssen Sie den absoluten Pfad angeben.
CharlesB
1
Selbst wenn Sie absolute Pfade in Ihrer ~/.ssh/configDatei verwenden, sudo sshfsliest das Ausführen standardmäßig die Root- /root/.ssh/configDatei (falls vorhanden). Sie müssen den expliziten Pfad zu Ihrer Konfigurationsdatei über übergeben -F.
Dan Dascalescu
14

Nach vielen Versuchen stellte sich heraus, dass mein Client-Benutzer nicht in der fuseGruppe war. Nachdem ich es mit sudo usermod -a -G fuse myuserder Montierung hinzugefügt habe , funktioniert es wieder. Fragen Sie mich nicht, wie es hätte funktionieren können, bevor Sie den Server neu installiert haben. Vielen Dank für Ihre Hilfe!

André Stannek
quelle
2
Ist dies der Benutzer im lokalen oder fernen Dateisystem?
Woodrow Barlow
1
@WoodrowBarlow um ehrlich zu sein weiß ich nicht mehr: D Meine beste Vermutung wäre lokal, da hier die Sicherung verwendet wird.
André Stannek
odergpasswd --add USER fuse
verzögerte
In meinem Fall brauchte ich einfach die Portnummer. Dies wurde mit der -pOption hinzugefügt .
Paradox
11

Da diese Fehlermeldung die Standard-Fehlermeldung ist, wenn die SSH-Verbindung fehlschlägt, ist die allgemeinste Antwort (per @ Peterph-Kommentar) die Untersuchung mit mindestens -odebug:

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

beispielsweise

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

Wie an anderer Stelle gesagt, umfassen fehlende häufige Ursachen allow_otherin fuse.confoder fehlende fuseGruppenmitgliedschaft (obwohl das nicht mehr auf 18.04 Ubuntu benötigt werden?)

In meinem Fall ist dies gedruckt:

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

... auf eine nicht unterstützte Cipher-Option zeigen (auf Fedora aber nicht Ubuntu)

eddygeek
quelle
Unter Verwendung von habe -o debugich die Befehlszeile 0: Ungültige SSH2-Verschlüsselungsspezifikation 'arcfour' erhalten.
Salathiel Genèse
8

Ich hatte heute das gleiche Problem. sshVerbindung ist in Ordnung, sshfsist nicht. Mein SSH-Server ist Qnap NAS (TS-228).

Das Problem wurde behoben, indem SFTP auf dem NAS-Gerät aktiviert wurde .

Zusätzliche Einstellung erschien in sshd_config:

Subsystem sftp /usr/libexec/sftp-server
Geom
quelle
1
Diese Lösung funktioniert bei mir nicht. Deshalb schätze ich es, etwas anderes zum Ausprobieren zu haben.
Demented Hedgehog
Durch Aktivieren von SFTP auf meinem Synology NAS wurde der Fehler auch für mich behoben. ABER der Inhalt, der im gemounteten Ordner angezeigt wird, ist nicht derselbe wie beim direkten Verbinden über ssh. Ordner fehlen und auf den Stamm kann nicht zugegriffen werden. Schade.
Heinrich Ulbricht,
5

Ich fand mein Problem, das ähnlich war, hatte mit der Sicherungskonfigurationsdatei zu tun:

/etc/fuse.conf

Ich musste Folgendes entkommentieren:

user_allow_other
Cennings
quelle
5

Nur für den Fall, dass jemand über diesen Thread stolpert: Ich hatte diesen read: Connection reset by peerFehler, weil der Hostname nicht auflösbar war (ich habe keinen vollqualifizierten Host verwendet). Die Verwendung des richtigen Hostnamens löste das Problem - die Fehlermeldung ist dann einfach völlig irreführend.

Ein guter Test ist es, vor dem Ausführen des Befehls sshfs auf den Computer zu ssh, wenn dies nicht funktioniert, funktioniert sshfs auch nicht.

Bob Lauer
quelle
sshfs server-ssh-alias: / some / dir / mnt hat bei mir nicht funktioniert, aber sshfs real.servername.org:/some/dir / mnt hat bei mir funktioniert. (kombiniert mit user_allow_other)
Brian C.
2

Ich habe diesen Fehler erhalten und die oben genannten Methoden ausprobiert.

Das Problem war, dass der Server ssh an Port 22 nicht akzeptierte. Ich verwendete:

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

und es löste das Problem.

Arashr
quelle
1
Bitte stimmen Sie nicht ab, ohne zu sagen warum. Dies ist eine vernünftige Sache zu überprüfen.
Demented Hedgehog
2

Mein Fehler war serverseitig. Das sftp-Subsystem für sshd ist anscheinend standardmäßig nicht auf neueren Centos 7.6.xx verfügbar. behoben durch Entfernen von "#" vor dem folgenden in / etc / ssh / sshd_config

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

danke an eddygeek für das -odebug-rezept, das dabei hilft, dieses problem zu finden. Wie GEOM oben, jedoch nicht Qnap-spezifisch.

J. Bravo
quelle
2

Habe den gleichen Fehler beim Laufen bekommen sudo sshfs [...] myhost: /mnt/myhost, wo myhostin meinen ~/.ssh/configDateien definiert ist .

Das Problem ist, dass das Laufen sudo sshfsnicht in meinem Homeverzeichnis gesucht hat ~/.ssh/config, sondern in roots. Die Lösung bestand darin, die Konfigurationsdatei explizit zu übergeben über -F:

sudo sshfs -F /home/dandv/.ssh/config [...] myhost: /mnt/myhost
Dan Dascalescu
quelle
1

Ich habe den Fingerabdruck des Hosts aus /home/user/.ssh/known_hosts gelöscht (tatsächlich die gesamte Datei gelöscht) und ihn repariert ... weil sich der Fingerabdruck geändert hat. Die Verwendung von ssh zum Herstellen einer Verbindung mit dem Host ergab einen klaren Grund, warum keine Verbindung hergestellt wurde.

mdxe
quelle
1

Für diejenigen, die nach einer sehr einfachen Lösung suchen : Nachdem ich sshfs im Debug-Modus ausgeführt habe, stellte ich fest, dass meine Verbindung unterbrochen war.

Aktivieren Sie den ausführlichen Modus mit dem Schalter:

-o debug
sandoval31
quelle
1

Ich hatte ein ähnliches Problem, und als ich die Netzwerkkonfiguration überprüft habe, hat das System die Gateway-Adresse verloren. Also habe ich den folgenden Befehl ausgeführt

route add default gw 192.169.0.254

und startete das System neu.

Das Problem ist nach dem Neustart behoben.

Jag
quelle
2
Sie haben "Verbindung von Peer zurückgesetzt" mit einem fehlerhaften Gateway?!?
Jeff Schaller
1

In meinem Fall war es die Serverschnittstelle, die nach langer Zeit beim Start nicht mehr aktiv war. Der Server ist mit einem Cisco-Switch-Port im Trunk-Modus verbunden. Da jeder Trunk-Port verschiedene Überprüfungen durchführt, bevor er tatsächlich UP wird (normalerweise länger als 30 Sekunden), hat dies zu der obigen Fehlermeldung zum Zurücksetzen der Verbindung geführt.

Meine Lösung bestand darin, den Switch-Port in den Zugriffsmodus mit zu ändern spanning-tree portfast , da in meiner Umgebung der Trunk-Modus für diesen Server nicht erforderlich ist.

Ich fand auch über dieses Problem heraus, das den debugging-Parameter zu sshfs verwendet.

Afardana
quelle