Hoe koppel je automatisch een externe SSHFS-directory bij het opstarten in Debian?

Je configureert een SSHFS-mount, controleert of deze werkt, herstart Debian en plotseling is de externe map weer leeg. De handmatige opdracht werkte omdat je was ingelogd, het netwerk al online was en SSH om bevestiging kon vragen als er een wachtwoord of host-sleutel nodig was. Mounts die tijdens het opstarten worden geconfigureerd, bieden die gemakken niet.

De betrouwbare oplossing is om SSH-authenticatie niet-interactief te maken, een permanente /etc/fstabvermelding te creëren en systemd te laten weten dat het bestandssysteem afhankelijk is van het netwerk. Deze handleiding begint met de eenvoudigste werkende configuratie en voegt vervolgens opties toe voor trage netwerken en verbroken SSH-sessies. De voorbeelden gebruiken user@server.example.com:/srv/dataals de externe map en /mnt/remoteals het lokale mountpunt.

Op de pakketpagina van Debian staat momenteel SSHFS 3.7.3 vermeld voor Debian 12 (Bookworm). SSHFS maakt gebruik van het SFTP-subsysteem van SSH. Zie de Debian SSHFS-pakketpagina en de officiële SSHFS-handleiding . Pakketversies verschillen per Debian-release, maar de onderstaande methode voor het mounten van de bootloader is gebaseerd op standaardgedrag van fstab en systemd.

Waarom werkt een SSHFS-mount wel handmatig, maar niet bij het opstarten?

Drie oorzaken zijn verantwoordelijk voor de meeste mislukkingen. Ten eerste kan SSH nog steeds een wachtwoord, sleutelwachtwoordzin of bevestiging van de hostsleutel vereisen. Een opstartproces heeft geen terminal waar het deze prompts kan beantwoorden. Ten tweede kan het mounten beginnen voordat de netwerkverbinding of DNS volledig bruikbaar is. Ten derde kan een langdurige SSH-verbinding na een netwerkonderbreking later verlopen.

De systemd-documentatie van Debian legt uit dat de _netdevoptie ervoor zorgt dat een mount als een netwerkmount wordt behandeld. Netwerkmounts worden na de standaard mounts geplaatst network-online.target. Dezelfde documentatie vermeldt dat /etc/fstabde entries bij het opstarten worden omgezet in native systemd-mountunits. Zie systemd.mount(5) in Debian .

1. Installeer SSHFS en maak het koppelpunt aan.

Installeer de meegeleverde SSHFS-client en maak de lokale map aan die de externe bestanden beschikbaar zal maken:

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

SSHFS is gebouwd op FUSE, de Linux Filesystem in Userspace interface. Op Debian 12 is het sshfspakket afhankelijk van FUSE 3 en de OpenSSH-client.

2. Stel SSH-authenticatie in die zonder prompt kan worden uitgevoerd.

Voor een systeemwijde mount die door systemd wordt gestart, is een speciale sleutel in root-bezit eenvoudig te verkrijgen, omdat de mount-helper als root draait. Genereer er een zonder wachtwoordzin alleen als de machine zelf vertrouwd is en de sleutel uitsluitend voor dit doel wordt gebruikt.

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

Het tweede commando vraagt ​​normaal gesproken eenmaal om het wachtwoord van het externe account. Test vervolgens de exacte identiteit op een niet-interactieve manier:

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

Als die opdracht succesvol wordt uitgevoerd zonder prompt, is de authenticatie gereed voor het opstarten. Als er wordt gevraagd om de servervingerafdruk te bevestigen, maak dan eenmaal interactief verbinding als root, verifieer de vingerafdruk aan de hand van een vertrouwde bron en accepteer deze. Omzeil fouten met de hostsleutel niet door hostverificatie uit te schakelen.

OpenSSH-documentatie BatchMode=yesis specifiek bedoeld voor scripts en batchtaken, omdat het wachtwoord- en bevestigingsprompts uitschakelt. Hostsleutels worden gecontroleerd aan de hand van het gebruikersbestand known_hosts. Zie de Debian ssh(1)-handleiding en ssh_config(5) .

3. Controleer handmatig of de SSHFS-mount is aangemaakt voordat u fstab bewerkt.

Debug de opstartvolgorde niet totdat de basis SSHFS-opdracht werkt. Koppel de directory eenmaal met dezelfde sleutel:

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

Controleer of je de bestanden op de externe schijf kunt weergeven en ontkoppel deze vervolgens voordat je fstab test:

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

De SSHFS-handleiding van de upstream-ontwikkelaars beveelt aan reconnectom onderbroken verbindingen te herstellen. Hierin wordt ook uitgelegd dat dit ServerAliveIntervalkan voorkomen dat een mount vastloopt wanneer een inactieve SSH-verbinding stilletjes wordt verbroken. Met een interval van 15 seconden en de standaard OpenSSH-teller van drie onbeantwoorde probes, wordt een verbroken verbinding na ongeveer 45 seconden gedetecteerd; de teller wordt hier expliciet vermeld, zodat het gedrag duidelijk is.

4. Voeg een permanente SSHFS-vermelding toe aan /etc/fstab

Maak een back-up van het bestand voordat je het bewerkt:

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

Voeg één regel toe:

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

Het fuse.sshfssubtype wordt herkend door de mount-tools van Debian. De upstream SSHFS-handleiding documenteert het ook sshfsals een fstab-bestandssysteemtype en vermeldt de compatibiliteit. De fstab(5)-handleidingfuse.sshfs van Debian beschrijft de zes fstab-velden en beveelt een notatie voor bestandssysteemsubtypen aan, zoals .fuse.sshfs

