Скидання з’єднання одноранговими за допомогою sshfs

32

Я використовую запобіжник / sshfs кріплення, яке добре працювало до цих пір. Тепер мені довелося перевстановити серверну систему і раптом отримати класичну read: Connection reset by peerпомилку. Я використовую аутентифікацію відкритого ключа та скопіював свій ключ до нещодавно встановленої системи. Звичайний вхід в ssh працює чудово. Я змінив журнал на налагодження, але, на жаль, це не дає мені корисної інформації:

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

Хтось має уявлення про те, чого я тут пропускаю?

ОНОВЛЕННЯ

Рівень auth.logналагодження 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

ОНОВЛЕННЯ

Я спробував ручне sshfsкріплення, і я також отримую read: Connection reset by peer. Потім я додав параметри налагодження і також отримав Permission denied (publickey).. Це дивно, оскільки відкритий ключ діє і працює нормально. Я також використовую свого користувача для з'єднання ssh і вручну вказую файл приватного ключа. Чи може це бути проблемою, коли кореневий обліковий запис не може отримати доступ до правильного відкритого ключа десь на сервері? Я виконую

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

і відповідна частина журналу є

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

— Андре Станек
джерело

1

Вихід виглядає точно так само, як з сеансу ssh, який відмовляється підключитися через невідповідність відбитків пальця ключа сервера (або невідомого ключа). Чи sftpправильно працює сервер?

— петерф

Я спробував sftp і з Nautilus ( Connect to Server...опція), і з Filezilla. Це чудово працює. Хоча Filezilla запитав мене про невідомий хост-ключ.

— Андре Станек

Спробуйте sftpбезпосередньо - саме для цього використовується SSHFS.

— петерф

4

На мене так само виглядає. Ви намагалися отримати інформацію про налагодження від клієнта? sshfs -odebug,sshfs_debug,loglevel=debug ...міг зробити трюк (взятий з sourceforge.net/apps/mediawiki/fuse/index.php?title=SshfsFaq ).

— петерф

1

@peterph вже зрозумів таку ідею ;-) Дивіться моє друге оновлення. Я просто опустив параметри налагодження в команді, розміщеній тут, але я виконав їх із ними.

— Андре Станек

21

Я використовував -F /path/to/configваріант. Відповідь була у моєму конфігураційному файлі, де я був

IdentityFile ~/.ssh/id_rsa

які не спрацювали. Абсолютний шлях необхідний:

IdentityFile /home/user/.ssh/id_rsa

— Sanchke Dellowar
джерело

man ssh-configчітко дозволяє tilde дляIdentityFile

— CharlesB

4

@CharlesB Я перевірив це обома способами, і запевняю, моя відповідь справедлива. І я бачу те, на що ви посилаєтесь на сторінках man. Можливо, це помилка при бігу з судо? (бо я є)

— Санчке Доллер

7

звичайно, якщо ви використовуєте sshfs з sudo, tilde - це головна користувач root. то вам потрібно вказати абсолютний шлях.

— ЧарльзБ

1

Навіть якщо ви використовуєте абсолютні шляхи у вашому ~/.ssh/configфайлі, запуск sudo sshfsза замовчуванням прочитає /root/.ssh/configфайл root (якщо такий є). Вам потрібно пройти явний шлях до вашого конфігураційного файлу через -F.

— Дан Даскалеску

14

Після набагато більше спроб виявилося, що мій клієнт не був у fuseгрупі. Після того, як я додав його з sudo usermod -a -G fuse myuserкріпленням, знову добре працює. Не запитуйте мене, як це могло працювати перед перевстановленням сервера. Дякую за всю допомогу!

— Андре Станек
джерело

2

це користувач у локальній чи віддаленій файловій системі?

— Вудро Барлоу

1

@WoodrowBarlow, чесно кажучи, я вже не знаю: D Моя найкраща здогадка буде місцевою, оскільки саме тут ви використовуєте запобіжник.

— Андре Станек

абоgpasswd --add USER fuse

— deceleratedcaviar

У моєму випадку мені просто потрібен номер порту. Це було додано з -pопцією.

— Парадокс

11

Оскільки це повідомлення про помилку є типовим, коли ssh-з'єднання виходить з ладу, найбільш загальною відповіддю (за коментарем @peterph) є розслідування за допомогою принаймні -odebug :

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

наприклад

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

Як сказано в інших місцях, до загальних причин відносяться відсутні allow_other в fuse.confабо відсутності fuseчленства в групі (хоча це може бути не потрібно більше на Ubuntu 18.04?)

У моєму випадку це було надруковано:

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

