Mounten Sie beim Booten ein sshfs über macfuse

10118
dag729

Ich möchte einen sshfs-Ordner beim Booten unter Mac OSX einbinden: Ich verwende Macfusion, das ist eine GUI für MacFUSE, aber ich muss den Ordner manuell einhängen.

Wie kann ich das erreichen?

6

3 Antworten auf die Frage

5
dag729

Wenn Sie einen Remote-Computer verwalten, kann es sehr nützlich sein, das Dateisystem dieses Computers lokal anzuhängen, um Dateien zu verschieben. MacFuse und sshfsmachen dies sehr einfach, obwohl das Einrichten und Mounten automatisch beim Login ein bisschen schwierig sein kann.

Stellen Sie zunächst sicher, dass Sie ssh auf Ihrem Remote-Computer ausführen können, ohne ein Kennwort einzugeben. Führen Sie das Setup in Leopard aus, indem Sie schließlich ssh-agent beim Anmelden unterstützen, und überprüfen Sie, ob es funktioniert:

ssh USER@HOSTNAME: 

Wenn Sie sich angemeldet haben, ohne nach einem Kennwort oder einem Kennwort gefragt zu werden, können Sie fortfahren.

Als Nächstes installieren Sie sshfsund MacFuse gemäß Installation von sshfs 1.9 mit MacFuse 1.7 unter OS X Leopard 10.5.5 .

Finden Sie heraus, wo Sie Ihr Remote-Volume einhängen möchten. Ich würde die Verwendung nicht empfehlen, /Volumesda OS X anscheinend automatisch Verzeichnisse löscht, wenn Sie die Bereitstellung von Objekten aufheben. Also habe ich stattdessen verwendet/mnt/HOSTNAME

mkdir -p / mnt / Hostname

(Sie werden natürlich durch HOSTNAMEden Namen Ihres Remote-Servers ersetzt.)

Stellen Sie dann sicher, dass Sie Ihren Remote-Standort als Volume bereitstellen können, ohne ein Kennwort anzugeben, indem Sie Folgendes verwenden sshfs:

sshfs USER@HOSTNAME:PATH /mnt/HOSTNAME -oreconnect,allow_other,volname=VOLUME_NAME 

Stellen Sie VOLUME_NAME auf den Namen des Datenträgers im Finder ein. Ich habe HOSTNAME verwendet. PFAD ist optional; Legen Sie fest, welches Verzeichnis Sie auf dem Remote-Host bereitstellen möchten. Ist dies nicht der Fall, wird Ihr Heimatverzeichnis verwendet.

Wenn keine Fehlermeldungen angezeigt werden und die Remote-Dateien angezeigt werden, können Sie mit dem nächsten Schritt fortfahren.ls /mnt/HOSTNAME

Hängen Sie das soeben gemountete Volume ab:

umount / mnt / hostenname

Jetzt kommt die knifflige Party. Sie müssen ein LaunchAgent-Element erstellen, um Ihr Volume bei der Anmeldung bereitzustellen. Das ist an sich ziemlich einfach. Wenn Ihr System jedoch meinem System ähnelt, ist SSH_AUTH_SOCK für dieses Element nicht richtig eingestellt, sodass es nicht möglich ist, sich am Remote-Host ohne Verwendung eines Kennworts anzumelden. Sie müssen den SSH_AUTH_SOCK manuell einstellen.

Erstellen Sie zunächst einen Wrapper um sshfsden SSH_AUTH_SOCK für Sie. Legen Sie dies in eine Datei, wo immer Sie möchten. Ich schlage vor /opt/local/bin/sshfs-authsock.

#!/bin/bash export SSH_AUTH_SOCK=$(ls -t /tmp/launch-*/Listeners | head -1) /opt/local/bin/sshfs $* 

Grundsätzlich setzt diese Datei SSH_AUTH_SOCK auf den neuesten Socket in Ihrem tmp-Verzeichnis. In den meisten Fällen sollte dies der richtige sein. Es ist unwahrscheinlich, dass ein Fehler auftritt, und es gibt keine Sicherheitslücke, wenn dies der Fall ist.

Nun können Sie endlich die launchd plist-Datei erstellen. Setze das ein

~/Library/LaunchAgents/BACKWARDS_HOST_DNS.PATH.sshfs.plist 

