Come montare automaticamente una directory SSHFS remota all'avvio in Debian

Si configura un mount SSHFS, si verifica che funzioni, si riavvia Debian e improvvisamente la directory remota è di nuovo vuota. Il comando manuale ha funzionato perché si era già effettuato l'accesso, la rete era già online e SSH poteva chiedere conferma se era necessaria una password o una chiave host. I mount all'avvio non offrono queste comodità.

La soluzione più affidabile consiste nel rendere l'autenticazione SSH non interattiva, creare una /etc/fstabvoce persistente e indicare a systemd che il filesystem dipende dalla rete. Questa guida inizia con la configurazione funzionante più semplice, per poi aggiungere opzioni per reti lente e sessioni SSH interrotte. Gli esempi utilizzano user@server.example.com:/srv/datacome directory remota e /mnt/remotecome punto di mount locale.

La pagina dei pacchetti di Debian elenca attualmente SSHFS 3.7.3 per Debian 12 (Bookworm), e SSHFS utilizza il sottosistema SFTP fornito da SSH. Consultare la pagina del pacchetto SSHFS di Debian e il manuale di SSHFS ufficiale . Le revisioni dei pacchetti variano tra le diverse versioni di Debian, ma l'approccio di avvio mount descritto di seguito si basa sul comportamento standard di fstab e systemd.

Perché un mount SSHFS funziona manualmente ma fallisce all'avvio?

La maggior parte dei fallimenti è dovuta a tre cause. In primo luogo, SSH potrebbe comunque richiedere una password, una passphrase o la conferma della chiave host al primo utilizzo. Un processo di avvio non dispone di un terminale in cui poter rispondere a tali richieste. In secondo luogo, il mount può iniziare prima che la rete o il DNS siano completamente utilizzabili. In terzo luogo, una connessione SSH di lunga durata può successivamente diventare obsoleta in seguito a un'interruzione di rete.

La documentazione di systemd di Debian spiega che l' _netdevopzione forza un mount a essere trattato come un mount di rete. I mount di rete sono ordinati dopo network-online.target. La stessa documentazione nota che /etc/fstable voci vengono convertite in unità di mount native di systemd all'avvio. Vedi systemd.mount(5) in Debian .

1. Installa SSHFS e crea il punto di montaggio

Installa il client SSHFS precompilato e crea la directory locale che renderà accessibili i file remoti:

sudo apt update
sudo apt install sshfs
sudo mkdir -p /mnt/remote

SSHFS è basato su FUSE, l'interfaccia Linux Filesystem in Userspace. Su Debian 12, il sshfspacchetto dipende da FUSE 3 e dal client OpenSSH.

2. Configura l'autenticazione SSH che può essere eseguita senza prompt

Per un mount a livello di sistema avviato da systemd, una chiave dedicata di proprietà di root è semplice da ottenere perché il gestore di mount viene eseguito come root. Generane una senza passphrase solo se la macchina stessa è considerata affidabile e la chiave è limitata a questo scopo:

sudo ssh-keygen -t ed25519 -f /root/.ssh/sshfs_remote
sudo ssh-copy-id -i /root/.ssh/sshfs_remote.pub user@server.example.com

Il secondo comando richiede normalmente la password dell'account remoto una sola volta. Quindi verifica l'identità esatta in modalità non interattiva:

sudo ssh -i /root/.ssh/sshfs_remote -o BatchMode=yes user@server.example.com true

Se il comando termina correttamente senza richiedere conferma, l'autenticazione è pronta per l'avvio. Se viene richiesto di confermare l'impronta digitale del server, connettersi una volta in modalità interattiva come root, verificare l'impronta digitale rispetto a una fonte attendibile e accettarla. Non aggirare gli errori della chiave host disabilitando la verifica dell'host.

La documentazione di OpenSSH BatchMode=yesè specifica per gli script e i processi batch perché disabilita le richieste di password e di conferma. Le chiavi host vengono confrontate con il file dell'utente known_hosts. Vedi il manuale Debian ssh(1) e ssh_config(5) .

3. Conferma manualmente il mount SSHFS prima di modificare fstab

Non eseguire il debug dell'ordine di avvio finché il comando SSHFS di base non funziona. Monta la directory una sola volta utilizzando la stessa chiave:

sudo sshfs user@server.example.com:/srv/data /mnt/remote   -o IdentityFile=/root/.ssh/sshfs_remote   -o reconnect   -o ServerAliveInterval=15   -o ServerAliveCountMax=3

Verifica di poter elencare i file remoti, quindi smonta il repository prima di testare fstab:

ls -la /mnt/remote
sudo fusermount3 -u /mnt/remote

Il manuale SSHFS a monte raccomanda reconnectdi ristabilire le connessioni interrotte. Spiega anche che ServerAliveIntervalpuò impedire un mount apparentemente bloccato quando una connessione SSH inattiva viene interrotta silenziosamente. Con un intervallo di 15 secondi e il conteggio predefinito di OpenSSH di tre probe senza risposta, una connessione interrotta viene rilevata in circa 45 secondi; qui il conteggio è scritto esplicitamente in modo che il comportamento sia chiaro.

4. Aggiungere una voce SSHFS permanente a /etc/fstab

Esegui un backup del file prima di modificarlo:

sudo cp /etc/fstab /etc/fstab.backup
sudo nano /etc/fstab

Aggiungi una riga:

user@server.example.com:/srv/data /mnt/remote fuse.sshfs _netdev,IdentityFile=/root/.ssh/sshfs_remote,BatchMode=yes,reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,default_permissions 0 0