5. Test de fstab-vermelding voordat u opnieuw opstart.

Een typefout /etc/fstabis veel gemakkelijker te corrigeren vóór een herstart. Vraag systemd om de gegenereerde mount-eenheden opnieuw te laden en test vervolgens de invoer:

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

Als mount -aer geen foutmelding wordt gegeven en findmntdit wordt gerapporteerd fuse.sshfs, wordt de fstab-syntaxis geaccepteerd en wordt het bestandssysteem aangekoppeld. De handleiding van Debian mount(8) bevestigt dat mount -afstab-bestandssystemen worden aangekoppeld, behalve vermeldingen die zijn gemarkeerd met noauto.

Wat als het netwerk niet snel genoeg klaar is?

_netdevDit geeft systemd de juiste volgorde van processen, maar network-online.targetde nauwkeurigheid hangt af van de netwerkbeheerservice die dit mogelijk maakt. Wi-Fi, VPN's, DHCP-vertragingen, DNS-vertragingen en ongebruikelijke netwerkstacks kunnen er nog steeds voor zorgen dat een directe bootmount onbetrouwbaar is.

Gebruik in dat geval systemd automounting, zodat het opstartproces een automountpunt aanmaakt en de SSHFS-verbinding pas tot stand brengt wanneer er voor het eerst toegang tot wordt verkregen /mnt/remote. Voeg het volgende toe x-systemd.automountaan de opties:

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

Dit is vaak de betere keuze voor laptops, wifi-systemen of servers waarbij de externe host af en toe niet beschikbaar kan zijn. Het verandert de semantiek enigszins: de automount wordt tijdens het opstarten voorbereid, maar de daadwerkelijke SSH-verbinding wordt pas bij de eerste toegang tot stand gebracht. Als een applicatie absoluut vereist dat de externe map is verbonden voordat deze start, behoud dan de normale netwerkmount en laat de systemd-unit van die applicatie afhankelijk zijn van de mount-unit.

Heb je allow_other nodig?

Standaard is een FUSE-mount alleen toegankelijk met de machtigingen die zijn gekoppeld aan de mountcontext. De SSHFS-handleiding beschrijft allow_otherhoe toegang door andere lokale gebruikers kan worden toegestaan. Voeg deze machtiging alleen toe als een service of een ander account de gemounte bestanden echt nodig heeft.

Als u het gebruikt allow_other, bekijk /etc/fuse.confdan eerst de beveiligingsimplicaties van FUSE. Het default_permissionsis over het algemeen aan te raden om het te combineren met FUSE, zodat lokale Unix-toegangscontroles niet worden overgeslagen. Het externe SSH-account bepaalt uiteindelijk nog steeds welke bewerkingen de server toestaat.

Problemen met SSHFS-opstartfouten oplossen

De mount wacht op een wachtwoord.

Herhaal de exacte niet-interactieve test met sudo ssh ... -o BatchMode=yes. Als deze mislukt, corrigeer dan de authenticatie met publieke sleutels voordat je systemd aanpast. Een sleutel die beveiligd is met een wachtwoordzin vereist ook een agent of een ander mechanisme voor geheime sleutels tijdens het opstarten; een eenvoudige fstab-mount kan de wachtwoordzin niet voor je invoeren.

Hostsleutelverificatie mislukt

Beschouw dit niet StrictHostKeyChecking=noals een algemene oplossing. Controleer of de server opnieuw is opgebouwd of dat de host-sleutel rechtmatig is gewijzigd. Het controleren van de SSH-host-sleutel is een beveiligingsmaatregel tegen identiteitsfraude en man-in-the-middle-aanvallen.

Het mounten werkt na het inloggen, maar niet tijdens het opstarten.

Controleer de gegenereerde eenheidsnaam en het bijbehorende logboek. Voor /mnt/remote, ontsnapt systemd normaal gesproken aan het pad naar mnt-remote.mount:

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

Als je dit hebt toegevoegd x-systemd.automount, controleer dan ook:

systemctl status mnt-remote.automount

De toegang blijft hangen nadat de server of het netwerk niet meer bereikbaar is.

Keep reconnecten SSH keepalives ingeschakeld. De SSHFS-handleiding waarschuwt dat bestandssysteemoperaties oneindig lang kunnen blokkeren als een verbroken verbinding niet wordt gedetecteerd. Keepalives beperken de foutdetectie, maar alle I/O-bewerkingen die gaande waren toen de verbinding verbroken werd, kunnen nog steeds mislukken en moeten mogelijk opnieuw door de applicatie worden uitgevoerd.

Hoe controleer je of de mount daadwerkelijk blijft werken na een herstart?

Als mount -ahet gelukt is, start de machine dan opnieuw op:

sudo reboot

Voer na het opnieuw tot stand brengen van de verbinding de volgende controles uit:

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

Als u hiervoor kiest x-systemd.automount, kan de montage-eenheid inactief zijn tot de eerste keer dat deze wordt gebruikt. Controleer eerst de automatische montage en activeer deze vervolgens met ls:

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

Een succesvolle configuratie kenmerkt zich door vier waarneembare eigenschappen: SSH-authenticatie verloopt zonder interactie, de fstab-vermelding is correct mount -a, systemd herkent de mount als netwerkafhankelijk en de externe bestanden zijn bereikbaar na een schone herstart. Als een van deze controles mislukt, los het probleem dan direct op in die laag in plaats van willekeurig meer mount-opties toe te voegen.