Restablecimiento de la conexión por igual usando sshfs

32

Estoy usando un montaje de fusible / sshfs que funcionó bien hasta ahora. Ahora tenía que reinstalar el sistema del servidor y de repente obtenía el read: Connection reset by peererror clásico . Estoy usando la autenticación de clave pública y copié mi clave en el sistema recién instalado. El inicio de sesión ssh normal funciona bien. Cambié el registro para depurar, pero lamentablemente esto no me da ninguna información útil:

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

¿Alguien tiene una idea de lo que me estoy perdiendo aquí?

ACTUALIZAR

El auth.logcon nivel de depuración 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

ACTUALIZAR

Intenté un sshfsmontaje manual y también lo consigo read: Connection reset by peer. Luego agregué las opciones de depuración y también obtuve Permission denied (publickey).. Esto es extraño ya que la clave pública está en su lugar y de lo contrario funciona bien. También uso mi usuario para la conexión ssh y especifico manualmente el archivo de clave privada. ¿Podría ser esto un problema con la cuenta raíz que no puede acceder a la clave pública correcta en el servidor en alguna parte? Estoy ejecutando

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

y la parte de registro relevante es

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 
— André Stannek
fuente
1
El resultado se ve exactamente como uno de una sesión ssh que se niega a conectarse debido a la falta de coincidencia de la huella digital de la clave del servidor (o una clave desconocida). ¿ sftpEl servidor funciona correctamente?
— Peter
Probé sftp con Nautilus ( Connect to Server...opción) y Filezilla. Funciona bien. Aunque Filezilla me preguntó sobre una clave de host desconocida.
— André Stannek
Pruébelo sftpdirectamente: eso es lo que utiliza SSHFS.
— Peter
44
A mí me parece igual. ¿Has intentado obtener alguna información de depuración del cliente? sshfs -odebug,sshfs_debug,loglevel=debug ...podría hacer el truco (tomado de sourceforge.net/apps/mediawiki/fuse/index.php?title=SshfsFaq ).
— Peter
1
@peterph ya tiene esa idea ;-) Ver mi segunda actualización. Simplemente omití los parámetros de depuración en el comando publicado aquí, pero lo ejecuté con ellos.
— André Stannek

Respuestas:

21

Estaba usando la -F /path/to/configopción. La respuesta estaba en mi archivo de configuración donde tenía

IdentityFile ~/.ssh/id_rsa

que no funcionó Se requiere la ruta absoluta:

IdentityFile /home/user/.ssh/id_rsa
— Sanchke Dellowar
fuente
man ssh-configpermite explícitamente tilde paraIdentityFile
— CharlesB
44
@CharlesB Lo he probado en ambos sentidos y le aseguro que mi respuesta es válida. Y veo lo que estás haciendo referencia en las páginas del manual. Tal vez es un error cuando se ejecuta con sudo? (porque lo estoy)
— Sanchke Dellowar
77
claro, si está ejecutando sshfs con sudo, tilde es el hogar del usuario root. entonces necesita especificar la ruta absoluta.
— CharlesB
1
Incluso si usa rutas absolutas en su ~/.ssh/configarchivo, la ejecución sudo sshfsleerá de manera predeterminada el /root/.ssh/configarchivo raíz (si corresponde). Debe pasar la ruta explícita a su archivo de configuración a través de -F.
— Dan Dascalescu
14

Después de intentarlo mucho más, resulta que mi usuario cliente no estaba en el fusegrupo. Después lo agregué con sudo usermod -a -G fuse myuserel soporte funciona bien nuevamente. No me pregunte cómo podría haber funcionado antes de reinstalar el servidor. ¡Gracias por toda su ayuda!

— André Stannek
fuente
2
¿Es este el usuario en el sistema de archivos local o remoto?
— Woodrow Barlow
1
@WoodrowBarlow para ser honesto, ya no lo sé: D Mi mejor conjetura sería local, ya que aquí es donde usas el fusible.
— André Stannek
ogpasswd --add USER fuse
— desaceleratedcaviar
En mi caso, simplemente necesitaba el número de puerto. Esto se agregó con la -popción.
— Paradoja
11

Dado que este mensaje de error es el predeterminado cuando falla la conexión ssh, la respuesta más genérica (por comentario de @peterph) es investigar usando al menos -odebug:

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

por ejemplo

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

Como se ha dicho en otro lugar, las causas comunes son la ausencia allow_otherde fuse.conffalta o fusepertenencia a un grupo (aunque esto puede no ser necesario ya en Ubuntu 18.04?)

En mi caso esta impreso:

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

