Resetowanie połączenia przez peera za pomocą sshfs

32

Używam fuse / sshfs mount, który do tej pory działał dobrze. Teraz musiałem ponownie zainstalować system serwera i nagle otrzymałem klasyczny read: Connection reset by peerbłąd. Korzystam z uwierzytelniania za pomocą klucza publicznego i skopiowałem swój klucz do nowo zainstalowanego systemu. Normalne logowanie ssh działa dobrze. Zmieniłem dziennik na debugowanie, ale niestety nie daje to żadnych użytecznych informacji:

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

Czy ktoś ma pojęcie, czego mi brakuje?

AKTUALIZACJA

Z auth.logpoziomem debugowania 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

AKTUALIZACJA

Próbowałem sshfsmontażu ręcznego, a także dostaję read: Connection reset by peer. Następnie dodałem opcje debugowania, a także dostałem Permission denied (publickey).. Jest to dziwne, ponieważ klucz publiczny jest na swoim miejscu i działa inaczej. Używam również mojego użytkownika do połączenia ssh i ręcznie określam plik klucza prywatnego. Czy może to być problem z tym, że konto root nie może uzyskać dostępu do poprawnego klucza publicznego gdzieś na serwerze? Wykonuję

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

a odpowiednią częścią dziennika jest

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
André Stannek
źródło
1
Dane wyjściowe wyglądają dokładnie tak, jak sesja ssh, która odmawia połączenia z powodu niedopasowania odcisku palca klucza serwera (lub nieznanego klucza). Czy sftpserwer działa poprawnie?
peterph
Próbowałem sftp zarówno z Nautilus ( Connect to Server...opcja), jak i Filezilla. To działa dobrze. Chociaż Filezilla zapytał mnie o nieznany klucz hosta.
André Stannek
Spróbuj sftpbezpośrednio - tego używa SSHFS.
peterph
4
Dla mnie wygląda tak samo. Czy próbowałeś uzyskać informacje o debugowaniu od klienta? sshfs -odebug,sshfs_debug,loglevel=debug ...może zrobić lewę (wzięte z sourceforge.net/apps/mediawiki/fuse/index.php?title=SshfsFaq ).
peterph
1
@peterph już wpadł na ten pomysł ;-) Zobacz moją drugą aktualizację. Właśnie pominąłem parametry debugowania w opublikowanym tutaj poleceniu, ale wykonałem je z nimi.
André Stannek

Odpowiedzi:

21

Korzystałem z -F /path/to/configopcji. Odpowiedź była w moim pliku konfiguracyjnym, w którym miałem

IdentityFile ~/.ssh/id_rsa

które nie działało. Wymagana jest ścieżka bezwzględna:

IdentityFile /home/user/.ssh/id_rsa
Sanchke Dellowar
źródło
man ssh-configwyraźnie zezwala na tyldy dlaIdentityFile
CharlesB
4
@CharlesB Przetestowałem to na dwa sposoby i zapewniam, że moja odpowiedź jest prawidłowa. I widzę, do czego się odwołujesz na stronach podręcznika. Być może jest to błąd podczas uruchamiania z sudo? (bo ja jestem)
Sanchke Dellowar
7
jasne, jeśli korzystasz z sshfs z sudo, tylda jest domem użytkownika root. następnie musisz podać ścieżkę bezwzględną.
CharlesB
1
Nawet jeśli użyjesz bezwzględnych ścieżek w swoim ~/.ssh/configpliku, uruchomione sudo sshfsdomyślnie odczyta /root/.ssh/configplik roota (jeśli istnieje). Musisz przekazać jawną ścieżkę do pliku konfiguracyjnego przez -F.
Dan Dascalescu
14

Po wielu próbach okazuje się, że mojego klienta nie było w fusegrupie. Po dodaniu go z sudo usermod -a -G fuse myusermontażem znów działa dobrze. Nie pytaj mnie, jak mogło to działać przed ponowną instalacją serwera. Dziękuję za całą pomoc!

André Stannek
źródło
2
czy to użytkownik w lokalnym lub zdalnym systemie plików?
Woodrow Barlow
1
@WoodrowBarlow, szczerze mówiąc, już nie wiem: D Moje najlepsze przypuszczenie byłoby lokalne, ponieważ tutaj używasz bezpiecznika.
André Stannek
lubgpasswd --add USER fuse
spowolniony około
W moim przypadku po prostu potrzebowałem numeru portu. Zostało to dodane z -popcją.
Paradoks
11

Ponieważ ten komunikat o błędzie jest domyślny w przypadku niepowodzenia połączenia ssh, najbardziej ogólną odpowiedzią (na komentarz @peterph) jest zbadanie przy użyciu co najmniej -odebug:

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

na przykład

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

Jak wcześniej wspomniano, najczęstsze przyczyny to brakuje allow_otherw fuse.conflub brak fuseprzynależności do grupy (mimo, że nie może być już potrzebne na Ubuntu 18.04?)

W moim przypadku wydrukowano:

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

... wskazując na nieobsługiwaną opcję szyfrowania (działa na Fedorze, ale nie na Ubuntu)

