Repository 32bit  Forum
Repository 64bit  Wiki

Dischi remoti e condivisioni di rete veloci e sicure con sshfs

Da Slacky.eu.
Versione delle 00:58, 19 apr 2011, autore: Zoros (Discussione | contributi)

(diff) ← Versione meno recente | Versione attuale (diff) | Versione più recente → (diff)

Indice

Come utilizzare SSH e SSHFS per collegarsi a dischi remoti

Campo di applicazione, avvertenze

Queste informazioni si applicano a tutti i sistemi che usano un kernel con supporto FUSE - Filesystem in Userspace e librerie utente. Possono essere valide quindi, in modo diretto, per le versioni di Slackware 12.2, 13, 13.1, 13.3x. I test sono stati effettuati sulla 13.1 e le procedure descritte in questo articolo sono state controllate e verificate, tuttavia non si può escludere la presenza di errori ed imprecisioni, anche gravi. Use at own risk! Salvo diversamente specificato (con il simbolo "$" che indica comune "user"), tutti i comandi si intedono eseguiti come utente "root";

Premessa generale

Tutti le distribuzioni GNU/Linux implementano di serie, si puo dire "da sempre", il servizio SSH. In Slackware questo servizio è attivo per default già al primo avvio. E' già una buona base di partenza rispetto a ciò che intendiamo fare: utilizzare partizioni remote come fossero dischi locali.

Quando è attivo il server SSH, tutti si possono collegare alla nostra macchina; naturalmente dovranno fornire username e password validi. SSH è considerato sicuro per quanto riguarda le trasmissioni di rete, visto che sono criptate e non facilmente decifrabili. Può considerarsi sicuro anche il servizio stesso, nel senso che la maggior parte dei server collegati ad Internet sono gestiti attraverso ssh, anche se molto dipende dalla complessità delle credenziali (user e pass) e dall'aggiornamento costante dell'applicativo per "tappare" eventuali falle di sicurezza. In realtà la sicurezza dipende anche da altri fattori, ma questo esula dal nostro discorso. Quello che renda anche interessante SSH è la possibilità di attivare un meccanismo di autenticazione basato su una chiave numerica, più o meno sicura e complessa. E' quello che faremo.

L'accesso a directory remote è già implementato da tempo in KDE attraverso il protocollo fish:// per cui sarebbe sufficiente digitare nella barra degli indirizzi di konqueror una stringa tipo:

 fish://tux@192.168.0.1:22/home/tux/

però, finora, il sistema non sembra molto stabile ed è affetto da qualche bug.

In questo articolo si utilizzerà il client SSHFS (SSH File Transfer Protocol) per condividere ed usare dischi remoti, come fossero locali.

Installazione lato server

Sulla Slackware non dobbiamo fare niente lato server. Tuttavia è meglio assicurarsi che il servizio sia attivo, attraverso questi semplici comandi:

 chmod 755 /etc/rc.d
 /rc.sshd /etc/rc.d/rc.sshd start

Installazione lato client

Sulle macchine che intendiamo usare per collegarci ai dischi remoti condivisi SSH è necessario avere il client SSHFS (SSH File Transfer Protocol). Purtroppo di serie non è presente in Slackware quindi è necessario intallarlo. Per fortuna ci viene incontro slacky.eu. Lo possiamo scaricare con il comodo slackyd:

 $ slackd -g sshfs

e quindi installare (qui si usa upgradepkg per comodità), esempio:

 upgradepkg --install-new /var/slackyd/sshfs-2.2-i486-3kc.txz

Riguardo al pacchetto, però, se non avete slackyd, che non è di serie su Slackware, ma è sviluppato e mantenuto dalla community slacky.eu, le informazioni di cui sopra non vi bastano. Occorre allora installare il pacchetto che potete trovare qui: slackyd - Slacky downloader. Ma anche così, se siete nella 13.1, non riuscirete a scaricare il pacchetto, perché non è presente nel repository al momento.

Una soluzione è aggiungere i vecchi repository in /etc/slackyd/slackyd.conf, esempio:

 #Extra repositories:
 # Slacky.eu
 repository slacky  = http://darkstar.ist.utl.pt/slackware/addon/slacky/slackware-13.1/
 repository slacky1 = http://slack.isper.sk/pub/slackware-13.0/

Comunque, se non vi interessa slackyd (vivamente consigliato installarlo), ecco l'ultima versione disponibile all'atto della pubblicazione di questo articolo: sshfs-2.2-i486-3kc.txz (13.0 repository).

L'utilizzo da linea di comando

Una volta installato il pacchetto, l'utilizzo di sshfs è molto semplice:

 $ sshfs hostname: mountpoint