... вказує на непідтримуваний параметр Cipher (працює на fedora, але не на ubuntu)

— eddygeek
джерело

Використовуючи -o debug, я отримав рядок командного рядка 0: Неправильна специфікація шифру SSH2 "arcfour".

— Салатієль Генез

8

У мене було таке ж питання і сьогодні. sshз'єднання в порядку, sshfsні. Мій сервер SSH - це Qnap NAS (TS-228).

Проблему виправили, включивши SFTP на пристрої NAS.

Додаткові налаштування з’явилися в sshd_config:

Subsystem sftp /usr/libexec/sftp-server

— Геом
джерело

1

Це рішення для мене не працює. Тож я ціную ще щось спробувати.

— дементований їжак

Увімкнення SFTP в моїй Synology NAS також вирішило помилку. АЛЕ вміст, який відображається у змонтованій папці, не такий, як при прямому підключенні через ssh. Папки відсутні, а до кореня не можна отримати доступ. Бампер.

— Генріх Ульбріхт

5

Я виявив, що моя проблема, яка була схожа, пов'язана з файлом конфігурації запобіжників у:

/etc/fuse.conf

Мені довелося скасувати коментар:

user_allow_other

— століття
джерело

5

На випадок, якщо хтось наткнеться на цей потік: у мене виникла read: Connection reset by peerпомилка, оскільки ім'я хоста не було вирішеним (я не використовував повністю кваліфікованого хоста). Використання правильного імені хоста вирішило проблему - тоді повідомлення про помилку просто повністю вводить в оману.

Хорошим тестом є ssh до машини перед запуском команди sshfs, якщо це навіть не працює.

— Боб Лауер
джерело

sshfs server-ssh-alias: / some / dir / mnt не працював для мене, але sshfs real.servername.org:/some/dir / mnt працював для мене. (у поєднанні з user_allow_other)

— Брайан К.

2

Я отримав цю помилку і спробував вищевказані методи і не зміг зробити так, щоб вона працювала.

Проблема полягала в тому, що сервер не приймав ssh на порт 22. Я використовував:

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

і це вирішило питання.

— Арашр
джерело

1

Будь ласка, не зволікайте, не говорячи чому. Це розумна річ, щоб перевірити.

— дементований їжак

2

Моя помилка була на стороні сервера. Підсистема sftp для sshd, мабуть, за замовчуванням недоступна в нових centos 7.6.xx. виправлено, видаливши "#" перед наступним в / etc / ssh / sshd_config

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

завдяки Eddygeek за рецепт -odebug, який допоможе знайти цю проблему. Те саме, що вище GEOM, але не характерне для Qnap.

— Дж.Браво
джерело

2

Отримала таку ж помилку під час запуску sudo sshfs [...] myhost: /mnt/myhost, де myhostвизначено у моїх ~/.ssh/configфайлах.

Проблема полягає в тому, що біг sudo sshfsне шукав у моєму домашньому каталозі ~/.ssh/config, а в roots. Рішенням було явно передати конфігураційний файл через -F:

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

— Дан Даскалеску
джерело

1

Я стерла відбиток пальця хоста з /home/user/.ssh/known_hosts (фактично видалила весь файл) і це виправила ... бо відбиток пальця змінився. використання ssh для підключення до хоста дало чітку причину, чому він не підключався.

— mdxe
джерело

1

Для тих , хто шукає дуже просте рішення: Після запуску sshfs у режимі налагодження я виявив, що мій зв’язок розірваний.

Увімкніть докладний режим за допомогою перемикача:

-o debug

— sandoval31
джерело

1

У мене була аналогічна проблема, і коли я перевірив мережевий конфігурацію, сформулював, як втратив адресу шлюзу. Тому я запустив команду нижче

маршрут додати за замовчуванням gw 192.169.0.254

а потім перезавантажте систему.

Проблема вирішується після перезавантаження.

— Джаг
джерело

2

У вас "скидання з'єднання одноранговим" із поганим шлюзом?!?

— Джефф Шаллер

1

У моєму випадку серверний інтерфейс не працював після тривалого запуску. Сервер підключений до порту комутатора Cisco в режимі магістралі. Оскільки будь-який порт магістралі здійснюватиме різні перевірки до того, як насправді стане UP (зазвичай це більше 30 секунд), це призвело до вищезазначеного повідомлення про помилку скидання з'єднання.

Моє рішення полягало в тому, щоб змінити порт комутатора на режим доступу spanning-tree portfast, оскільки в моєму середовищі режим магістралі не потрібен цьому серверу.

Я також дізнався про цю проблему, використовуючи параметр налагодження для sshfs.

— afardana
джерело