sshfs предоставление “удаленного хоста разъединился”
Я пытаюсь смонтироваться sftp соединение в использование папки sshfs со следующей командой, которая бросает ошибку.
~$ sshfs admin@example.com:/ testfo
remote host has disconnected
Та же ошибка происходит, если я SSH в систему и повторяю команду с localhost. Эта команда также работала с другой машиной поэтому, проблема находится где-нибудь на сервере.
~$ cat /var/log/auth.log
[...]
May 24 22:49:43 example sshd[20095]: Accepted publickey for admin from 24.111.222.33 port 47086 ssh2: RSA ad:xx:6e:xx:14:xx:bd:b5:xx:cb:66:xx:xx:xx:a3:ac
May 24 22:49:43 example sshd[20095]: pam_unix(sshd:session): session opened for user admin by (uid=0)
May 24 22:49:43 example systemd-logind[812]: Removed session 60.
May 24 22:49:43 example systemd-logind[812]: New session 61 of user admin.
May 24 22:49:44 example sshd[20143]: Received disconnect from 24.203.164.45: 11: disconnected by admin
May 24 22:49:44 example sshd[20095]: pam_unix(sshd:session): session closed for user admin
~/.ssh каталог принадлежит администратору, так как я рассматривал что как попытку отладки для подобной проблемы.
Дополнительная информация для дальнейшего использования:
Проблема не с самим SSH, а с SFTP. Это проявлено тем, что соединения SSH работают правильно, но SFTP всегда перестал работать. Попытка к SFTP приводит к Received unexpected end-of-file from SFTP server
Проблема не связана с произведенными строками сценариев входа в систему (например. ~/.bashrc).
Проблема присутствует от всех пользователей (включая корень).
Вот моя sshd конфигурация (/etc/ssh/sshd_config):
# Package generated configuration file
# See the sshd_config(5) manpage for details
# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024
# Logging
SyslogFacility AUTH
LogLevel INFO
# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#MaxStartups 10:30:60
#Banner /etc/issue.net
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
Subsystem sftp sftp-server
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
sftp-server пакет установлен. (sudo apt-get install openssh-sftp-server)
6 ответов
Ваш Subsystem значение в sshd_config является неправильным.
Это должно быть Subsystem sftp /usr/lib/openssh/sftp-server или internal-sftp. Попытайтесь изменить /etc/ssh/sshd_config к этому значению перезапустите ssh сервисную попытку ответа еще раз.
Если Вы можете соединить хост через ssh отдельно:
ssh xxx.xxx.xxx.xxx
Вам можно предложить сохранить ключ, Вы ned для ввода ДА, не просто Y. Вас нужно затем попросить имени пользователя и пароля для пользователя на той удаленной машине.
Используйте тот, который Вы пытаетесь сделать sshfs с, сообщение назад Ваши результаты.
Если Вы отказались от соединения, я предполагаю, что Вы не установили SSH на удаленном компьютере. Открытый ssh может устанавливаться с этой командой, работаться удаленный компьютер:
sudo apt install openssh-server
Старый вопрос, но первый, который предстает перед этой проблемой.
Моей проблемой был сервер требуемая ключевая аутентификация, но я выполнял использование команды sudo и определение -o IdentityFile=~/.ssh/id_rsa, значение ~ был расширен до дома корня, не моего.
Определение полного пути работало, и я предполагаю использовать $HOME имел бы также (потому что это расширится ранее).
Вы получите эту ошибку, если удаленный сервер выполнит Dropbear, а не OpenSSH.
SSHFS использует SFTP, и Dropbear не обеспечивает SFTP. Таким образом, когда Вы пытаетесь использовать его, сервер Dropbear видит запрос на подсистему, что это не понимает и отбрасывает соединение.
Я не уверен, помогает ли это, но у меня была подобная проблема
remote host has disconnected
и после некоторого googling&browsing я понял, это на самом деле я соединил ssh через другой порт.
Так, например, я должен был соединиться через ssh (пример, приняв номер порта 1234):
ssh username@example.com -p 1234
вместо стандарта ssh, когда номер порта равняется 22. Таким образом, то же должно было использоваться для sshfs соединения:
sshfs username@example.com:/ ~/testfolder -p 1234
Это решило мою проблему.
Еще одна причина, которая произошла со мной, состояла в том что dropbearmulti сам двоичный файл испытал недостаток в строке /usr/libexec/sftp-server который потерялся где-нибудь вокруг сборки 33600 из DD-WRT. Проверьте, упоминает ли упомянутый двоичный файл этот файл, или он не будет работать, даже если он присутствует. Я должен был использовать двоичный файл от сборки 33525 и сделать средство запуска, которое уничтожает нормальный багги dropbear, затем выполняет этого. Вы создаете названную символьную ссылку dropbear указывая dropbearmulti. Вы останавливаете текущий с stopservice sshd, затем выполните рабочий. Посмотрите в ps на что похожи надлежащие параметры. Лучше иметь его на jffs (или распакуйте его к/tmp) так, чтобы Вы могли все еще umount любой диск.