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 peer
błą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.log
poziomem 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 sshfs
montaż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
sftp
serwer działa poprawnie?Connect to Server...
opcja), jak i Filezilla. To działa dobrze. Chociaż Filezilla zapytał mnie o nieznany klucz hosta.sftp
bezpośrednio - tego używa SSHFS.sshfs -odebug,sshfs_debug,loglevel=debug ...
może zrobić lewę (wzięte z sourceforge.net/apps/mediawiki/fuse/index.php?title=SshfsFaq ).Odpowiedzi:
Korzystałem z
-F /path/to/config
opcji. Odpowiedź była w moim pliku konfiguracyjnym, w którym miałemktóre nie działało. Wymagana jest ścieżka bezwzględna:
źródło
man ssh-config
wyraźnie zezwala na tyldy dlaIdentityFile
~/.ssh/config
pliku, uruchomionesudo sshfs
domyślnie odczyta/root/.ssh/config
plik roota (jeśli istnieje). Musisz przekazać jawną ścieżkę do pliku konfiguracyjnego przez-F
.Po wielu próbach okazuje się, że mojego klienta nie było w
fuse
grupie. Po dodaniu go zsudo usermod -a -G fuse myuser
montażem znów działa dobrze. Nie pytaj mnie, jak mogło to działać przed ponowną instalacją serwera. Dziękuję za całą pomoc!źródło
gpasswd --add USER fuse
-p
opcją.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
:na przykład
Jak wcześniej wspomniano, najczęstsze przyczyny to brakuje
allow_other
wfuse.conf
lub brakfuse
przynależ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)
źródło
-o debug
dostałem wiersz poleceń 0: Zła specyfikacja szyfru SSH2 „arcfour”.Miałem dzisiaj ten sam problem.
ssh
połączenie jest OK,sshfs
nie 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
:źródło
Mój problem, który był podobny, dotyczył pliku konfiguracyjnego bezpiecznika w:
Musiałem cofnąć komentarz:
źródło
Na wypadek, gdyby ktoś potknął się o ten wątek: miałem ten
read: Connection reset by peer
błą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ć.
źródło
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:
i to rozwiązało problem.
źródło
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.
źródło
Wystąpił ten sam błąd podczas działania
sudo sshfs [...] myhost: /mnt/myhost
, gdziemyhost
jest zdefiniowany w moich~/.ssh/config
plikach.Problem polega na tym, że uruchomienie
sudo sshfs
nie szukało w moim katalogu domowym~/.ssh/config
, ale wroot
s. Rozwiązaniem było jawne przekazanie pliku konfiguracyjnego przez-F
:źródło
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ł.
źródło
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:
źródło
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.
źródło
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.
źródło