... apuntando a una opción de cifrado no compatible (trabajando en fedora pero no en ubuntu)

— eddygeek
fuente
Usando -o debug, obtuve la línea de línea de comando 0: especificación de cifrado SSH2 incorrecta 'arcfour'.
— Salathiel Genèse
8

Tuve el mismo problema hoy. sshla conexión está bien, sshfsno lo está. Mi servidor SSH es Qnap NAS (TS-228).

El problema se solucionó habilitando SFTP en el dispositivo NAS.

La configuración adicional apareció en sshd_config:

Subsystem sftp /usr/libexec/sftp-server
— Geom
fuente
1
Esa solución no me funciona. Así que agradezco tener algo más que probar.
— erizo demente
Habilitar SFTP en mi Synology NAS también resolvió el error para mí. PERO el contenido que se muestra en la carpeta montada no es el mismo que cuando se conecta directamente a través de ssh. Faltan carpetas y no se puede acceder a la raíz. Gorrón.
— Heinrich Ulbricht
5

Encontré que mi problema, que era similar, tenía que ver con el archivo de configuración del fusible en:

/etc/fuse.conf

Tuve que dejar de comentar:

user_allow_other
— cennings
fuente
5

En caso de que alguien tropiece con este hilo: tuve este read: Connection reset by peererror porque el nombre de host no se podía resolver (no estaba usando un host totalmente calificado). El uso del nombre de host correcto resolvió el problema: el mensaje de error es completamente engañoso en ese momento.

Una buena prueba es hacer ssh en la máquina antes de ejecutar el comando sshfs, si eso ni siquiera funciona, sshfs tampoco funcionará.

— Bob Lauer
fuente
sshfs server-ssh-alias: / some / dir / mnt no funcionó para mí, pero sshfs real.servername.org:/some/dir / mnt sí funcionó para mí. (combinado con user_allow_other)
— Brian C.
2

Obtuve este error e intenté los métodos anteriores y no pude hacerlo funcionar.

El problema era que el servidor no aceptaba ssh en el puerto 22. Solía:

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

y resolvió el problema.

— Arashr
fuente
1
Por favor, no voten sin decir por qué. Esto es algo razonable de verificar.
— erizo demente
2

Mi error fue en el servidor. El subsistema sftp para sshd aparentemente no está disponible en los nuevos centos 7.6.xx. arreglado eliminando "#" delante de lo siguiente en / etc / ssh / sshd_config

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

gracias a eddygeek por la receta -odebug para ayudar a encontrar este problema. Igual que GEOM arriba pero no específico de Qnap.

— J.Bravo
fuente
2

Obtuve el mismo error durante la ejecución sudo sshfs [...] myhost: /mnt/myhost, donde myhostse define en mis ~/.ssh/configarchivos.

El problema es que la ejecución sudo sshfsno buscó en mi directorio de inicio ~/.ssh/config, sino en roots. La solución fue pasar explícitamente el archivo de configuración a través de -F:

sudo sshfs -F /home/dandv/.ssh/config [...] myhost: /mnt/myhost
— Dan Dascalescu
fuente
1

Borré la huella digital del host de /home/user/.ssh/known_hosts (en realidad borré todo el archivo) y lo arreglé ... porque la huella digital había cambiado. El uso de ssh para conectarse al host dio una razón clara de por qué no se estaba conectando.

— mdxe
fuente
1

Para aquellos que buscan una solución muy simple: después de ejecutar sshfs en modo de depuración, descubrí que mi conexión estaba rota.

Active el modo detallado con el interruptor:

-o debug
— sandoval31
fuente
1

Tuve un problema similar, y cuando revisé la configuración de la red, el sistema perdió la dirección de la puerta de enlace. Entonces ejecuté el siguiente comando

route add default gw 192.169.0.254

y luego reinicia el sistema.

El problema se resuelve después del reinicio.

— Punta
fuente
2
¿Tienes "restablecimiento de conexión por igual" con una puerta de enlace incorrecta?!?
— Jeff Schaller
1

En mi caso, era que la interfaz del servidor no estaba activa después de mucho tiempo en el inicio. El servidor está conectado a un puerto de switch Cisco con modo troncal. Dado que cualquier puerto troncal realizará varias comprobaciones antes de que esté realmente ARRIBA (generalmente más de 30 segundos), esto ha resultado en el mensaje de error de restablecimiento de conexión anterior.

Mi solución fue cambiar el puerto del conmutador al modo de acceso spanning-tree portfast, ya que en mi entorno el modo troncal no es necesario para este servidor.

También descubrí este problema utilizando el parámetro de depuración para sshfs.

— afardana
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.