SSH-ról már volt szó. Az SSHFS az SSH FileSystem. Bár nem egy teljesen új fájlrendszerről van szó, csupán az SFTP segítségével felcsatolt könyvtárakról. Leginkább Linuxon használható, de Windows kliensre is van megoldás. Ez a fejezet a Debian 6 és Windows 7 kliensek lehetőségeiről fog szólni.
Az SSHFS már azért is szót érdemel, mivel magyar a fejlesztője. Szeredi Miklós. De természetesen nem csak ezért szólok róla. Jó szolgálatot tesz, ha épp csak az SSH/SFTP elérhető a szerveren és nincs más lehetőség könyvtármegosztásra. Mivel egyes programok csak helyi fájlrendszeren képesek dolgozni, hasznos, ha az a program a távoli könyvtárat is helyinek látja. Ebben segít az SSHFS.
Tartalomjegyzék
SSHFS Debian 6-on
Telepítés
A telepítés egy sor terminálban root-ként:
Ezzel felkerül még a "fuse-utils" és a "libfuse2" csomag is, mivel az SSHFS alapja az FUSE.
Használat
A használat sem nehezebb. Nagyon hasonló az ssh parancshoz, amit korábban ismertettem. Annyi különbséggel, hogy meg kell adni a szerver felcsatolandó könyvtárát és egy lokális célkönyvtárat, ahova felcsatoljuk.
A következő példák a virtuális Debian kliensről az előzőekben készített virtuális gépre való bejelentkezésről szólnak. De ugyanígy használható a szerverről a Windows kliens egy könyvtárának felcsatolására.
Az "a22.vm1" szerver gyökérkönyvtárának felcsatolása a szerver "web" felhasználójának nevében a "/home/felhasznalonev/mnt/a22.vm1" lokális könyvtárba.
Az "a22.vm1" szerver "web" felhasználójának nevében annak home könyvtárának felcsatolása a "/home/felhasznalonev/mnt/a22.vm1" lokális könyvtárba.
Az "a22.vm1" szerver "web" felhasználójának nevében tetszőleges könyvtár felcsatolása a "/home/felhasznalonev/mnt/a22.vm1" lokális könyvtárba.
Port megadásával, ha szükséges
Érvényesek az SSH konfigurálásánál említett szabályok. Tehát lehet készíteni kulcsokat, amivel a jelszóbekérés átugorható. Illetve beállítható a kliens felhasználójának "~/.ssh/config" fájljában a szerver címéhez tartozó port és felhasználó is. Így ezeket sem kell megadni.
.ssh/config
User web
Port 22
Parancs
Ezek után a célkönyvtárban úgy lehet dolgozni a fájlokkal, mintha eleve a helyi fájlrendszer része lenne. Viszont le is kellene tudni csatolni.
Tehát
Ha már le lett csatolva korábban a könyvtár, előfordulhat a következő hibaüzenet:
root-ként pedig a következő
Jogosultság
Alapesetben csak a root felhasználó tudja használni az sshfs-t a "/dev/fuse" jogosultságai miatt. Bár a csoportja az "fuse", annak nincsenek hozzá jogai.
Ha saját, nem root felhasználóval megpróbálunk felcsatolni egy könyvtárat, akövetkező hibaüzenet fogad a jelszó megadása után:
Erre sok panaszt és szerencsére megoldást is lehet találni a weben. Módosíthatnánk a jogokat chmod-dal, de ez nem maradandó változtatás lenne. Minden újraindításkor visszaállna alaphelyzetre. Lehetne boot időben szkriptből átállítani minden alkalommal a jogosultságát a fájlnak 0660 -ra, de van ennél jobb mód is.
A helyes megoldás, hogy root felhasználóként az /etc/udev/rules.d mappába leteszünk egy új szabályt, ami az fuse -ra fog vonatkozni. Például:
Tartalma
A KERNEL után két egyenlőség jel legyen. Az egyes beállítások között pedig vesszők vannak. A GROUP meghatározza a /dev/fuse csoportját. A MODE pedig beállítja a fájl jogosultságait. A 0660 -ra lesz írási és olvasási joga a tulajdonosnak (aki a root) és a csoportnak is a fájlra. Viszont még érvényesíteni kell a változtatásokat:
modprobe fuse
/etc/init.d/fuse start
Most már a fájl jogai rendben vannak:
Ha most megpróbálnánk felcsatolni egy könyvtárat, még a régi lenne a hibaüzenet, mivel hozzá kell adni a felhasználónkat a "fuse" csoporthoz a következő módon:
Vagy
FONTOS, hogy a "-a" is kell. Ellenkező esetben nem hozzáadná az új csoportot, hanem lecserélné az összeset erre az egyre. Valamint a "-G" nagy G-vel írandó. A kis "g" az elsődleges csoportot állítja be a felhasználónak. Ami általában a felhasználó nevével megegyező csoportot jelent.
A fenti példák az "fuse" csoporttal íródtak. Egyes webes leírások az "operator" csoporttal dolgoznak. Maga a csoport neve lényegtelen. A fontos, hogy a felhasználónk rendelkezzen a /dev/fuse csoportjával.
Az új csoport használatához ki kell jelentkezni, majd a legközelebbi bejelentkezéskor már hiba nélkül működni fog a könyvtár felcsatolása.
Más felhasználók viszont nem fogják tudni elérni az általunk felcsatolt könyvtárat. Még a root felhasználó sem. Erre használhatók a "-o allow_root" és a "-o allow_other" opciók. Az előbbi csak a root felhasználó számára engedélyezi a hozzáférést, utóbbi pedig mindenkinek.
vagy
Ha most kipróbálnánk, egy ilyen hibaüzenet lenne az eredménye:
A hibaüzenetben említett fájlban az időzéjeles kifejezés elől kell kivenni a megjegyzés jelet. Ez után már használhatók az említett opciók.
Fontos, hogy ilyenkor a többi felhasználó is a mi távoli felhasználónk jogaival rendelkezik a fájlok felett.
ID egyeztetés
Amikor felcsatolunk egy távoli könyvtárat a helyi gépre, a két könyvtárban a fájlok tulajdonosai továbbra is a távoli felhasználók lesznek. Viszont egy fájlhoz csak a tulajdonos azonosítója (uid) tárolódik. A helyi gépen pedig nagy valószínűséggel nem ugyanaz a felhasználónév tartozik az adott id-hez. Így egy "ls -l" paranccsal egy másik felhasználót láthatunk a fájl tulajdonosaként.
Ez csak megjelenésbeli probléma. A távoli fájlokat a távoli felhasználó fogja kezelni az ő jogaival. Mi csak SSH segítségével utasítjuk a távoli felhasználót a műveletekre. Probléma akkor lehet, ha egy program a uid-t felhasználva próbál dolgozni. Vegyük a legegyszerűbb példát, a find program használatát kereséshez.
Ha ezt az utasítást egy felcsatolt könyvtárban adjuk ki, megpróbál ott minden olyan fájlt kiírni a terminálban, aminek a tulajdonosa az 1000-es azonosítójú felhasználó. A távoli szerveren viszont lehet, hogy a felhasználónak egész más id-je van. Így az eredmény a nagy semmi lesz. Holott ha ezt a jogosultságok vizsgálata miatt végzi a program, nem megfelelő képet ad a helyzetről, ugyanis a helyi felhasználó a távoli felhasználó jogaival kezelheti a távoli fájlokat.
Ha ezt szeretnénk elkerülni, akkor a következő módon kell felcsatolni egy könyvtárat:
Ezzel már az ls program is a helyi felhasználó nevét jeleníti meg a fájlok mellett és a find is megtalálná a helyi felhasználó id-jére keresve a távoli felhasználó tulajdonába tartozó fájlokat.
FONTOS, hogy az idmap után nem egy felhasználó nevét kell írni, hanem azt, hogy "user".
FONTOS, hogy az id egyeztetés annak a felhasználónak a nevében történik, aki a könyvtárat felcsatolja. Ha az allow_other opcióval másoknak is engedélyezzük a hozzáférést, ez akkor is így lesz. Így más felhasználók azt láthatják, hogy nincs joguk a fájlhoz, mégis a felcsatoló felhasználó jogaival rendelkeznek.
Egyes verzióknál létezhet az "-o idmap=file" opció is. Amivel nem csak a tulajdonos uid azonosítóját társítja a távoli felhasználó azonosítójához, hanem a csoportazonosítót (gid) is beállítja.
A "-o uid=1000" válogatás nélkül az összes távoli fájlhoz az 1000-es uid-t rendeli. A "-o gid=1000" pedig hasonlóképpen jár el a csoportokkal függetlenül attól, hogy mi a távoli fájl csoportja.
Felcsatolás boot időben
Ami biztos, hogy kelleni fog egy ssh kulcspár, amiről az SSH fejezetben írtam. Egyébként próbálná kérni a jelszót felcsatoláskor.
Itt a példák a virtuális gépre csatolják fel a gazda gép gyökérkönyvtárát. Bár javasoltam, hogy ilyen irányú fájlmegosztást ne készítsünk, bootoláskor a virtuális gép még nem fut. Így nem érdemes dolgoztatni vele a klienst. Távoli, a klienstől függetlenül folyamatosan futó szerverre természetesen alkalmazhatók ugyanígy a módszerek.
Mivel a gazdagép portja nem az alapértelmezett 22, az ssh-copy-id -nek meg kellene mondani a portot. Az SSH fejezetben említett megoldásra szükség lesz. Azaz előre megadjuk a portot a "~/.ssh/config" fájlban, vagy az ssh-copy-id attribútumlistáját idézőjelbe tesszük.
Még készítsük el a célkönyvtárat web felhasználóval (nem root-ként):
/etc/fstab
Használható az /etc/fstab fájl is az automatikus felcsatoláshoz a gép indításakor. Ehhez a következőhöz hasonló sort kell root-ként a /etc/fstab fájlba másolni:
Konkrétabban így nézne ki:
Látható, hogy kénytelenek vagyunk az allow_other opciót alkalmazni, mivel az fstab-ban levő könyvtárakat a root user csatolja fel, így alapesetben csak neki lenne hozzáférése. Ez így viszont más felhasználóknak is ugyanúgy megadja a hozzáférést, amit nem biztos, hogy szeretnénk.
Ráadásul ebben a fázisban még nem biztos, hogy él a hálózat. És bár lehet találni instrukciókat a hálózati kapcsolat felépítésének kivárására, a tapasztalatom az, hogy ezek működésében nem lehetünk annyira biztosak, mint a következőkben bemutatott megoldásnál.
/etc/rc.local
A "/etc/rc.local" fájl már a hálózati kapcsolatok felépítése után fut. Így itt a már ismert módon, parancssorból csatolhatjuk fel a választott könyvtárakat. Az "exit 0" sora elé tegyük a következőt:
-p 2246 \
-o idmap=user \
-o IdentityFile=/home/web/.ssh/id_rsa
Az IP természetesen mindenkinek a saját kliensének IP-je legyen. A "sudo -u web -H" teszi lehetővé, hogy a "web" felhasználó nevében történjen a felcsatolás. mivel az "allow_other" opció nincs engedélyezve, más nem fogja tudni elérni a felcsatolt könyvtárat. A gép újraindítása után a gazda gép gyökérkönyvtára már automatikusan felcsatolódik és elérhető lesz.
SSHFS Windows 7-ben
Windows kliensnél már más a helyzet. Az SSHFS még a Cygwin-nel sem valósítható meg. Tehát mindenképpen Windowsos megoldásra lesz szükség.
win-sshfs
A win-sshfs egy program, amivel új meghajtóként lehet felcsatolni egy távoli könyvtárat.
A betűjelek spórolásához, azaz egy alkönyvtárba való felcsatolására már nem ad lehetőséget. Arra viszont igen, hogy már a belépéskor felcsatolja a meghajtót.
Így tehát egy meghajtójelet kell választani, és a szerverről felcsatolandó könyvtár útvonalát megadni a "Directory" mezőben. Választható jelszavas mód is, de titkos kulcs is megadható. Ekkor megjelenik egy második beviteli mező is a passhprase-hez. Viszont azzal együtt már nem boldogul a passphrase kódolása miatt. Anélkül viszont könnyen működik és a "save" gombbal elmenthetjük a beállításokat, a "Mount" gombbal pedig felcsatolható a meghajtó. A felcsatolt meghajtót kiválasztva az "Unmount" gombbal történik a lecsatolás. A "mount at login" bejelölésével a meghajtó rögtön belépéskor felcsatolódik.
A weboldalán egy "Requirements" blokkban jelzik a készítői, hogy miket kell a win-sshfs előtt feltelepíteni. Ez a Microsoft .NET 4-es verziója, és egy Dokan nevű programkönyvtár.
Ennyi volna a win-sshfs. Nem tökéletes, de használható.
SFTP Net Drive
Az SFTP Net Drive egy fizetős program, de van ingyenes verziója is maximum 10 gépig. Otthon magánhasználatra ezt biztosan nem haladjuk meg. Vannak bizonyos korlátozásai az ingyenes verzióban, de ezzel együtt is többre képes, mint a win-sshfs. A különbségek az ingyenes és fizetős verzió között a Comparison of Free and Professional versions of SFTP Net Drive oldalon láthatók.
A telepítéskor a szokásos ikonelhelyezős kérdések mellett bejelölhető, hogy már rendszerinduláskor fusson a program. Ezeket én ki szoktam kapcsolni. Nem kell, hogy minden automatikusan induljon.
Az első indításkor még nincsenek profilok. Létre kell hozni egyet a "New profile" gombra kattintva. A fizetős verzióban lehetne egyedi neve a profilnak. Az ingyenesben viszont a profil neve a szerver neve lesz. Ha ugyanahhoz a szerverhez kell több meghajtót készíteni, akkor különböző címeken kell tudni elérni.
A profil nevet üresen kell hagyni. Ha megpróbálunk írni valamit bele, szól is a program, hogy az nem fog menni. Mentés után a szerver neve sem módosítható már. Ha sikerül elírni, akkor muszáj lesz új kapcsolatot létrehozni és a hibásat törölni.
Lehet választani SSH kulcsos és jelszavas belépést is. És már a passphrase is működni fog. A profil elkészülte után annak bizonyos tulajdonságait lehet módosítani a "Profile settings" gombra kattintva. Nem fog mindent engedni állítani. De például a "Root folder on the server", azaz a felcsatolandó szerveroldali könyvtár útvonala megadható. Előre meghatározott opciókkal, vagy tetszőleges útvonallal.
Végül a "Connect" gombra kattintva már fel is csatolja a meghajtót, amit bármelyik programból elérhetünk egyszerűen.
ExpanDrive
Az ExpanDrive nem ingyenes szoftver, de 7 napig ingyen lehet tesztelni. SSHFS/SFTP meghajtóhoz nem ad többet, mint az előző megoldások. És egy kis hibát is felfedezhettem benne.
Többféle meghajtót lehet készíteni. Ebből az egyik az SFTP. Szerver, felhasználó és jelszó megadható. Illetve a "More options"-re kattintva lenyílik a többi lehetőség, ahol a belépés módját is meg lehet adni. Például a kulcsos módszert.
Port, távoli könyvtár és meghajtójel is választható. Ezen kívül egy "Nickname". Ami első gondolatra saját becenevünknek tűnhet, de a meghajtó becenevét jelenti. Ami megjelenik a meghajtó neveként. És itt van egy kis hiba. El lehet menteni ékezetes becenevet bármiféle figyelmeztetés nélkül. Viszont felcsatlakoztatni nem fogja tudni a meghajtót. És erről sem szól egy szót sem a "Connect" gombra kattintva.
WebDrive
A WebDrive ismét egy fizetős program 20 nap próbaidővel. Szintén többféle meghajtót lehet választani, ami után viszont egy nem túl egyértelmű beállítási folyamat következik. Ráadásul időnként háttérbe kerül az aktív ablak, amire nehéz visszanavigálni. Miközben blokkolja a WebDrive szülő ablakait az előtérben.
Telepítés után az első képernyőn rögtön lehet a "New" gombra kattintva új meghajtót készíteni. Vagy az "App Settings"-re kattintva többek között a "Security" fülön ssh kulcspárt generálni vagy importálni. Azok formátumaival viszont hadilábon áll. Ráadásul passphrase nélkül generálni sem képes.
A "New" gombra előjön egy lista, ahonnan meghajtótípust választhatunk:
Az SFTP-t kiválasztva és a "Next" -re kattintva az egyszerű kapcsolódás felülete jön elő. Létezik egy "Advanced" is. A két felületen viszont nem változnak párhuzamosan az értékek, ami kissé elbizonytalanít. De nem lehet minden tökéletes.
Említettem, hogy a kulcsfájlok kezelése is problémás. Az egyszerű, jelszavas belépéssel viszont nincs gond. Ám a szerver címeként nem ismeri fel a virtualbox által készített hálózaton beállított névszerver domainjeit. Mintha csak az internet felé nézelődne. IP címmel viszont a virtuális gépre is lehet csatlakozni.
Azt, hogy melyik távoli könyvtárt csatolja fel, az "Advanced" beállításoknál az "SFTP settings" fülön lehet beállítani az első mezőben. Legalul pedig a kulcsfájlt lehetne megadni. Azt, hogy mi legyen a meghajtó betűjele, a "General Host Settings" fülön lehet állítani.
Engem tehát nem győzött meg. És ez alapján nem is fizetnék érte. Viszont ez is egy a lehetőségek közül.
Swish
A swish a Windows Explorerbe beépülő SFTP kliens. Bár más szoftverek nem tudnak rajta keresztül tallózni, a fájlkezelést úgymond Windowsosabbá teszi. Ezért többen javasolják SSHFS helyett. Bár az előző programok képességeivel nem ér fel.
Kis jelentősége miatt többet nem is foglalkoznék vele. De jó tudni róla.
Összefoglalás
Linuxon tehát az sshfs adott. Nem nagyon kell más megoldást keresni. Windowson win-sshfs, SFTP Net Drive is használható ingyenesen. Bár utóbbi csak 10 gépig. Az ExpanDrive, WebDrive fizetős szoftverek. Többek között SFTP-re is. Ha már valamiért fizetnék, az az ExpanDrive lenne. A kis ékezetes bakiját simán ki lehet bírni. Viszont egyértelműbbek a beállításai és a használata, mint a WebDrive-nak. És ott a kakukktojás swish, ami csak Windows Explorerbe tud beépülni és más szoftverek számára nem elérhető.
Igyekeztem olyan sorrendben írni róluk, amilyen sorrendben javasolnám őket. Ha választanom kéne, a win-sshfs mellett szól, hogy nincs gépek számára szóló megkötés. Az SFTP Net Drive viszont kifinomultabb.
A win-sshfs és a WebDrive is problémás a kulcsfájlokat tekintve. A win-sshfs viszont passpharse nélkül könnyen használható.
Magán a szervergépen nem sok változott. Én viszont mégis elmentem a virtuális gépet "wtk-vm1-v11-sshfs" néven. Ha valaki spórolna a hellyel, nyugodtan rámentheti az előző verzióra.
Források
- Wikipedia: SSHFS
- SSHFS in Windows
- Effectively sshfs for Windows
- Map Network Location Over SSH / SFTP In Windows Explorer
- Mounting Remote Directories With SSHFS On Debian Squeeze
- SSH Filesystem
- Using SSHFS and Fuse, permission fix how to fix permission of /dev/fuse
- Fuse.conf
- Notes on sshfs on Ubuntu
- ssh-copy-id and sshd port
- dapper: /dev/fuse not owned by group set in package config
Egyéb ajánlott linkek
