Chi, come me, smanetta su più macchine in LAN (e magari anche oltre), sa quanto sia comodo poter accedere ai file remoti come se fossero locali. In un mondo dominato da NFS, Samba e mille altri protocolli, a volte la soluzione più semplice e affidabile è proprio davanti a noi: SSHFS, ovvero SSH FileSystem.

È uno di quegli strumenti che uso da anni, spesso dimentico che esista, ma che ogni volta mi salva la giornata. È minimale, funziona praticamente ovunque ci sia una shell SSH e non richiede alcuna configurazione server-side. Solo un sshd attivo e sei pronto.

Cos’è SSHFS

SSHFS è un filesystem basato su FUSE (Filesystem in Userspace) che consente di montare una directory remota accessibile via SSH come se fosse locale. La magia è che tutto passa da SSH, quindi erediti in automatico cifratura, autenticazione e compatibilità con firewall o NAT (basta che funzioni ssh).

In pratica: Se puoi fare ssh utente@server, puoi montare /home/utente come una directory sul tuo client.

Installazione

Su Debian (e derivate), è sufficiente:

apt install sshfs

Verifica che FUSE sia abilitato nel kernel (lo è praticamente sempre, di default).

Utilizzo base

Supponiamo di voler montare la home del nostro utente su un server remoto:

mkdir ~/remote
sshfs utente@server:/home/utente ~/remote

A questo punto, puoi navigare dentro ~/remote come se fosse una directory locale. E per smontare:

fusermount -u ~/remote

Oppure:

umount ~/remote

Esempi pratici

Montaggio persistente via fstab

Può sembrare controintuitivo montare qualcosa su SSH in fstab, ma si può fare (anche se con qualche accortezza):

sshfs#utente@server:/home/utente /mnt/remote fuse defaults,_netdev,IdentityFile=/home/user/.ssh/id_rsa,allow_other 0 0

NB: Serve allow_other in /etc/fuse.conf per permettere ad altri utenti di accedere al mount.

Automatizzare con systemd (spoiler: si può!)

Per chi ama systemd, è possibile creare un mount unit che si attiva solo quando serve, proprio come abbiamo fatto con rclone. Ma attenzione: serve sshfs in modalità non interattiva come per fstab (quindi key-based login obbligatorio).

Pregi

• Semplice e veloce: nessun demone da configurare lato server.
• Crittografia integrata: grazie a SSH.
• Compatibile con qualsiasi server SSH.
• Perfetto per accessi saltuari o su reti non affidabili.

Difetti

• Prestazioni limitate: non aspettarti il throughput di NFS o SMB.
• Non adatto a I/O pesante: database, VM o file system intensivi sono un no-go.
• Sensibile alla latenza: ogni operazione è un roundtrip SSH.
• Problemi con i permessi: specialmente se i uid/gid non corrispondono tra client e server.
• Raramente usato in produzione: meglio considerarlo un tool da sysadmin per usi personali o emergenze.

Quando (non) usarlo

Da usare:

• Per accedere rapidamente a file remoti in modo sicuro.
• Per editing occasionale su server remoti.
• Per backup manuali o sincronie rapide.

Da evitare:

• Su filesystem di rete ad alte prestazioni.
• Come storage per container, database o workload pesanti.

Usato sul campo: import VM in Proxmox

Di recente mi è capitato di dover importare alcune VM in un nodo Proxmox VE da un host KVM remoto. Invece di copiare i dischi con scp su uno storage condiviso o interno, ho montato direttamente la directory contenente i .qcow2 tramite SSHFS, e da lì ho fatto l’import con il classico:

qm set [VMID] --virtio0 [STORAGE]:0,import-from=/mnt/remote/vm-101-disk-0.qcow2 

Risultato? Niente tempi morti, niente doppia copia. Un mount veloce, e via.

Conclusione

SSHFS è uno di quei tool che ogni sysadmin dovrebbe avere nel proprio arsenale. Non sarà la soluzione definitiva per tutto, ma quando serve, c’è… E spesso è l’opzione più semplice da mettere in piedi in pochi secondi, senza sbattimenti.

Se vi capita spesso di dover copiare file avanti e indietro con scp o rsync, forse è il momento di dare una chance a SSHFS. Vi farà risparmiare tempo — e qualche imprecazione.

Le opinioni in quanto tali sono opinabili e nulla ti vieta di approfondire l’argomento.

Risorse:

• SSHFS
• Crowdsec
• Canale Telegram