LinuxParty

Accede a los archivos de otro servidor como si estuvieran en tu propio equipo utilizando SSH, SFTP y FUSE, sin instalar servicios adicionales en el servidor

Imagina que tienes una carpeta en un servidor y quieres abrirla desde Linux como si estuviera dentro de tu directorio personal. Podrías utilizar SFTP, copiar los archivos con scp o trabajar directamente mediante SSH, pero existe una alternativa mucho más cómoda: SSHFS.

SSHFS permite montar un directorio remoto dentro del sistema de archivos local. Una vez conectado, podremos abrir, copiar, editar y eliminar sus archivos desde el gestor de archivos, el terminal o cualquier aplicación compatible.

Todo el tráfico viaja mediante SSH y, normalmente, no tendremos que instalar nada adicional en el servidor. Si ya podemos conectarnos por SSH y utilizar SFTP, tenemos casi todo preparado.

¿Qué es SSHFS?

SSHFS significa SSH File System. Es un sistema de archivos basado en FUSE que utiliza el subsistema SFTP de OpenSSH para comunicarse con el equipo remoto.

En la práctica, transforma una ruta como esta:

usuario@servidor:/var/www

en una carpeta local como esta:

/home/javier/remotos/web

Cuando entremos en la carpeta local veremos el contenido almacenado realmente en el servidor.

SSHFS resulta útil para:

• Trabajar con los archivos de un servidor web.
• Acceder a documentos de otro ordenador.
• Compartir una carpeta entre varios equipos Linux.
• Consultar archivos de una máquina virtual.
• Administrar pequeños servidores mediante una conexión cifrada.
• Abrir archivos remotos desde aplicaciones gráficas.
• Realizar copias manuales entre el equipo y el servidor.

No sustituye siempre a NFS, Samba, rsync o una plataforma de almacenamiento distribuido. Sin embargo, para acceder cómodamente a una carpeta remota sin configurar un servicio nuevo, SSHFS continúa siendo una solución sencilla y práctica.

¿Qué necesitamos?

Para seguir el tutorial necesitaremos:

• Un equipo Linux que actuará como cliente.
• Un servidor o segundo ordenador accesible mediante SSH.
• Una cuenta con permisos sobre el directorio remoto.
• SSHFS instalado en el cliente.
• Un punto de montaje local propiedad de nuestro usuario.

El servidor debe tener OpenSSH y el subsistema SFTP funcionando. En la mayoría de los servidores Linux administrados mediante SSH, SFTP ya está disponible.

Antes de instalar SSHFS conviene comprobar la conexión:

ssh usuario@servidor

Podemos utilizar una dirección IP:

ssh Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.

O un dominio:

ssh Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.

Si esta conexión no funciona, SSHFS tampoco podrá conectarse. Primero tendremos que revisar el nombre del servidor, el puerto, el cortafuegos, las credenciales y la configuración de OpenSSH.

Instalar SSHFS

En Debian, Ubuntu, Linux Mint y distribuciones derivadas:

sudo apt update
sudo apt install sshfs

En Fedora:

sudo dnf install fuse-sshfs

En Arch Linux y derivadas:

sudo pacman -S sshfs

En openSUSE:

sudo zypper install sshfs

Podemos comprobar que quedó instalado con:

sshfs --version

Las versiones actuales de SSHFS utilizan FUSE 3. Ya no suele ser necesario instalar por separado el antiguo paquete fuse, crear un grupo llamado fuse ni cargar manualmente el módulo del núcleo.

Crear el punto de montaje

Vamos a crear una carpeta dentro de nuestro directorio personal:

mkdir -p "$HOME/remotos/servidor"

Esta carpeta será la puerta de entrada al sistema remoto. Debe estar vacía antes de realizar el montaje.

Podemos comprobar que pertenece a nuestro usuario:

ls -ld "$HOME/remotos/servidor"

SSHFS recomienda realizar el montaje como usuario normal. No es necesario ejecutar todo el proceso como root.

Montar una carpeta remota manualmente

Supongamos que queremos acceder al directorio /var/www del servidor:

sshfs usuario@servidor:/var/www "$HOME/remotos/servidor"

Si utilizamos una dirección IP:

sshfs Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.:/var/www "$HOME/remotos/servidor"

SSH solicitará la contraseña del usuario remoto, salvo que tengamos configurada la autenticación mediante clave.

Si es la primera conexión, también tendremos que verificar la huella del servidor. Debemos comprobarla antes de responder afirmativamente, especialmente cuando se trate de una máquina externa.

