SSHFS - el fork de SSHFS que se mantiene actualmente

• SSHFS permite montar sistemas de archivos remotos usando SFTP, y como la mayoría de los servidores SSH soportan y tienen habilitado por defecto el acceso por SFTP, se puede usar sin hacer trabajo del lado del servidor
• El fork de mantenimiento deadbeefsociety/sshfs fue archivado porque SSHFS ya no está abandonado; el proyecto que debe usarse es libfuse/sshfs
• SSHFS está incluido en las principales distribuciones de Linux y tiene un largo historial de uso en producción en varios sistemas, pero actualmente no hay colaboradores activos de forma regular y los problemas conocidos están en el bugtracker
• El mantenedor actual sigue aplicando pull requests y haciendo lanzamientos periódicos, pero no tiene capacidad de desarrollo más allá de atender problemas de alto impacto; es muy probable que los reportes de errores sin pull request o los problemas no críticos no reciban respuesta
• El formato básico de ejecución es sshfs [user@]hostname:[directory] mountpoint, y se recomienda ejecutarlo como usuario normal; mountpoint debe pertenecer a ese usuario
  • Si se omite el nombre de usuario, se usa el nombre de usuario local
  • Si se omite el directorio, se monta el directorio home remoto
  • Si se necesita contraseña, ssh ejecutado por sshfs la solicitará
• Se pueden especificar varias opciones de ssh, incluyendo -oport=PORT, y para desmontar se usa fusermount -u mountpoint en Linux y umount mountpoint en BSD y macOS
• Para compilar se requiere libfuse 3.1.0 o superior, o una interfaz compatible con libfuse3, Glib con headers de desarrollo, Meson 0.38 o superior y Ninja; para ejecutar pruebas se necesita el módulo de Python py.test

[GN⁺]

Opiniones en Hacker News

• Si quieres que funcione en espacio de usuario y Emacs te parece bien, existe TRAMP, “Transparent Remote (file) Access, Multiple Protocol”: https://www.gnu.org/software/tramp/
  Lo uso con frecuencia para acceder a archivos en servidores desde mi MacBook Pro

  • Lo mejor de TRAMP es que, después de hacer cd a un directorio de un sistema remoto, puedes hacer cp de archivos desde el directorio de trabajo actual a tu máquina local o a otro remoto, y también al revés: desde local al directorio de trabajo remoto actual.
    Antes de usar TRAMP, tenía que entrar por SSH al remoto, buscar el destino de copia con cd y ls, cerrar la sesión SSH, mover los archivos con scp o rsync y, por lo general, volver a entrar por SSH
  • Como referencia, una buena parte de las funciones de Emacs, quizá la mayoría o todas, funcionan de forma transparente con Tramp. Eso incluye dired, eshell y magit

• Interesante. Siempre pensé que sshfs era parte de OpenSSH, pero todos los días se aprende algo nuevo
  El sshfs que se usa en Slackware también parece estar abandonado: https://github.com/libfuse/sshfs
  Viendo la cita del enlace, me pregunto si este proyecto será ese “siguiente en tomar la posta”

  If you would like to take over this project, you are welcome to do so. Please fork it and develop the fork for a while. Once there has been 6 months of reasonable activity, please contact [e-mail] and I'll be happy to give you ownership of this repository or replace with a pointer to the fork.
  También me pregunto si quedó abandonado por la reestructuración de RHEL, como pasó con Bluetooth

  • Parece algo muy adecuado para que lo mantengan los responsables de OpenSSH. Yo también pensaba que esto era parte de la infraestructura SSH central de Linux

• Como referencia, en Mac usé macFUSE + sshfs durante años, pero ahora simplemente instalo la excelente herramienta Mountain Duck. Permite acceder a endpoints SFTP desde Finder y como puntos de montaje
  Es un software muy bueno y para mí es indispensable

  • Hace poco volví a ser cliente de rsync.net y, al revisar la documentación, me sorprendió un poco ver que todavía aparece Fuse/sshfs como opción recomendada de integración con Mac: https://www.rsync.net/resources/howto/mac_sshfs.html
    Hace unos meses probé ExpanDrive/StrongSync por esto, y recién ahora me entero de Mountain Duck. Me gusta Cyberduck. Pienso probarlo; si funciona bien, sería bueno que actualicen esa página para otras personas. Por lo demás, soy un cliente satisfecho
  • Para dejarlo registrado, macOS ahora cuenta con https://www.fuse-t.org/. Funciona sin extensiones de kernel: levanta un servidor NFS local en segundo plano y macOS se conecta a él
    También hay una implementación de sshfs en https://github.com/macos-fuse-t/fuse-t/wiki#sample-filesyste...
  • Yo también uso principalmente Mountain Duck. Dicho eso, en VSCode la extensión Remote SSH de Microsoft ayuda mucho para trabajar con repositorios en una VM u otra máquina remota
    En macOS, Libfuse/SSHFS se volvió bastante pesado de usar desde hace unos años, y por eso también terminé pasándome a Mountain Duck