Il fuse.sshfssottotipo è compreso dagli strumenti di montaggio di Debian. Il manuale SSHFS upstream lo documenta anche sshfscome tipo di filesystem fstab e ne nota la compatibilità. Il manuale fstab(5)fuse.sshfs di Debian descrive i sei campi fstab e raccomanda la notazione del sottotipo di filesystem come .fuse.sshfs

5. Verifica la voce fstab prima di riavviare

Un errore di battitura /etc/fstabè molto più facile da correggere prima di un riavvio. Chiedi a systemd di ricaricare le unità di montaggio generate, quindi verifica la voce:

sudo systemctl daemon-reload
sudo mount -a
findmnt -T /mnt/remote
ls -la /mnt/remote

Se mount -anon restituisce alcun errore e findmntsegnala , la sintassi fstab viene accettata e il filesystem viene montato. Il manuale mount(8)fuse.sshfs di Debian conferma che monta i filesystem fstab tranne le voci contrassegnate .mount -anoauto

E se la rete non fosse pronta in tempo?

_netdevFornisce a systemd la semantica di ordinamento corretta, ma network-online.targetla sua accuratezza dipende dalla qualità del servizio di gestione della rete che la fornisce. Wi-Fi, VPN, ritardi DHCP, ritardi DNS e stack di rete insoliti possono comunque rendere inaffidabile un montaggio di avvio immediato.

In tal caso, usa l'automounting di systemd in modo che il processo di avvio crei un punto di automount e stabilisca la connessione SSHFS solo quando qualcosa accede per la prima volta /mnt/remote. Aggiungi x-systemd.automountalle opzioni:

user@server.example.com:/srv/data /mnt/remote fuse.sshfs _netdev,x-systemd.automount,IdentityFile=/root/.ssh/sshfs_remote,BatchMode=yes,reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,default_permissions 0 0

Questa è spesso la scelta migliore per laptop, sistemi Wi-Fi o server in cui l'host remoto potrebbe occasionalmente non essere disponibile. Modifica leggermente la semantica: l'automount viene preparato all'avvio, ma la connessione SSH effettiva viene stabilita al primo accesso. Se un'applicazione richiede assolutamente che la directory remota sia connessa prima di avviarsi, mantieni il normale mount di rete e fai in modo che l'unità systemd di tale applicazione dipenda dall'unità di mount.

Hai bisogno di allow_other?

Per impostazione predefinita, un mount FUSE è accessibile solo con le autorizzazioni associate al contesto di mount. Il manuale di SSHFS documenta allow_othercome consentire l'accesso ad altri utenti locali. Non aggiungerlo a meno che un servizio o un altro account non necessiti effettivamente dei file montati.

Se si utilizza allow_other, esaminare /etc/fuse.confprima le implicazioni di sicurezza di FUSE. L'abbinamento con default_permissionsè generalmente appropriato in modo che i controlli dei permessi Unix locali non vengano saltati. L'account SSH remoto determina comunque in ultima analisi quali operazioni il server consente.

Risoluzione dei problemi relativi agli errori SSHFS all'avvio

La montatura attende una password

Ripeti esattamente il test non interattivo con sudo ssh ... -o BatchMode=yes. Se fallisce, correggi l'autenticazione con chiave pubblica prima di modificare systemd. Una chiave protetta da una passphrase richiederà anche un agente o un altro meccanismo di segreto all'avvio; un semplice mount fstab non può digitare la passphrase per te.

Verifica della chiave host non riuscita

Non impostarlo StrictHostKeyChecking=nocome soluzione definitiva. Verifica se il server è stato ricostruito o se la sua chiave host è stata modificata legittimamente. Il controllo della chiave host SSH è una misura di sicurezza contro i tentativi di impersonificazione e gli attacchi man-in-the-middle.

Il mount funziona dopo l'accesso, ma non durante l'avvio.

Controlla il nome dell'unità generata e il relativo registro. Per /mnt/remote, systemd normalmente esegue l'escape del percorso a mnt-remote.mount:

systemctl status mnt-remote.mount
journalctl -b -u mnt-remote.mount

Se hai aggiunto x-systemd.automount, controlla anche:

systemctl status mnt-remote.automount

L'accesso si blocca dopo la scomparsa del server o della rete.

Keep reconnecte SSH keepalive abilitati. Il manuale SSHFS originale avverte che le operazioni sul filesystem possono bloccarsi indefinitamente se non viene rilevata un'interruzione di connessione. I keepalive limitano il rilevamento degli errori, ma qualsiasi operazione di I/O in corso al momento dell'interruzione della connessione può comunque fallire e potrebbe essere necessario un nuovo tentativo da parte dell'applicazione.

Come verificare che il mount sopravviva effettivamente a un riavvio

Una volta mount -acompletata l'operazione, riavviare la macchina:

sudo reboot

Dopo aver ristabilito la connessione, esegui questi controlli:

findmnt -T /mnt/remote
systemctl is-active mnt-remote.mount
ls -la /mnt/remote

Se hai scelto x-systemd.automount, l'unità di montaggio potrebbe essere inattiva fino al primo accesso. Controlla prima il montaggio automatico, poi attivalo con ls:

systemctl is-active mnt-remote.automount
ls -la /mnt/remote
findmnt -T /mnt/remote

Una configurazione corretta presenta quattro proprietà osservabili: l'autenticazione SSH si completa senza interazione, la voce fstab risulta corretta mount -a, systemd riconosce il mount come dipendente dalla rete e i file remoti sono raggiungibili dopo un riavvio pulito. Se uno qualsiasi di questi controlli fallisce, è necessario risolvere il problema direttamente a quel livello anziché aggiungere opzioni di mount a caso.