eddygeek
źródło
Za pomocą -o debugdostałem wiersz poleceń 0: Zła specyfikacja szyfru SSH2 „arcfour”.
Salathiel Genèse,
8

Miałem dzisiaj ten sam problem. sshpołączenie jest OK, sshfsnie jest. Mój serwer SSH to Qnap NAS (TS-228).

Problem został rozwiązany poprzez włączenie SFTP na urządzeniu NAS.

Dodatkowe ustawienie pojawiło się w sshd_config:

Subsystem sftp /usr/libexec/sftp-server
Geom
źródło
1
To rozwiązanie nie działa dla mnie. Doceniam więc, że mogę spróbować czegoś innego.
szalony jeż
Włączenie SFTP na moim serwerze Synology NAS również rozwiązało problem. ALE zawartość wyświetlana w zamontowanym folderze nie jest taka sama jak w przypadku bezpośredniego połączenia przez ssh. Brakuje folderów i nie można uzyskać dostępu do katalogu głównego. Bummer.
Heinrich Ulbricht
5

Mój problem, który był podobny, dotyczył pliku konfiguracyjnego bezpiecznika w:

/etc/fuse.conf

Musiałem cofnąć komentarz:

user_allow_other
cencencje
źródło
5

Na wypadek, gdyby ktoś potknął się o ten wątek: miałem ten read: Connection reset by peerbłąd, ponieważ nazwy hosta nie można było rozwiązać (nie korzystałem z w pełni kwalifikowanego hosta). Użycie właściwej nazwy hosta rozwiązało problem - komunikat o błędzie jest wtedy całkowicie mylący.

Dobrym testem jest ssh na maszynie przed uruchomieniem komendy sshfs, jeśli to nie zadziała, sshfs też nie będzie działać.

Bob Lauer
źródło
sshfs server-ssh-alias: / some / dir / mnt nie działał dla mnie, ale sshfs real.servername.org:/some/dir / mnt działał dla mnie. (w połączeniu z user_allow_other)
Brian C.
2

Wystąpił ten błąd i wypróbowałem powyższe metody, ale nie udało mi się go uruchomić.

Problem polegał na tym, że serwer nie akceptował ssh na porcie 22. Użyłem:

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

i to rozwiązało problem.

Arashr
źródło
1
Proszę nie głosować bez podania przyczyny. Jest to rozsądna rzecz do sprawdzenia.
szalony jeż
2

Mój błąd był po stronie serwera. Podsystem sftp dla sshd jest najwyraźniej domyślnie niedostępny w nowszych wersjach Centos 7.6.xx. naprawione przez usunięcie „#” przed następującymi w / etc / ssh / sshd_config

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

dzięki eddygeek za przepis na -odebug, aby pomóc w znalezieniu tego problemu. To samo co GEOM powyżej, ale nie specyficzne dla Qnap.

J.Bravo
źródło
2

Wystąpił ten sam błąd podczas działania sudo sshfs [...] myhost: /mnt/myhost, gdzie myhostjest zdefiniowany w moich ~/.ssh/configplikach.

Problem polega na tym, że uruchomienie sudo sshfsnie szukało w moim katalogu domowym ~/.ssh/config, ale w roots. Rozwiązaniem było jawne przekazanie pliku konfiguracyjnego przez -F:

sudo sshfs -F /home/dandv/.ssh/config [...] myhost: /mnt/myhost
Dan Dascalescu
źródło
1

Usunąłem odcisk palca hosta z /home/user/.ssh/known_hosts (faktycznie usunąłem cały plik) i naprawiłem go ... ponieważ odcisk palca się zmienił. użycie ssh do połączenia się z hostem podało wyraźny powód, dla którego się nie łączył.

mdxe
źródło
1

Dla tych, którzy szukają bardzo prostego rozwiązania: Po uruchomieniu sshfs w trybie debugowania stwierdziłem, że moje połączenie zostało zerwane.

Włącz tryb gadatliwy za pomocą przełącznika:

-o debug
sandoval31
źródło
1

Miałem podobny problem, a kiedy sprawdziłem konfigurację sieci, system trochę zgubił adres bramy. Uruchomiłem więc poniższe polecenie

Dodaj trasę domyślnie gw 192.169.0.254

a następnie ponownie system.

Problem został rozwiązany po ponownym uruchomieniu.

Ząbkować
źródło
2
Masz „resetowanie połączenia przez sieć równorzędną” ze złą bramą?!?
Jeff Schaller
1

W moim przypadku interfejs serwera nie działał po długim czasie uruchamiania. Serwer jest podłączony do portu przełącznika Cisco w trybie trunk. Ponieważ jakikolwiek port magistralny przeprowadzi różne kontrole, zanim faktycznie się uruchomi (zwykle ponad 30 sekund), spowodowało to wyświetlenie powyższego komunikatu o błędzie resetowania połączenia.

Moim rozwiązaniem była zmiana portu przełącznika na tryb dostępu spanning-tree portfast, ponieważ w moim środowisku tryb łącza nie jest potrzebny na tym serwerze.

Dowiedziałem się także o tym problemie, używając parametru debugowania do sshfs.

afardana
źródło