• Qué lástima que sshfs ya no reciba mantenimiento. En la universidad lo usaba para editar código con mis numerosos plugins de Vim sin tener que instalarlos todos en el servidor remoto de cómputo
  Me sorprendió lo fluido que funcionaba el sistema

• Creo que SFTP es un buen protocolo, pero subestimado. Hay casos en los que tiene más sentido reflejar archivos en ambas direcciones que replicar un árbol de archivos de un lado al otro
  Después de hacer un fork del código de SSHFS y revisarlo, estoy manteniendo materiales relacionados y algunas ideas personales en https://hackmd.io/@q/sftp-over-ws

  • SFTP fue una gran mejora frente a FTP, pero del lado del servidor todavía tiene mucho potencial no realizado, así que no se soluciona solo creando mejores clientes
    Tanto OpenSSH como el servidor GNU lsh solo ofrecen versiones antiguas del protocolo. Probablemente sea v2. Esa antigüedad es una decisión deliberada: https://marc.info/?l=openssh-unix-dev&m=168488976013498&w=2

• La combinación de tecnologías es un poco distinta, pero desde hace un tiempo uso NFS sobre WireGuard y estoy bastante conforme

  • Cuando se restablece un canal TCP, NFS maneja la reconexión de forma más elegante, y eso es una gran ventaja
    También implementa más funciones de sistema de archivos, por lo que el reporte de df refleja correctamente el uso del sistema de archivos remoto
    Además, NFSv4 ofrece “delegations”, que permiten darle al cliente control total de un archivo en forma de un arrendamiento que expira. Los clientes NFS modernos también tienen “polite delegations”, que extienden implícitamente el período del arrendamiento
    SSHFS es muy práctico para un montaje “rápido y sucio” con configuración mínima
  • Yo fui en la dirección opuesta. La infraestructura de VPN es muy estable, pero pasé a un enfoque de almacenamiento
    Sincronizo archivos con una utilidad de almacenamiento DVFS muy simple y no volví a mirar atrás. Me gusta tener varias copias en distintos lugares
  • Hace unos años cambié de sshfs a NFSv4 + WireGuard, y funciona muy bien

• Actualmente, cuando necesito funcionalidad de sshfs, uso principalmente rclone mount. Tiene mejor rendimiento, estabilidad y opciones de caché.

  • Sin embargo, rclone no puede escribir en medio de un archivo sin transferir el archivo completo. Ese es el mayor problema.
    sshfs también podría tener la misma limitación.

• Lamentablemente, este fork no parece muy activo. El último commit fue en marzo, y casi no hay actividad en PR ni issues.
  No pondría mis expectativas en esto.

  • Si se trata de un proyecto estable, ¿qué nivel de actividad se esperaría?
  • “Actividad”, según la definición al estilo JavaScript, es tocar algo que funciona bien y romperlo.

• Nautilus, es decir, el explorador de archivos de Ubuntu, admite montar carpetas SFTP. Parece que internamente usa gvfs.
  Como SFTP usa una conexión SSH para transferir archivos, no noté diferencias de UI frente a SSHFS.

  • En la GUI de Nautilus se puede navegar un endpoint SFTP, pero ¿también crea al mismo tiempo un punto de montaje del sistema de archivos que pueda usarse desde la terminal?
    No lo recuerdo bien.

• ¿Alguien ha usado rclone o sshfs con macFUSE/osxfuse en Mac OS X?

  • Uso Macfuse para montar todos mis servidores como carpetas locales. Funciona bien.
    Tengo un pequeño script para cada servidor. Por ejemplo, mount_fooserver.sh:
    umount -f ~/mounts/fooserver
sshfs -o kill_on_unmount,reconnect,allow_other,defer_permissions,direct_io username@server:/ ~/mounts/fooserver -ovolname=foo
  • En una M1 uso macFUSE y sshfs para montar el disco de una máquina Linux de la oficina. En general va bien, aunque tiene sus crujidos característicos.
    El proceso de configuración fue toda una aventura, y varias veces dudé si eso era lo correcto, pero seguí adelante y terminó funcionando bien.
  • Mira mi comentario principal de más arriba. La respuesta es “Mountain Duck”.
  • En Monterey, M1, sshfs funciona, pero es algo lento.