Соединение, сброшенное одноранговым узлом, использующим sshfs

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

/etc/fuse.conf

Я не комментировал:

user_allow_other

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

IdentityFile ~/.ssh/id_rsa

, который не работал. Требуется абсолютный путь:

IdentityFile /home/user/.ssh/id_rsa

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

Хорошей проверкой является подключение к машине по ssh перед выполнением команды sshfs, если это не сработает, sshfs тоже не сработает.

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

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

Вsshd_config:

Subsystem sftp /usr/libexec/sftp-server

Поскольку это сообщение об ошибке появляется по умолчанию при сбое подключения 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

...указывает на неподдерживаемую опцию шифрования (, работающую на Fedora, но не на Ubuntu)

Для тех, кто ищет очень простое решение :После запуска sshfs в режиме отладки я обнаружил, что мое соединение разорвано.

Включите подробный режим с помощью переключателя:

-o debug

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

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

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

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

Я получил эту ошибку и попробовал описанные выше методы, но они не сработали.

Проблема заключалась в том, что сервер не принимал ssh через порт 22. Я использовал:

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

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

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

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

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

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

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

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

Если у кого-то по-прежнему возникают проблемы, и он такой же идиот, как я, убедитесь, что вы не создали новый каталог (в вашей локальной системе )с помощью sudo.

Потому что тогда вы, (локальный пользователь ), не будете иметь права на запись в него.

Что делает невозможным использование в качестве точки монтирования.

Быстрое исправление для этогоsudo chown -R localuser:localuser ~/directory_you_created

(Замените localuser своим реальным именем пользователя ).

Удачи.

У меня тоже была эта проблема, и я прокомментирую решение на случай, если оно сработает для кого-то еще.

Пытался смонтировать NAS на малине. В NAS я использую SSH на порту 2222, а SFTP — на порту 22.

Мне удалось найти ошибку с помощью команды из предыдущего комментария:

sshfs -p 2222 -odebug,sshfs_debug,loglevel=debug -o Compression=no -o allow_root -o transform_symlinks user@ip:/ /mnt/folder

................
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending subsystem: sftp
subsystem request failed on channel 0
read: Connection reset by peer

Моя ошибка заключалась в том, что я пытался подключиться через SSH-порт 2222, когда мне просто пришлось оставить 22 по умолчанию для SFTP.

sshfs user@ip:/ /mnt/folder

Так просто и так функционально.

У меня была проблема, вызванная DNS. Пинг и ssh работали напрямую, но

sshfs -o debug <hostname>:/ /mnt/<directory>
SSHFS version 3.7.0
executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-2> <hardie.isode.net> <-s> <sftp>
ssh: Could not resolve hostname hardie.isode.net: Name or service not known
read: Connection reset by peer

Мой маршрутизатор возвращал результат DNS, но SSHF явно не работал, и -o отладка показала, почему. Добавление хоста в /etc/hosts позволило ему работать. Непонятно, зачем это было нужно (, что явно не идеально ). (Федора 32)

У меня была такая же проблема. Эти варианты мне помогли:

sshfs -odebug,sshfs_debug,loglevel=debug

Взамен я получил:

SSHFS версии 2.10.0 предохранитель :неверная точка монтирования `разрешить _другое, по умолчанию _разрешения, IdentityFile=/home/rbr/.ssh/id _rsa' :Нет такого файла или каталога

...что дало мне направление, где искать.

Я обнаружил, что если я пытался связаться с тем же сервером с обычным ssh, это дало мне это:

Что для меня было точным; оно изменилось .

Он сообщил мне, что я могу решить эту проблему с помощью этой команды:

ssh-keygen -f "/path/to/known_hosts" -R REMOTE_IP

После этого и повторного запуска sshfsвсе заработало нормально.