SSHFS - o fork do SSHFS atualmente mantido

• SSHFS permite montar sistemas de arquivos remotos usando SFTP, e como a maioria dos servidores SSH oferece e ativa acesso SFTP por padrão, ele pode ser usado sem trabalho no lado do servidor
• O fork de manutenção deadbeefsociety/sshfs foi arquivado porque o SSHFS não está mais abandonado; o alvo de uso é libfuse/sshfs
• O SSHFS está incluído nas principais distribuições Linux e tem um longo histórico de uso em produção em vários sistemas, mas atualmente não há contribuidores ativos de forma regular, e os problemas conhecidos estão no bugtracker
• O mantenedor atual continua aplicando pull requests e fazendo lançamentos regulares, mas não tem capacidade de desenvolvimento além de lidar com problemas de alto impacto; relatórios de bugs sem pull request ou problemas não críticos provavelmente não receberão resposta
• O formato básico de execução é sshfs [user@]hostname:[directory] mountpoint, sendo recomendado executá-lo como usuário comum, e o mountpoint deve pertencer a esse usuário
  • Se o nome de usuário for omitido, será usado o nome do usuário local
  • Se o diretório for omitido, será montado o diretório home remoto
  • Se for necessária senha, o ssh executado pelo sshfs solicitará a senha
• É possível especificar várias opções do ssh, incluindo -oport=PORT; para desmontar, use fusermount -u mountpoint no Linux e umount mountpoint em BSD e macOS
• Para compilar, são necessários libfuse 3.1.0 ou superior, ou uma interface compatível com libfuse3, Glib com headers de desenvolvimento, Meson 0.38 ou superior e Ninja; para executar os testes, é necessário o módulo Python py.test

[GN⁺]

Opiniões no Hacker News

• Se você quer algo que funcione no espaço do usuário e Emacs for uma opção para você, existe o TRAMP, “Transparent Remote (file) Access, Multiple Protocol”: https://www.gnu.org/software/tramp/
  Uso com frequência para acessar arquivos de servidores a partir de um MacBook Pro

  • O melhor do TRAMP é poder dar cd para um diretório no sistema remoto e, a partir do diretório de trabalho atual, fazer cp de arquivos para a máquina local ou para outro remoto, e também copiar no sentido inverso, do local para o diretório de trabalho remoto atual
    Antes de usar TRAMP, eu entrava por SSH no remoto, usava cd e ls para encontrar o local de cópia, encerrava a sessão SSH, transferia os arquivos com scp ou rsync e, em geral, precisava entrar de novo por SSH
  • Como referência, uma boa parte dos recursos do Emacs, talvez a maioria ou todos, funciona de forma transparente com o Tramp. Isso inclui dired, eshell e magit

• Interessante. Sempre achei que o sshfs fizesse parte do OpenSSH, mas todo dia se aprende algo novo
  O sshfs usado no Slackware também parece estar abandonado: https://github.com/libfuse/sshfs
  Pela citação no link, fico me perguntando se este projeto será o “próximo da fila”

  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.
  Também fico imaginando se ele ficou abandonado por causa da reorganização da RHEL, como aconteceu com o Bluetooth

  • Parece algo que faria sentido para os mantenedores do OpenSSH assumirem. Eu também achava que isso fosse uma infraestrutura SSH central do Linux

• Só como referência, depois de usar macFUSE + sshfs por anos no Mac, hoje só instalo a excelente ferramenta Mountain Duck. Dá para acessar endpoints SFTP pelo Finder e por pontos de montagem
  É um software muito bom e, para mim, indispensável

  • Recentemente voltei a ser cliente da rsync.net e, ao passar pela documentação, fiquei um pouco surpreso ao ver Fuse/sshfs ainda listado como a opção recomendada de integração com Mac: https://www.rsync.net/resources/howto/mac_sshfs.html
    Por causa disso, há alguns meses experimentei ExpanDrive/StrongSync, e só ouvi falar do Mountain Duck agora. Gosto do Cyberduck. Pretendo testar agora; se ele estiver funcionando bem, seria ótimo atualizar essa página para outras pessoas. Fora isso, sou um cliente satisfeito
  • Para deixar registrado, agora existe https://www.fuse-t.org/ para macOS. Ele funciona sem extensão de kernel; em segundo plano, sobe um servidor NFS local, e o macOS se conecta a ele
    A implementação de sshfs também está em https://github.com/macos-fuse-t/fuse-t/wiki#sample-filesyste...
  • Eu também uso principalmente o Mountain Duck. Dito isso, no VSCode a extensão Remote SSH da Microsoft ajuda bastante ao trabalhar com repositórios em VMs ou outras máquinas remotas
    No macOS, Libfuse/SSHFS ficou bem trabalhoso de usar de alguns anos para cá, e foi por isso que eu também acabei migrando para o Mountain Duck

