sshfs con fstab: restablecimiento de la conexión por igual

10

Estoy tratando de permitir que mi computadora portátil (Ubuntu 13.04) acceda al disco duro de mi PC (Lubuntu 13.04) a través de SSHFS. Estoy usando claves RSA para conectarme.

Funciona perfectamente bien si escribo esto en la terminal:

sshfs my-PC:/a_folder /media/a_folder

Pero me gustaría que se montara automáticamente cuando arranque mi laptop. Entonces me agregué al grupo de fusibles:

sudo adduser mynickname fuse

Y agregué la siguiente línea a mi archivo fstab:

sshfs#mynickname@my-PC:/a_folder /media/a_folder fuse defaults,idmap=user,_netdev 0 0

Cuando inicio el portátil, aparece una carpeta en la lista de dispositivos, pero no está montada. Cuando intento acceder a través de Nautilus, muestra el siguiente error:

mount: only root can mount sshfs#mynickname@my-PC:/a_folder on /media/a_folder

Me sale el mismo error si intento

mount /media/a_folder

en una terminal

Si lo intento

sudo mount /media/a_folder

yo obtengo

read: Connection reset by peer

Traté de agregar "allow_other" como una opción en la entrada fstab, y descomenté la línea relacionada en /etc/fuse.conf, pero no cambió nada.

El usuario "mynickname" es el propietario de la carpeta / media / a_folder y tiene permisos rwx.

Miré muchos hilos en Internet sobre personas con problemas bastante similares, pero nada funcionó hasta ahora. Por lo general, la gente ni siquiera puede hacer

sshfs my-PC:/a_folder /media/a_folder

sin obtener un error, mientras que esto funciona bien en mi computadora portátil.

Cualquier idea y consejos serán muy apreciados! Gracias.

EDITAR: Resolví este problema hace un tiempo, pero olvidé actualizar esta publicación. Así que aquí está lo que hay en mi fstab:

sshfs#mynickname@my-PC:/a_folder /media/a_folder fuse noauto,_netdev,idmap=user,user,default_permissions 0 0

La opción clave para agregar era default_permissions si recuerdo. Tuve que agregar mynickname al grupo al que pertenece / a_folder / en mi PC.

fstab sshfs

8

El problema que está experimentando es que su usuario normal tiene una configuración correcta para su archivo de identidad, mientras que el usuario raíz no tiene idea de qué clave ssh usar.

Puede solucionar esto diciéndole a fstab qué archivo de identidad / clave ssh usar al intentar conectarse:

sshfs#user@host:/mnt/whatever/ /mnt/whatever/        fuse    user,_netdev,reconnect,uid=1000,gid=1000,IdentityFile=/home/USER/.ssh/KEYFILE,idmap=user,allow_other  0   2

— earthmeLon
fuente

Gracias por tu respuesta. Ya probé con la opción IdentityFile, pero no especifiqué las opciones uid y gid, ¡así que lo intentaré!

Técnicamente, no debería necesitar usarlo sudosi todo está configurado correctamente para un montaje FUSE. Además, la configuración de uid / gid solo debería afectar a qué usuario tiene derechos sobre los archivos de su sistema.

— earthmeLon

Así que probé con uid, gid, IdentityFile, allow_other, todas esas opciones al mismo tiempo, y desafortunadamente todavía no funciona. Sigue siendo el mismo error.

¿Te importaría publicar una muestra de cómo lo has escrito? Debería apuntar a su clave privada y no a su clave pública.

— earthmeLon

1

Entonces ambos métodos no funcionaron. Sigue siendo el mismo error. Para el archivo de configuración, intenté especificando el host correcto: usuario, nombre de host (probé tanto IP como nombre), archivo de identidad. Pero no funcionó tan bien. Entonces, lo que termino haciendo por ahora es que agregué el comando sshfs my-PC: / a_folder / media / a_folder en las aplicaciones de inicio. No es tan limpio como usar fstab, pero funciona lo suficientemente bien por ahora. ¡Gracias por tu ayuda y tus sugerencias! Si piensas en otra cosa, siéntete libre de compartir, ¡te lo agradeceré!

4

Para obtener una salida de depuración real, debe agregar ambas sshfs_debugy debugopciones al soporte:

sshfs#mynickname@my-PC:/a_folder /media/a_folder fuse defaults,idmap=user,_netdev,debug,sshfs_debug 0 0

Con esto obtendrás mucha información de depuración para ayudarte:

$ sudo mount -a
SSHFS version 2.5
FUSE library version: 2.9.2
nullpath_ok: 0
nopath: 0
utime_omit_ok: 0
executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-2> <user@box> <-s> <sftp>
user@box's password: 
Server version: 3
Extension: posix-rename@openssh.com <1>
Extension: statvfs@openssh.com <2>
Extension: fstatvfs@openssh.com <2>
Extension: hardlink@openssh.com <1>
Extension: fsync@openssh.com <1>
unique: 1, opcode: INIT (26), nodeid: 0, insize: 56, pid: 0
INIT: 7.22
flags=0x0000f7fb
max_readahead=0x00020000
remote_uid = 1001
   INIT: 7.19
   flags=0x00000011
   max_readahead=0x00020000
   max_write=0x00020000
   max_background=0
   congestion_threshold=0
   unique: 1, success, outsize: 40
unique: 2, opcode: STATFS (17), nodeid: 1, insize: 40, pid: 2771
unique: 3, opcode: LOOKUP (1), nodeid: 1, insize: 47, pid: 3371

En mi caso, descubrí que mi máquina solo figuraba en la lista .ssh/config, por lo que no tenía solución para root.

Y, por cierto, debe configurar uid y gid, ya que idmap=usersolo parece funcionar para el usuario actual, que es la raíz en este caso.

— Alexander Torstling
fuente

3

Este problema también puede ocurrir cuando cambia la clave de host de ssh.

Intente conectarse al servidor a través de ssh (por ejemplo ssh username@hostIP). Si aparece el siguiente error:

 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!    @
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Siga las instrucciones en el mensaje de error para eliminar la clave anterior e intente conectarse nuevamente a través de ssh. Si el error ya no aparece, la conexión sshfs debería funcionar.

— Gorka
fuente

"intente conectarse al servidor a través de ssh" Asegúrese de hacer esto como root si está montando el directorio como root (que es lo que sucede cuando se monta automáticamente). El known_hostsarchivo de un usuario puede ser diferente del known_hostsarchivo raíz .

— Shelvacu

0

Revelación completa: geek de la vieja escuela, pero completamente nuevo en el mundo de Linux / código abierto

En primer lugar, sigo usando la autenticación de contraseña porque todavía no me he vuelto lo suficientemente inteligente con las claves RSA. Sin embargo, eso está llegando a la parte superior de la lista.

Información de configuración relevante: Uso de un MacBook Pro con VMWare Fusion instalado, en el que tengo el servidor Ubuntu 10.04 LTS. Confiar en el terminal de Mac y SSH para casi toda la interacción de mi servidor

Después de estropear una instalación de Drupal, volví a una instantánea anterior y de repente no pude ejecutar un comando que acababa de usar momentos antes: sshfs -o idmap=user -o allow_other user@mac.home:/Users/<username>/Documents ~/mountpoint

El problema es que las claves se desincronizaron. No sé si realmente necesitaba hacer esto tanto en mi host como en mi servidor, pero borré todas las claves locales en cada una haciendo primero una copia de seguridad del archivo conocido_hosts, luego editando el archivo conocido_hosts para eliminar entradas .
En Mac, este archivo se encuentra en: /Users/<username>/.ssh/known_hosts
En Ubuntu, este archivo se encuentra en:/home/<username>/.ssh/known_hosts

Entonces, para resumir, todo se realizó desde mi terminal Mac, después de iniciar el servidor Ubuntu:

cp /Users/<username>/.ssh/known_hosts /Users/<username>/.ssh/known_hosts.old
nano  /Users/<username>/.ssh/known_hosts
  # remove extra entries, save file
ssh <username>@ubuntu_server
cp /home/<username>/.ssh/known_hosts, /home/<username>/.ssh/known_hosts.old
nano /home/<username>/.ssh/known_hosts
  # remove extra entries, save file

En el primer SSH en cada sistema, SSH me pide que permita que se agreguen claves RSA y todo funciona a partir de entonces.

— Galán
fuente