(Wenn der Pfad des Hosts zum Beispiel der Pfad ist foo.niskala.orgund der Pfad PATH war /tmp, dann wäre der Dateiname das Ergebnis org.niskala.foo.tmp.sshfs.plist. Dies ist nur eine Konvention. Geben Sie der Datei einen beliebigen Namen, den Sie wollen, aber es muss enden .plist.)

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>BACKWARDS_HOST_DNS.PATH.sshfs</string> <key>ProgramArguments</key> <array> <string>/opt/local/bin/sshfs-authsock</string> <string>USER@HOSTNAME:</string> <string>/mnt/HOSTNAME</string> <string>-oreconnect,allow_other,volname=VOLUME_NAME</string> </array> <key>RunAtLoad</key> <true/> </dict> </plist> 

Laden Sie nun die Plist-Datei und führen Sie sie aus, um zu sehen, ob sie funktioniert.

launchctl load ~/Library/LaunchAgents/BACKWARDS_HOST_DNS.PATH.sshfs launchctl start BACKWARDS_HOST_DNS.PATH.sshfs 

Wenn keine Fehlermeldungen angezeigt werden, prüfen Sie, ob der Datenträger ordnungsgemäß bereitgestellt wurde:

ls / mnt / hostenname

Wenn Ihre Remote-Dateien auftauchen, dann toll! Sie sind fertig!

Wenn nicht, verwenden Sie

launchctl unload ~/Library/LaunchAgents/BACKWARDS_HOST_DNS.PATH.sshfs 

Entladen Sie die Datei, bevor Sie sie bearbeiten, und verwenden Sie ps auxwww | grep sshfsund killzum Suchen und Beenden von sshfsProzessen, bevor Sie es erneut versuchen.

Verweise:

2
oliora

Ich möchte die großartige Antwort von dag729 aktualisieren. Bei El Captain OS X mit der OS X-Sicherung 2.8.3 sind die Dinge etwas anders:

  1. Einige Pfade werden geändert
  2. osxfuse muss mit der -fOption im Vordergrundmodus ausgeführt werden
  3. SSH_AUTH_SOCKist bereits definiert, so dass es keinen Grund mehr gibt, das sshfs-authsockSkript zu erstellen

Ich würde auch raten, allow_otherOption nicht zu verwenden (aus Sicherheitsgründen) und auto_cacheOption zu verwenden, nur weil es sich als nützlich anhört. Weitere Informationen finden Sie in den OS X-Sicherungsmontageoptionen .

Hier ist eine ~/Library/LaunchAgents/NAME.sshfs.plistDatei, die ich verwende:

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>NAME.sshfs</string> <key>ProgramArguments</key> <array> <string>/usr/local/bin/sshfs</string> <string>[USER@]HOST:REMOTE_DIR</string> <string>MOUNT_DIR</string> <string>-oreconnect,auto_cache,volname=FINDER_VOLUME_NAME</string> <string>-f</string> </array> <key>RunAtLoad</key> <true/> </dict> </plist> 

Wo NAMEist ein beliebiger Name und die restlichen Variablen sind ziemlich selbstbeschreibend.


Wenn Sie aus irgendeinem Grund nicht SSH_AUTH_SOCKdefiniert haben (Befehl ausführen launchctl getenv SSH_AUTH_SOCK, um es zu überprüfen), erstellen Sie ein Hilfsskript, beispielsweise /usr/local/bin/sshfs-authsockmit dem folgenden Inhalt:

#!/bin/bash export SSH_AUTH_SOCK=$(ls -t /tmp/com.apple.launchd.*/Listeners | head -1) /usr/local/bin/sshfs $* 

Führen Sie dieses Skript anstelle sshfsvon plist file aus. Also ~/Library/LaunchAgents/NAME.sshfs.plistsolltest du sein:

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>NAME.sshfs</string> <key>ProgramArguments</key> <array> <string>/usr/local/bin/sshfs-authsock</string> <string>[USER@]HOST:REMOTE_DIR</string> <string>MOUNT_DIR</string> <string>-oreconnect,auto_cache,volname=FINDER_VOLUME_NAME</string> <string>-f</string> </array> <key>RunAtLoad</key> <true/> </dict> </plist> 
1
Tex

I'd like to add something to dag729's very complete answer.

If you have Lion and have now OS X Fuse instead of the old MacFuse, then the procedure above won't work out of the box because the path of sshfs is different.

If that's the case for you, look where sshfs is in your installation using

which sshfs 

and put that path in the /opt/local/bin/sshfs-authsock script.

In my installation, that path is /usr/local/bin/sshfs and therefore my script is:

#!/bin/bash export SSH_AUTH_SOCK=$( ls -t /tmp/launch-*/Listeners | head -1) /usr/local/bin/sshfs $* 

I can confirm that the rest is still valid.