Una vez realizado el montaje, podemos entrar en la carpeta:

cd "$HOME/remotos/servidor"
ls -la

También aparecerá como un volumen en gestores de archivos como Dolphin, Nautilus, Nemo, Caja o Thunar.

Utilizar un puerto SSH diferente

Si el servidor escucha, por ejemplo, en el puerto 2222:

sshfs -p 2222 \
  usuario@servidor:/var/www \
  "$HOME/remotos/servidor"

También podemos escribirlo como una opción:

sshfs usuario@servidor:/var/www \
  "$HOME/remotos/servidor" \
  -o port=2222

Evitar bloqueos cuando se corta la conexión

En conexiones remotas conviene añadir algunas opciones:

sshfs usuario@servidor:/var/www \
  "$HOME/remotos/servidor" \
  -o reconnect \
  -o ServerAliveInterval=15 \
  -o ServerAliveCountMax=3

Estas opciones significan lo siguiente:

• reconnect: intenta restablecer la conexión si se interrumpe.
• ServerAliveInterval=15: envía una comprobación cada 15 segundos.
• ServerAliveCountMax=3: cierra la conexión después de tres comprobaciones sin respuesta.

La opción reconnect no hace milagros. Los archivos que estuvieran abiertos cuando se perdió la conexión pueden producir errores y quizá tengan que cerrarse y abrirse nuevamente.

Montar en modo de solo lectura

Si únicamente queremos consultar los archivos y evitar modificaciones accidentales:

sshfs usuario@servidor:/var/www \
  "$HOME/remotos/servidor" \
  -o ro

Esta opción resulta especialmente recomendable al inspeccionar copias de seguridad, configuraciones importantes o directorios de producción.

Desmontar la carpeta

Cuando terminemos, debemos salir del punto de montaje:

cd "$HOME"

Después lo desmontamos con:

fusermount3 -u "$HOME/remotos/servidor"

También puede funcionar:

umount "$HOME/remotos/servidor"

Si aparece el mensaje target is busy, algún programa continúa utilizando la carpeta. Podemos buscarlo con:

findmnt "$HOME/remotos/servidor"

Y localizar los procesos implicados mediante:

fuser -vm "$HOME/remotos/servidor"

No deberíamos utilizar un desmontaje forzado sin comprobar primero qué aplicaciones tienen archivos abiertos.

Configurar una clave SSH

Introducir la contraseña cada vez acaba siendo incómodo. La solución es utilizar una clave SSH.

Creamos una clave Ed25519:

ssh-keygen -t ed25519 -a 100 -C "$(whoami)@$(hostname)-$(date -I)"

Cuando pregunte dónde guardarla, podemos aceptar la ruta propuesta pulsando Enter.

Es recomendable proteger la clave privada mediante una contraseña. Después podemos utilizar ssh-agent para no tener que escribirla continuamente durante la sesión.

Copiamos la clave pública en el servidor:

ssh-copy-id usuario@servidor

Si utilizamos otro puerto:

ssh-copy-id -p 2222 usuario@servidor

Comprobamos que la autenticación funciona:

ssh usuario@servidor

Cuando todo esté correcto, SSHFS utilizará automáticamente la misma clave.

No debemos copiar la clave privada al servidor. El archivo privado permanece en el equipo cliente; solo se envía la clave pública.

Simplificar la conexión con ~/.ssh/config

En lugar de repetir el usuario, el dominio, el puerto y la clave, podemos crear una entrada en:

~/.ssh/config

Abrimos el archivo:

nano "$HOME/.ssh/config"

Añadimos una configuración como esta:

Host servidor-web
    HostName servidor.ejemplo.com
    User usuario
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 15
    ServerAliveCountMax 3

Protegemos el archivo:

chmod 600 "$HOME/.ssh/config"

Ahora podremos conectarnos así:

ssh servidor-web

Y montar el directorio con una orden mucho más corta:

sshfs servidor-web:/var/www \
  "$HOME/remotos/servidor" \
  -o reconnect

Esta es una forma limpia de administrar varios servidores, ya que los datos de cada conexión permanecen centralizados en la configuración de OpenSSH.

Montaje automático con systemd

Podemos hacer que SSHFS monte el directorio automáticamente dentro de nuestra sesión de usuario.

Primero comprobamos las rutas de los ejecutables:

command -v sshfs
command -v fusermount3

