sshfs dando "el host remoto se ha desconectado"

Estoy tratando de montar una sftpconexión en una carpeta usando sshfsel siguiente comando que arroja un error.

~$ sshfs admin@example.com:/ testfo
remote host has disconnected

El mismo error ocurre si ingreso SSH en el sistema y repito el comando con localhost. Este comando también funcionó con otra máquina, por lo que el problema está en algún lugar del servidor.

~$ 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

El ~/.sshdirectorio es propiedad del administrador ya que lo vi como un intento de depuración para un problema similar.

Información adicional para referencia futura:

El problema no es con SSH en sí, sino con SFTP. Esto se manifiesta por el hecho de que las conexiones SSH funcionan correctamente pero SFTP siempre falla. Intentar SFTP resulta enReceived unexpected end-of-file from SFTP server

El problema no está relacionado con las secuencias de comandos de inicio de sesión producidas por cadenas (por ejemplo ~/.bashrc).

El problema está presente en todos los usuarios (incluida la raíz).

Aquí está mi configuración 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-serverEl paquete está instalado. ( sudo apt-get install openssh-sftp-server)

Su Subsystemvalor en sshd_configestá mal.

Debería ser Subsystem sftp /usr/lib/openssh/sftp-servero internal-sftp. Intente modificar el /etc/ssh/sshd_configa este valor, reinicie el servicio ssh e intente una vez más.

Antigua pregunta, pero la primera que surge para este problema.

Mi problema era que el servidor requería autenticación de clave, pero estaba ejecutando el comando usando sudoy especificando -o IdentityFile=~/.ssh/id_rsa, lo que significaba que ~se expandió al inicio de la raíz, no al mío.

Especificar la ruta completa funcionó, y me imagino que usarlo también lo $HOMEhabría hecho (porque se habría expandido antes).

Obtendrá este error si el servidor remoto ejecuta Dropbear en lugar de OpenSSH.

SSHFS usa SFTP y Dropbear no proporciona SFTP. Entonces, cuando intentas usarlo, el servidor Dropbear ve una solicitud de un subsistema que no entiende y desconecta la conexión.

Desde aquí: /unix/363540/mount-a-filesystem-using-sshfs-using-the-dropbear-server-on-yocto-firmware

Si puede conectar el host a través de ssh por sí mismo:

ssh xxx.xxx.xxx.xxx

Es posible que se le solicite que guarde la clave, debe escribir SÍ, no solo una Y. Luego, se le debe solicitar el nombre de usuario y la contraseña del usuario en esa máquina remota.

Use el que está tratando de hacer sshfs, publique sus resultados.

Si se rechaza una conexión, supongo que no ha instalado SSH en la computadora remota. Open ssh se puede instalar con este comando, ejecutar en la computadora remota:

sudo apt install openssh-server

No estoy seguro de si ayuda, pero tuve un problema similar

remote host has disconnected

y después de buscar y buscar en Google, me di cuenta de que realmente conectaba ssh a través de un puerto diferente.

Entonces, por ejemplo, tuve que conectarme a través de ssh (por ejemplo, suponiendo el número de puerto 1234):

ssh username@example.com -p 1234

en lugar de ssh estándar cuando el número de puerto es 22. Entonces, lo mismo tuvo que usarse para la conexión sshfs:

sshfs username@example.com:/ ~/testfolder -p 1234

Solucionó mi problema.

Otra causa que me sucedió fue que el dropbearmultibinario en sí carecía de la cadena /usr/libexec/sftp-serverque se perdió en algún lugar alrededor de la compilación 33600 de DD-WRT. Compruebe si dicho binario menciona este archivo o no funcionará incluso si está presente. Tuve que usar un binario de la versión 33525 y hacer un lanzador que matara el buggy dropbear normal, luego ejecuta este. Creas un enlace simbólico llamado dropbearapuntando a dropbearmulti. Detiene el actual con stopservice sshd, luego ejecuta el que funciona. Vea pscómo se ven los parámetros adecuados. Es mejor tenerlo en jffs (o descomprimirlo en / tmp) para poder seguir umountmanejando.