per montare la risorsa (hostname può essere anche l'IP del server) e

 $ fusermount -u mountpoint

per smontarla (purtroppo lo smontaggio da semplice "user" deve passare per l'apposito programma, solo "root" può usare "umount")

Dobbiamo considerare che SSH server condivide praticamente qualsiasi risorsa del server (partizioni, directory, ecc.), in pratica tutti i dispositivi di memorizzazione attivi. Lato client è quindi possibile usare una qualsiasi di queste directory. Il client vedrà la risorsa come un disco locale a partire dal percorso che decideremo. L'accesso è regolato dal normale sistema dei permessi, quindi potremo accedere all'intero disco del server, ma riusciremo ad usare solo le risorse per le quali siamo autorizzati (lato server).

Se scriviamo un comando tipo:

 sshfs 192.168.0.1:/ /mnt/sshdisk

ci troveremo a "navigare" (dentro /mnt/sshdisk) lungo tutta la radice del disco server di IP 192.168.0.1. Occorre fare attenzione quindi: se accediamo da utente root, possiamo fare dei danni. Ma ciò dimostra la semplicità e la potenza di sshfs.

La configurazione come disco utilizzabile da user

Volendo utilizzare comodamente la nostra risorsa remota da "user", ci conviene creare un entry in /etc/fstab. Si può fare così (immaginando l'IP del server quello di prima):

 sshfs#192.168.0.1:/home/tux /mnt/tuxNET fuse user,noauto 0 0

naturalmente non possiamo scordarci di creare il punto di montaggio, che, nel caso di fusermount da user dovrà avere i permessi di scrittura per l'utente:

 mkdir -p /mnt/tuxNET
 chown tux /mnt/tuxNET
 mount -a

(l'ultimo comando serve per rendere attive le modifiche a /etc/fstab senza riavviare).

A questo punto l'utente "tux" potrà montare il disco remoto con un semplice:

 $ mount /mnt/tuxNET

C'è un problema però: ci viene chiesta (giustamente) la password dell'user tux ad ogni montaggio. Questo un pochino ci condiziona, specie in grafica: ci fa comodo accedere al disco con un semplice click. Poco male, grazie alla possibilità di autentica attraverso chiave, possiamo ovviare al problema.

Installazione delle chiavi di accesso

Per accedere al server remoto senza digitare la password dobbiamo creare una chaive utente da depositare sul server. Una semplice chiave si può generare così:

 tux@darkstar:~$ ssh-keygen -t rsa

poi va copiata sul server nella home dell'utente che si desidera autorizzare:

 tux@darkstar:~$ scp .ssh/id_rsa.pub tux@192.168.0.1:/home/tux/.ssh/authorized_keys

chiaro che l'operazione va ripetuta per tutti gli utenti e tutti i pc che si intendono autorizzare all'accesso remoto dei dischi (Nota: potrebbe essere necessario creare la dir .ssh sul server).

Ora che le chiavi sono installate si potrà navigare in grafica sul disco remoto come fosse un disco locale. Le prestazioni in termini di velocità e stabilità si sono rivelate notevoli, tanto che è stato possibile usare il disco remoto (in una LAN 100 Mbit) anche come buffer disco di lavoro per file di grosse dimensioni. In alcuni test si è dimostrato, per esempio, che è possibile la masterizzazione diretta di ISO (2-3 GB) depositate sul disco remoto (test "a pelle", certamente non scientifico).

Per quanto riguarda l'utilizzo "desktop" di queste unità remote, dipende un po' dal desktop manager scelto. In KDE è possibile (tasto destro del mouse) creare un collegamento a disco rigido sul desktop, però sembra non funzionare correttamente: l'unità remota viene riconosciuta, ma il montaggio non è corretto. Si può creare allora un piccolo script e aggiungerlo come collegamento a programma. Un esempio potrebbe essere il seguente:

#/bin/sh
# mount/umount sshfs user disk
 
PATH=/bin:/usr/bin:/usr/local/bin
 
SSHFS_MOUNPOINT=/mnt/tuxNET
 
if [ ! -d $SSHFS_MOUNPOINT ]; then
 kdialog --sorry "Mountpoint $SSHFS_MOUNPOINT not exist"
 exit
fi
 
sshNET_mounted=`mount | grep $SSHFS_MOUNPOINT`
 
if [ "a$sshNET_mounted" = "a" ]; then
 MOUNT_ERRORS=`mount $SSHFS_MOUNPOINT 2>&1`
 
 if [ "a$MOUNT_ERRORS" != "a" ]; then
  kdialog --sorry "$MOUNT_ERRORS"
  exit
 fi
 
 konqueror $SSHFS_MOUNPOINT &
 exit
 
else
 UMOUNT_MSG=`fusermount -u $SSHFS_MOUNPOINT 2>&1`
 
 if [ "a$UMOUNT_MSG" != "a" ]; then
  kdialog --sorry "$UMOUNT_MSG"
  exit
 
 fi
 
fi

lo script verifica se /mnt/tuxNET è montato, in tal caso esegue "mount" e richiama "konqueror"; se invece la risorsa è già montata, semplicemente la smonta. Occorre ovviamente creare un collegamento sul desktop per usarlo in grafica.


Have fun!


Strumenti personali
Namespace

Varianti