Сброс соединения по пиру с помощью sshfs

32

Я использую монтирование fuse / 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

— Санчке Деллоар
источник

man ssh-configявно разрешает тильду дляIdentityFile

— CharlesB

4

@CharlesB Я проверил это в обоих направлениях и уверяю вас, мой ответ верен. И я вижу, на что вы ссылаетесь в справочных страницах. Возможно, это ошибка при запуске с sudo? (потому что я)

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

7

конечно, если вы запускаете sshfs с sudo, тильда является домом пользователя root. тогда вам нужно указать абсолютный путь.

— CharlesB

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

— замедленная

В моем случае мне просто нужен был номер порта. Это было добавлено с -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: Bad SSH2 шифр спецификации 'arcfour'.

— Salathiel Genèse

8

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

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

Дополнительные настройки появились в sshd_config:

Subsystem sftp /usr/libexec/sftp-server

— геом
источник

1

Это решение не работает для меня. Поэтому я ценю что-то еще, чтобы попробовать.

— сумасшедший ежик

Включение SFTP на моем NAS-устройстве Synology также устранило ошибку для меня. НО содержимое, отображаемое в смонтированной папке, отличается от содержимого, подключенного напрямую через ssh. Папки отсутствуют, а корень не доступен. Облом.

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

5

Я обнаружил, что моя проблема, которая была похожей, была связана с файлом конфигурации предохранителя в:

/etc/fuse.conf

Я должен был оставить комментарий:

user_allow_other

— cennings
источник

5

На всякий случай, когда кто-то споткнется о этот поток: у меня была эта read: Connection reset by peerошибка, потому что имя хоста не было разрешено (я не использовал полностью определенный хост). Использование правильного имени хоста решило проблему - сообщение об ошибке просто полностью вводит в заблуждение.

Хорошим тестом является ssh на компьютер перед запуском команды sshfs, если это даже не работает, 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

и это решило проблему.

— Arashr
источник

1

Пожалуйста, не отрицайте, не говоря почему. Это разумная вещь, чтобы проверить.

— сумасшедший ежик

2

Моя ошибка была на стороне сервера. Подсистема sftp для sshd, по-видимому, по умолчанию недоступна в более новых Centos 7.6.xx. исправлено путем удаления "#" из следующего в / etc / ssh / sshd_config

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

спасибо eddygeek за рецепт -odebug, чтобы помочь найти эту проблему. То же, что и GEOM выше, но не относится к Qnap.

— J.Bravo
источник

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

У меня была похожая проблема, и когда я проверил конфигурацию сети, система как-то потеряла адрес шлюза. Итак, я запустил следующую команду

route add default gw 192.169.0.254

и затем перезагрузил систему.

Проблема решена после перезагрузки.

— выщерблять
источник

2

Вы получили "сброс соединения по пиру" с плохим шлюзом?!?

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

1

В моем случае это был интерфейс сервера после долгого времени запуска. Сервер подключен к порту коммутатора Cisco в режиме транка. Поскольку любой магистральный порт будет выполнять различные проверки перед тем, как фактически станет UP (обычно более 30 секунд), это привело к появившемуся выше сообщению об ошибке сброса соединения.

Мое решение состояло в том, чтобы переключить порт коммутатора в режим доступа с spanning-tree portfast, так как в моей среде режим магистрали не нужен для этого сервера.

Я также узнал об этой проблеме, используя параметр отладки для sshfs.

— afardana
источник