Habitualmente serán /usr/bin/sshfs y /usr/bin/fusermount3.

Creamos el directorio de unidades del usuario:

mkdir -p "$HOME/.config/systemd/user"

Creamos el servicio:

nano "$HOME/.config/systemd/user/sshfs-servidor.service"

Introducimos este contenido:

[Unit]
Description=Montaje SSHFS del servidor
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
ExecStartPre=/usr/bin/mkdir -p %h/remotos/servidor
ExecStart=/usr/bin/sshfs -f servidor-web:/var/www %h/remotos/servidor -o reconnect -o ServerAliveInterval=15 -o ServerAliveCountMax=3
ExecStop=/usr/bin/fusermount3 -u %h/remotos/servidor
Restart=on-failure
RestartSec=10

[Install]
WantedBy=default.target

En este ejemplo, servidor-web es el alias que definimos anteriormente en ~/.ssh/config.

Informamos a systemd de la nueva unidad:

systemctl --user daemon-reload

La activamos para las próximas sesiones y la iniciamos ahora:

systemctl --user enable --now sshfs-servidor.service

Comprobamos su estado:

systemctl --user status sshfs-servidor.service

Para detener el montaje:

systemctl --user stop sshfs-servidor.service

Para desactivarlo:

systemctl --user disable sshfs-servidor.service

Si algo falla, podemos consultar el registro:

journalctl --user -u sshfs-servidor.service

Este servicio se inicia con la sesión del usuario. Si necesitamos que funcione antes de iniciar sesión, tendremos que estudiar si conviene habilitar la permanencia del gestor de usuario mediante loginctl enable-linger, crear una unidad de sistema o utilizar /etc/fstab. No deberíamos activar linger automáticamente sin comprender sus implicaciones.

Montaje mediante /etc/fstab

También podemos utilizar /etc/fstab, aunque debemos ser especialmente cuidadosos: un error puede provocar esperas durante el arranque o dejar el montaje inaccesible.

Antes de modificarlo hacemos una copia:

sudo cp -a /etc/fstab /etc/fstab.copia

Creamos el punto de montaje con una ruta absoluta:

mkdir -p /home/javier/remotos/servidor

En /etc/fstab podríamos añadir una línea adaptada a nuestro usuario y servidor:

servidor-web:/var/www /home/javier/remotos/servidor fuse.sshfs noauto,x-systemd.automount,_netdev,nofail,users,reconnect,IdentityFile=/home/javier/.ssh/id_ed25519,ServerAliveInterval=15,ServerAliveCountMax=3 0 0

No podemos utilizar $HOME ni ~ dentro de /etc/fstab; hay que escribir las rutas completas.

Las opciones principales son:

• noauto: no intenta montar inmediatamente durante el arranque.
• x-systemd.automount: activa el montaje cuando accedemos a la carpeta.
• _netdev: identifica el recurso como dependiente de la red.
• nofail: evita que un fallo del servidor bloquee el arranque.
• users: permite que usuarios normales monten y desmonten el recurso.
• reconnect: intenta recuperar conexiones interrumpidas.
• IdentityFile: señala la clave privada utilizada.

Tras modificar el archivo ejecutamos:

sudo systemctl daemon-reload

Podemos probar el montaje con:

mount /home/javier/remotos/servidor

Y comprobarlo:

findmnt /home/javier/remotos/servidor

La configuración mediante /etc/fstab puede requerir ajustes dependiendo de la distribución, los permisos, la ubicación de las claves y la forma en que se verifica la identidad del servidor. Para un único usuario, la unidad systemd --user suele resultar más clara y fácil de depurar.

Compartir el montaje con otros usuarios

Por defecto, solamente el usuario que realizó el montaje puede acceder al contenido.

SSHFS dispone de la opción:

-o allow_other

Para utilizarla debemos habilitar en /etc/fuse.conf:

user_allow_other

Después podríamos montar así:

sshfs servidor-web:/var/www \
  "$HOME/remotos/servidor" \
  -o reconnect \
  -o allow_other \
  -o default_permissions

No debemos activar allow_other alegremente. Significa que otros usuarios locales podrían acceder al montaje, siempre dentro de los permisos aplicados. En un equipo compartido es necesario valorar cuidadosamente qué información estamos exponiendo.

Algunos problemas frecuentes

Connection reset by peer

Comprobamos primero la conexión SSH:

ssh -vv servidor-web