• É uma pena que o sshfs não seja mais mantido. Na faculdade, eu usava sshfs para editar código com meus vários plugins do Vim, sem precisar instalar todos os plugins do Vim no servidor remoto de computação
  Fiquei surpreso com o quanto o sistema funcionava de forma fluida

• Acho que SFTP é um protocolo bom e subestimado. Há casos em que faz mais sentido espelhar em duas vias do que replicar uma árvore de arquivos de um lado para o outro
  Depois de fazer um fork do código do SSHFS e examiná-lo, venho reunindo e mantendo materiais relacionados e ideias pessoais em https://hackmd.io/@q/sftp-over-ws

  • SFTP é uma grande melhoria em relação ao FTP, mas ainda há muito potencial não realizado no lado do servidor, então isso não se resolve apenas criando clientes melhores
    Tanto o OpenSSH quanto o servidor GNU lsh oferecem apenas versões antigas do protocolo. Provavelmente v2. Essa antiguidade é uma escolha deliberada: https://marc.info/?l=openssh-unix-dev&m=168488976013498&w=2

• A combinação técnica é um pouco diferente, mas venho usando NFS sobre WireGuard há algum tempo com bastante satisfação

  • Quando o canal TCP é redefinido, o NFS lida com a reconexão de forma mais elegante, e isso é uma grande vantagem
    Ele também implementa mais recursos de sistema de arquivos, então o relatório do df reflete corretamente o uso do sistema de arquivos remoto
    Além disso, o NFSv4 oferece “delegations”, permitindo conceder ao cliente controle total de um arquivo na forma de um lease que expira. Clientes NFS modernos também têm “polite delegations”, que estendem implicitamente o período do lease
    O SSHFS é muito conveniente para uma montagem “rápida e meio improvisada” com configuração mínima
  • Eu fui na direção oposta. A infraestrutura de VPN é muito estável, mas mudei para uma abordagem de armazenamento
    Depois que passei a sincronizar arquivos com um utilitário de armazenamento DVFS bem simples, não olhei mais para trás. Gosto de ter várias cópias espalhadas por aí
  • Há alguns anos troquei sshfs por NFSv4 + WireGuard, e funciona muito bem

• Hoje em dia, quando preciso de funcionalidades do sshfs, uso principalmente rclone mount. O desempenho, a estabilidade e as opções de cache são melhores

  • Porém, o rclone não consegue escrever no meio de um arquivo sem transferir o arquivo inteiro. Esse é o maior problema
    O sshfs também pode ter a mesma limitação

• Infelizmente, esse fork não parece muito ativo. O último commit é de março, e quase não há atividade em PRs e issues
  Eu não apostaria minhas fichas nele

  • Se for um projeto estável, que nível de atividade se espera?
  • Pela definição “à la JavaScript” de “ativo”, é mexer em algo que funciona bem e acabar quebrando

• O Nautilus, ou seja, o explorador de arquivos do Ubuntu, oferece suporte à montagem de pastas SFTP. Parece usar gvfs internamente
  Como o SFTP usa uma conexão SSH para transferência de arquivos, não vi diferença de UI em comparação com o SSHFS

  • Dá para navegar por um endpoint SFTP na GUI do Nautilus, mas ele também cria ao mesmo tempo um ponto de montagem do sistema de arquivos que possa ser usado no terminal?
    Não me lembro bem

• Alguém já usou rclone ou sshfs com macFUSE/osxfuse no Mac OS X?

  • Uso o Macfuse para conectar todos os meus servidores como se fossem pastas locais. Funciona bem
    Tenho um pequeno script para cada servidor. Por exemplo, 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
  • No M1, uso macFUSE e sshfs para montar o drive de uma máquina Linux do escritório. No geral é ok, mas tem aquelas engasgadas características
    O processo de configuração pareceu uma aventura e algumas vezes fiquei me perguntando se aquilo estava certo, mas segui em frente e funcionou bem
  • Veja meu comentário principal mais acima. A resposta é “Mountain Duck”
  • No Monterey, M1, o sshfs funciona, mas é meio lento