Puede tratarse de un puerto incorrecto, un bloqueo del cortafuegos, Fail2ban, un problema de autenticación o una configuración que impide utilizar SFTP.

read: Connection reset by peer

Puede existir una conexión inestable o un tiempo de espera del servidor. Probamos con:

sshfs servidor-web:/var/www \
  "$HOME/remotos/servidor" \
  -o reconnect \
  -o ServerAliveInterval=15 \
  -o ServerAliveCountMax=3

mountpoint is not empty

La carpeta local contiene archivos. Debemos usar otra carpeta vacía o mover previamente su contenido.

No debemos montar encima de archivos importantes, porque quedarán temporalmente ocultos mientras el sistema remoto permanezca montado.

Permission denied

Tenemos que distinguir entre dos problemas diferentes:

• El usuario no puede autenticarse mediante SSH.
• El usuario consigue conectarse, pero no tiene permisos sobre la ruta remota.

Podemos comprobarlo con:

ssh servidor-web 'ls -ld /var/www'

SSHFS no concede privilegios adicionales. Solamente permite realizar las operaciones autorizadas para la cuenta remota.

La carpeta parece bloqueada después de perder la conexión

Intentamos desmontarla:

fusermount3 -u "$HOME/remotos/servidor"

Si sigue ocupada, comprobamos qué procesos la utilizan:

fuser -vm "$HOME/remotos/servidor"

Limitaciones de SSHFS

SSHFS es muy cómodo, pero no es la mejor opción para todas las situaciones.

El rendimiento y la latencia dependen de la conexión SSH. Las aplicaciones que realizan miles de operaciones pequeñas pueden funcionar con lentitud. Tampoco es recomendable ejecutar directamente bases de datos sobre un montaje SSHFS.

Para sincronizar grandes cantidades de información puede resultar más apropiado rsync. Para compartir archivos de forma permanente dentro de una red local, NFS o Samba pueden ofrecer un comportamiento mejor. Para almacenamiento distribuido o cargas críticas necesitaremos soluciones diseñadas específicamente para ello.

El proyecto SSHFS continúa incluido en las principales distribuciones Linux y se utiliza desde hace años, pero actualmente dispone de pocos colaboradores activos. Su mantenimiento está centrado principalmente en aceptar contribuciones y solucionar problemas importantes.

Esto no significa que debamos dejar de utilizarlo, pero sí que conviene conocer sus limitaciones y probarlo cuidadosamente antes de incorporarlo a un servicio crítico.

Seguridad: cuatro consejos importantes

No necesitamos abrir un puerto especial para SSHFS: utiliza la conexión SSH existente. Si el servidor está en Internet, debemos proteger SSH correctamente.

Conviene aplicar estas medidas:

• Utilizar claves SSH protegidas mediante contraseña.
• Limitar los permisos del usuario remoto.
• Verificar la huella del servidor en la primera conexión.
• Mantener OpenSSH y SSHFS actualizados.
• Proteger el servidor con cortafuegos y herramientas como Fail2ban.
• No montar como root una carpeta que podemos montar como usuario.
• Utilizar ro cuando solo necesitemos consultar archivos.
• No compartir archivos pcap, claves privadas ni configuraciones sensibles.

Tampoco es buena idea crear una clave privada sin contraseña únicamente para ahorrar unos segundos. Podemos utilizar ssh-agent para conservar la comodidad sin dejar la clave completamente desprotegida.

Conclusión

SSHFS sigue siendo una de esas herramientas pequeñas que solucionan un problema muy concreto de forma elegante.

Si ya tenemos acceso SSH a un servidor, podemos montar uno de sus directorios con una sola orden y utilizarlo desde Linux como si fuese una carpeta local:

sshfs servidor-web:/var/www \
  "$HOME/remotos/servidor" \
  -o reconnect

No necesitamos configurar Samba, NFS ni otro servidor de archivos. Solo hacen falta SSH, SFTP, FUSE y una cuenta con los permisos adecuados.

Para trabajos cotidianos, pequeños servidores, máquinas virtuales o acceso ocasional a documentos remotos, SSHFS resulta cómodo y fácil de entender. Y cuando la conexión deja de ser ocasional, podemos automatizarla mediante una unidad de usuario de systemd.

Fuentes

• Proyecto oficial SSHFS
• Manual oficial de SSHFS
• Documentación de systemd.mount
• Paquete SSHFS en Debian
• Paquete fuse-sshfs en Fedora
• Paquete SSHFS en Arch Linux