SSHFS: montare una risorsa remota sfruttando FUSE ed SSH: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
m (→‎Installazione: aggiunta nota sul modulo fuse)
(verificata per Stretch e Buster, rimosse informazioni relative a versioni obsolete di Debian)
 
(47 versioni intermedie di 10 utenti non mostrate)
Riga 1: Riga 1:
=Introduzione=
{{File_System
Questa guida nasce dalla discussione [http://www.debianizzati.org/component/option,com_joomlaboard/Itemid,29/func,view/catid,19/id,14487/ Manovrare X da remoto] apparsa sul forum di Debianizzati.Org
|precedente=Samba:_guida_estesa
|successivo=Guida_alla_formattazione_dei_dischi_con_fdisk
}}
{{SSH
|precedente=SFTP: SSH File Transfer Protocol
}}
{{Versioni compatibili|Jessie|Stretch|Buster}}
== Introduzione ==
Spesso può essere necessario lavorare direttamente su un filesystem remoto (si pensi, ad esempio, alla webroot di un sito o alla home del proprio portatile).


Ogni home o client system software che si rispetti ha un 'interfaccia grafica(GUI). Microsoft la include nel suo systema, o kernel che dir si voglia. Le ditribuzioni GNU/Linux la includono nell'installazione di default. In ogni modo nelle distribuzioni GNU/Linux e POSIX la GUI non e' parte del kernel ma un programma a parte l' "X window system" o semplicemente X. Precisamente X non e' la GUI. ''Xdm'', ''Gdm'', ''Kdm'' sono GUI. X � una struttura che la GUI usa per i suoi scopi. Mentre la GUI gestisce bottoni, finestre, testi ecc. X gestisce applicazioni di piu' basso livello: input di tastiera, mouse,fonts ecc. Molte persone potrebero pensare riguardo per esempio ai termini X-server e X-client al contrario di quello che potrebbe sembrare. Un X server e' una macchina nel network dove e' installato un window manager e dove altre altre macchine, X-clients, ci si possono collegare e gestire finestre, scrivere testi, navigare in rete e che puo' leggere il tuo input. In definitiva cosa un X server "serve" sono finestre e il tuo input da mouse o tastiera.
'''<code>Sshfs</code>''' permette di superare questo problema in un modo semplice e pulito: montando una directory mediante FUSE<sup>[[#Collegamenti esterni|[1]]]</sup>, usando il protocollo [[SSH]].


=Configurazione=
== Installazione ==
Il server X di solito viene iniziato da un X Display Manager.Un X display manager e' xdm,gdm,kdm che forniscono svariati X displays locali o remoti specificati in Xservers usando XDMCP come specificato nel file Xaccess.
Il pacchetto <code>sshfs</code> e le utility per gestire FUSE sono già presenti in Debian, quindi l'installazione si riduce ad un semplice:
In /etc/X11/xdm/xdm-config commenta :
 
DisplayManager.requestPort:  0
!DisplayManager.requestPort:  0
In /etc/X11/xdm/Xaccess togli il comento a
 
        #*        #any host can get a login window       
        *        #any host can get a login window
 
Questo mettera' l'Xserver in broadcast mode che buttera' giu' una lista di tutti gli Xserver in Willing di accetare di connettersi all'X server.
Se vuoi permettere connesioni solo da parte di certi host che un sezione nello stesso file che si chiama CHOOSER
 
In /etc/X11/fs/config commenta cosi':
 
#no-listen = tcp
 
Poi cambia in /etc/X11/XF86Config-4
FontPath        "unix/:-1"
FontPath        "unix/:-7100"
 
Questo per indicare 7100 come porta per FontPath in UDP
 
=Utilizzo=
Se usi un sistema GNU/Linux probabilmente hai X gia' installato. L'X server puo' essere lanciarlo con un semplice:
<pre>
<pre>
# X &
# apt install sshfs
</pre>
</pre>
Questo fara' partire un server X in background. Comparira' uno schermo con lo sfondo grigio e un X come puntatore del mouse che puoi muovere per lo schermo... niente di speciale ne' di carino da vedere, .... inutile.
(da eseguirsi con [[privilegi di amministrazione]])
Il comando di sopra quindi inizia un X server, che semplicemente sta li' in attesa di un client che si collega come per esempio ''xterm'' che apre una finestra ed esegue una shell. Ci sono molte opzioni da riga di comando che aprono finestre di diversa grandezza e posizione ma tutto cio' non sarebbe molto pratico ne' di facile utilizzo.


C'e' bisogno di un ''X-client'' e di un ''window-manager''.
== Configurazione ==
Un window-manager puo dare quell'usabilita' interattiva alla quale siamo abituati. Un window manager in GNU/Linux potrebbe essere mwm o fvwm che possono essere lanciati con un ''mwm -display :0''  o ''fvwm -display :0'' una volta che e' partito un window-manager muovere e gestire finestre diventa interattivo e lanciare applicazioni diventa piu' facile. Il ''-display :0'' per aprire finestre sull X-server. Un display non e' nient'altro che uno schermo al quale collegarsi. Di default quando X parte lui inizia un display sul 'canale' :0 della macchina locale.
=== Permettere l'esecuzione di sshfs ad altri utenti ===
Quando parte una sessione X automaticamente va a piazzare il display al quale e' collegata nella variabile $DISPLAY. Se non dovesse essere stata dichiarata alcuna variabile di default X si andra a piazzare sul display '':0.0''.
A partire da Debian 8 ([[Jessie]]) non è necessario modificare niente, in quanto di default tutti gli utenti possono utilizzare il modulo <code>fuse</code> se è installato; né ha più alcuna importanza l'appartenenza al gruppo ''fuse'', in precedenza richiesta.
In ogni caso per lanciare X dalla console e' un sufficiente lanciare uno ''startx'', che iniziera' un X-server su display '':0''.
Molti X-server specialmente nel mondo GNU/Linux usano ''xdm'' o ''gdm'' o ''kdm''. Xdm sta' per "x display menager"; questi hanno lo scopo di accogliere l'utente con un X-client che e' un login grafico chiamato anche "greeter". Una volta che hai introdotto nome utente e password non solo un window manager ma un intero ambiente desktop si presenta dinanzi ai tuoi occhi.
Ritornado al discorso client server , sul server lancia startx,assicurati ci sia un window manager attivo e poi da un xterm lancia il comando:


<pre> $ xhost add 192.168.0.2 (ip del client)</pre>
== Utilizzo e Test ==
 
L'utilizzo è semplice:
Questo permettera' connessioni dalla macchina 192.168.0.2.
'''sshfs''' [user@]host''':'''[dir] mountpoint [options]
Sul client invece digita :
anche se spesso si può semplicemente usare senza opzioni:
<pre>
<pre>
$ xterm -display 192.168.0.1(ip Xserver):0
$ sshfs user@host:/dir/to/mount /mnt/sshdir
</pre>
</pre>
Sul server X adesso dovresti vedere un finestra di xterm. E' successo che un X-client si e' collegato ad un xserver aprendo una finestra di xterm li'.
dove
 
; <code>user</code>: è l'utente della macchina remota, se omesso verrà utilizzato l'username dell'utente che lancia il comando;
Riguardo la sicurezza il protocollo X e' apllicabile solo in ambienti fidati Lan e non e' cosigliabile avere sessioni X attraverso la grande rete. Se vuoi utilizzare X attraverso la rete e' consigliabile incanalare il protocollo X in un protocollo sicuro come ssh. In ogni caso ci sono anche altri modi in aggiunta ad ssh che puoi utilizzare per proteggere le tue macchine uno di questi e'xhost ma anche meglio con un programma xauth utilizzato per autenticare i clients: ''Xauth'' puo' funzionare in vari modi: uno di essi e' attraverso l'utilizzo di un cookie. Un X-client per collegarsi ad un X-server ha bisogno di conoscere una sequenza di dati casuali generati dal server conosciuto come cookie che funziona in maniera molto simile ad un session password: se il cookie trasmesso dal client non corrisponde a quello del server, Xserver rifiutera' la connessione. Xserver di default e' in ascolto sulla porta 6000 per display:0 , 6001 per display:01  ecc.
; <code>host</code>: è l'indirizzo IP o l'URL a cui la macchina remota risponde;
; <code>/dir/to/mount</code>: è il percorso assoluto della directory da montare, (è possibile anche utilizzare un percorso relativo a partire dalla directory home dell'utente: <code>''./path/to/dir''</code>; o perfino tralasciare questo argomento, per indicare la home, ma sempre digitando '''<code>:</code>''');
; <code>/mnt/sshdir</code>: rappresenta il punto di mount; questa directory deve appartenere all'utente, che deve avervi accesso anche in scrittura;


Programmi come xdm , gdm o kdm sono demoni che vanno in background, sono soliti essere iniziati da init al boot e sono sempre in attivita'. Si occupano di iniziare sessioni X-server se necessario, del login grafico, preparano i cookies di xauth che servono per autenticare i clients e fanno partire il programma adatto per ciascun desktop e cosi' via'.
per controllare la riuscita del comando, si può analizzare l'output del comando:
Xdm puo' essere configurato per accettare richieste XDMCP dal network. Questi sono speciali pacchetti UDP che un xserver trasmette da porta 177 per richiedere login remoti. Quando un Xserver richiede di collegarsi ad un altra macchia con xdm allora bisogna lanciare l'X-server con opzioni "-query" o "-broadcast". L'opzione "-query" viene usata quando X-server deve lanciare un richiesta XDMCP ad una macchina in particolare, invece "-broadcast" la trasmette a tutte le macchine nel network.
<pre>
<pre>
X -query 192.168.1.2
$ findmnt
</pre>
</pre>
o
 
Per quanto riguarda lo smontaggio (unmounting) il comando è il seguente:
<pre>
<pre>
X -broadcast
$ fusermount -u /mnt/sshdir
</pre>
</pre>
Come detto pocanzi X puo' essere usato attraverso la grande rete ma non senza alcune contromisure.Una di questa e' di usare un tunnel ssh , affinche' funzioni va' settata l'opzione X11Forwarding a yes in ''/etc/ssh/sshd_config''.
 
Fa partire un X-server con startx sulla macchina locale , poi in xterm collegherati alla macchina remota usando ssh con il seguente comando:
per le opzioni consultare il file
<pre>
<pre>
ssh -X -C user@remotebox
$ man sshfs
</pre>
</pre>
Dove "user" e' il tuo user code. Dopo esserti collegato puoi lanciare programmi X-client e questi li vedrai sulla tua macchina locale. Quando ssh si collega a un sshd usando l'opzione -X, l'sshd prepara un "virtual" X-server su di un display col numero piu' alto disponibile (di solito il 10)
tra le più comuni:
e dopo crea il suo authentication cookie per la sessione.   
'''-p''' ''PORT'' equivalente a <code>-o port=PORT</code>
Quando un X-client sulla stessa macchina del sshd server si connette al display 10, lo pseudo sshd X-server convalida l'X-client usando il suo cookie, cripta la connessione e trasmette la richiesta all' ssh client sulla tua macchina. L'ssh client poi autentica la richiesta al vero X-server usando il cookie vero e visualizza le richieste dell'X-server. L'opzione "-C" comprime la comunicazione rendendola piu fluida e la decomprime una volta a termine dall'altro lato. 
'''-C''' equivalente a <code>-o compression=yes</code>
L'uso di X attraverso ssh puo' delle volte causare dei problemi di rendimento e performance. Il protocollo X trasmettera' tutte le righe, tutte le aree anche non necessarie, non c'e' una cache ne' alcun tipo di funzionalita' "trasmetto solo cosa e' cambiato".Significa che se un' area e' stata ridisegnata tre volte il protocollo X trasmettera' tutte le volte che quell'area e' stata cambiata mentre basterebbe trasmettere solo l'ultima delle tre e questo potrebbe risultare un po' dannoso su connessioni lente. Il protocollo VNC e' consapevole di questo aspetto infatti il VNC server aspetta connessioni dai VNC clients e quando il client si connette VNC trasmette l'intero desktop al client. VNC e' sia un vncserver che un x-server. Quando parte si mette in ascolto sulla sua porta tcp la 5900 (+ il numero di display :0.1 x 5901, :02 x 5092 ecc.) in attesa di VNC clients che si collegano. Rimane in ascolto anche sulla socket del display proprio come un X-server ma, invece di trasmettere la richiesta su un monitor, la tiene in memoria per trasmetterla al client. Per configurare VNC c'e' bisogno della presenza di un vncserver da essere lanciato manualmente. Per prima cosa bisogna impostare una vncpasswd che poi verra' usata per il login. Ci si collega con ssh senza l'opzione ''-X'':
'''-F''' ''ssh_configfile'' specifica un file di configurazione alternativo
<pre>
'''-1''' equivalente a <code>-o ssh_protocol=1</code>
ssh username@hostremoto
 
</pre>
Si noti che per dichiarare opzioni di SSH è sufficiente digitare <code>'''-o''' ''variabile_sshd'''''='''''valore''</code>, ad esempio per specificare la propria chiave privata è sufficiente aggiungere <code>-o IdentityFile=/percorso/chiave</code> (ASSOLUTO!):
Poi una volta collegato lanci ''vncserver :1'' che in pratica mette vncserver in ascolto sul display 1 cioe' tcp port 5901.Dopo puoi lanciare il vnc client come per esempio tightvncviewer o vncviewer o svncviewer in questo modo :
<pre>$ sshfs user@host:/dir/to/mount /mnt/sshdir -o IdentityFile=/percorso/chiave -p numero_porta</pre>
<pre>
 
vncviewer hostremoto:1
Se il mount avviene con successo è possibile usare il file-manager preferito per poter gestire in lettura e scrittura la nuova directory montata, che sia esso MC, dolphin, PCmanfm o altro.
</pre>
 
Poi ti verra' chiesta la password e tu introdurrai quella stabilita in precedenza e vuola' eccoti il desktop remoto in locale in tutto il suo splendore.
=== Utenti e gruppi proprietari ===
Questa configurazione presenta dei rischi, porta 5900 e 5800 deve essere aperta nel firewall e la comunicazione e' in chiara. Per criptarla c'e' bisogno di un tunnel ssh. Ancora una volta l'amico ssh ci viene incontro:
 
<pre>
Per impostazione predefinita sshfs adotta un'associazione "diretta" tra [[UID]]/[[GID]] della macchina remota e quella locale, il che significa per esempio che se il proprietario di un certo file sulla macchina remota è l'utente con UID 1002 anche in locale la proprietà del file sarà attribuita all'utente avente UID 1002. Potrebbero dunque sorgere problemi di permessi se su macchina remota e locale non sussiste un esatta corrispondenza utenti/UID e gruppi/GID. Un modo veloce per superare tale problema è specificare lo UID/GID durante il comando per montare le risorse remote, per esempio
ssh -C -L 5901:127.0.0.1:5901 user@remotehost
 
</pre>
<pre># sshfs user@host:/dir/to/mount /mnt/sshdir -o idmap=user,uid=1001</pre>
questo comando mettera' ssh in ascolto sulla porta locale 5901 fino alla porta remota 5901 quella del server vnc. Una volta loggati sulla macchina remota, sulla macchina locale apri vncviewer (un qualsiasi client vnc,o addirittura il browser con java) e lo punti a ''localhost:5901'' vncviewer questo comando ti permettera' di criptare la tua connessione verso il server vnc attraverso un tunnel ssh.
 
fa sì che all'utenza usata per connettersi al server remoto sia associata in locale l'utenza avente UID 1001. Se si ha la necessità di fissare la corrispondenza di più utenze/gruppi è possibile creare degli appositi file di mappatura (si veda il manuale di sshfs).


(G)
==== Accesso ad altri utenti ====


Molte persone credono che X sia stato progettato solo per GNULinux e unixlike ma in realta' come ogni prodotto unix il primo intento e' la portabilita' verso quanti piu' OS e' possibile .
Per permettere l'accesso del file system anche ad altri utenti, indipendentemente dai permessi associati ai file, è possibile mediante l'opzione: <code>-o allow_other</code>
Altri ottimi progetti sono il [http://www.ltsp.org Linux terminal Server project] che usa tutte le potenzialita' di X in scenari dove gli utenti sono collegati ad un X server centrale attraverso dei thin client o diskless machine con un grosso abbatimento sui costi e in questo senso come non menzionare il progetto [http://www.progettolazzaro.it/ProgettoLazzaro.htm LazarusNX] che ha come obbiettivo il recupero di hardware obsoleto specialmente nelle scuole italiane,creazione di reti didattiche e laboratori informatici ad alte prestazioni e costi contenuti.
"C'� una crescente sensibilit� verso il reimpiego dell'hardware obsoleto, del suo riutilizzo con finalit� sociali, accademiche ma anche di business - si legge in una nota - Immaginiamo una scuola (ma potrebbe essere una qualsiasi organizzazione statale o privata) che abbia un parco computer obsoleto. Con Lazarus-NX queste macchine possono essere riutilizzate su piattaforma Open Source, svincolando l'organizzazione anche dalle spese di licenza tipiche del software proprietario".


Affinché abbia effetto però bisogna anche configurare '''fuse''', ossia che <code>/etc/fuse.conf</code> contenga, non commentata, la riga <code>user_allow_other</code>, che di default è disabilitata per ragioni di sicurezza. Per maggiori informazioni si rimanda al manuale (<code>man fuse</code>).


Altro link interessante:
È pertanto '''sconsigliato''' utilizzare tale impostazione, se si può fare altrimenti.


http://www.tldp.org/HOWTO/XDMCP-HOWTO
== FAQ ed Errori Frequenti ==
=== failed to open <code>/dev/fuse</code>: No such file or directory ===
L'errore è dovuto alla mancanza del modulo del kernel relativo a ''fusefs''. È necessario compilarlo come modulo o staticamente. Nei kernel pacchettizzati Debian è presente, ed è caricabile con un:
<pre>
# modprobe fuse
</pre>


Scopo di questo scritto e' di fornire una guida generale sul mondo dei desktop remoti e il loro uso mediante software opensource
=== mountpoint is not empty ===
Se si cerca di montare una risorsa in un [[mountpoint]] contenente già dei file, può apparire il seguente errore:
<pre>fusermount: mountpoint is not empty
fusermount: if you are sure this is safe, use the 'nonempty' mount option</pre>
Le soluzioni sono:
* usare un mountpoint libero (consigliata)
* appendere, dopo il comando <code>''sshfs''</code> l'opzione <code>''-o nonempty''</code>


Per insulti o gemiti di piacere questa e' la mia mail : gabrix@gabrix.ath.cx
=== Collegamenti esterni ===
[1] [http://fuse.sourceforge.net/ FUSE]
{{Autori
|Autore = [[Utente:MaXeR|MaXeR]]
|Verificata_da =
: [[Utente:Wtf|Wtf]] 16:58, 9 ott 2013 (CEST)
: [[Utente:mm-barabba|mm.barabba]]
: [[Utente:HAL 9000|HAL 9000]] 21:01, 18 ago 2019 (CEST)
| Numero_revisori = 3
}}


Grazie e ciao !
[[Categoria:Filesystem]]
[[Categoria:Condivisione_risorse]]
[[Categoria:Crittografia]]
[[Categoria:SSH server e amministrazione remota]]

Versione attuale delle 19:01, 18 ago 2019

File System e dispositivi fisici
Arrow left.png

Generalità

Locali

Remoti

Strumenti

Arrow right.png



SSH
Arrow left.png

Guide correlate



Debian-swirl.png Versioni Compatibili

Debian 8 "jessie"
Debian 9 "stretch"
Debian 10 "buster"

Introduzione

Spesso può essere necessario lavorare direttamente su un filesystem remoto (si pensi, ad esempio, alla webroot di un sito o alla home del proprio portatile).

Sshfs permette di superare questo problema in un modo semplice e pulito: montando una directory mediante FUSE[1], usando il protocollo SSH.

Installazione

Il pacchetto sshfs e le utility per gestire FUSE sono già presenti in Debian, quindi l'installazione si riduce ad un semplice:

# apt install sshfs

(da eseguirsi con privilegi di amministrazione)

Configurazione

Permettere l'esecuzione di sshfs ad altri utenti

A partire da Debian 8 (Jessie) non è necessario modificare niente, in quanto di default tutti gli utenti possono utilizzare il modulo fuse se è installato; né ha più alcuna importanza l'appartenenza al gruppo fuse, in precedenza richiesta.

Utilizzo e Test

L'utilizzo è semplice:

sshfs [user@]host:[dir] mountpoint [options]

anche se spesso si può semplicemente usare senza opzioni:

$ sshfs user@host:/dir/to/mount /mnt/sshdir

dove

user
è l'utente della macchina remota, se omesso verrà utilizzato l'username dell'utente che lancia il comando;
host
è l'indirizzo IP o l'URL a cui la macchina remota risponde;
/dir/to/mount
è il percorso assoluto della directory da montare, (è possibile anche utilizzare un percorso relativo a partire dalla directory home dell'utente: ./path/to/dir; o perfino tralasciare questo argomento, per indicare la home, ma sempre digitando :);
/mnt/sshdir
rappresenta il punto di mount; questa directory deve appartenere all'utente, che deve avervi accesso anche in scrittura;

per controllare la riuscita del comando, si può analizzare l'output del comando:

$ findmnt

Per quanto riguarda lo smontaggio (unmounting) il comando è il seguente:

$ fusermount -u /mnt/sshdir

per le opzioni consultare il file

$ man sshfs

tra le più comuni:

-p PORT equivalente a -o port=PORT
-C equivalente a -o compression=yes 
-F ssh_configfile specifica un file di configurazione alternativo
-1 equivalente a -o ssh_protocol=1

Si noti che per dichiarare opzioni di SSH è sufficiente digitare -o variabile_sshd=valore, ad esempio per specificare la propria chiave privata è sufficiente aggiungere -o IdentityFile=/percorso/chiave (ASSOLUTO!):

$ sshfs user@host:/dir/to/mount /mnt/sshdir -o IdentityFile=/percorso/chiave -p numero_porta

Se il mount avviene con successo è possibile usare il file-manager preferito per poter gestire in lettura e scrittura la nuova directory montata, che sia esso MC, dolphin, PCmanfm o altro.

Utenti e gruppi proprietari

Per impostazione predefinita sshfs adotta un'associazione "diretta" tra UID/GID della macchina remota e quella locale, il che significa per esempio che se il proprietario di un certo file sulla macchina remota è l'utente con UID 1002 anche in locale la proprietà del file sarà attribuita all'utente avente UID 1002. Potrebbero dunque sorgere problemi di permessi se su macchina remota e locale non sussiste un esatta corrispondenza utenti/UID e gruppi/GID. Un modo veloce per superare tale problema è specificare lo UID/GID durante il comando per montare le risorse remote, per esempio

# sshfs user@host:/dir/to/mount /mnt/sshdir -o idmap=user,uid=1001

fa sì che all'utenza usata per connettersi al server remoto sia associata in locale l'utenza avente UID 1001. Se si ha la necessità di fissare la corrispondenza di più utenze/gruppi è possibile creare degli appositi file di mappatura (si veda il manuale di sshfs).

Accesso ad altri utenti

Per permettere l'accesso del file system anche ad altri utenti, indipendentemente dai permessi associati ai file, è possibile mediante l'opzione: -o allow_other

Affinché abbia effetto però bisogna anche configurare fuse, ossia che /etc/fuse.conf contenga, non commentata, la riga user_allow_other, che di default è disabilitata per ragioni di sicurezza. Per maggiori informazioni si rimanda al manuale (man fuse).

È pertanto sconsigliato utilizzare tale impostazione, se si può fare altrimenti.

FAQ ed Errori Frequenti

failed to open /dev/fuse: No such file or directory

L'errore è dovuto alla mancanza del modulo del kernel relativo a fusefs. È necessario compilarlo come modulo o staticamente. Nei kernel pacchettizzati Debian è presente, ed è caricabile con un:

# modprobe fuse

mountpoint is not empty

Se si cerca di montare una risorsa in un mountpoint contenente già dei file, può apparire il seguente errore:

fusermount: mountpoint is not empty
fusermount: if you are sure this is safe, use the 'nonempty' mount option

Le soluzioni sono:

  • usare un mountpoint libero (consigliata)
  • appendere, dopo il comando sshfs l'opzione -o nonempty

Collegamenti esterni

[1] FUSE



Guida scritta da: MaXeR Swirl-auth80.png Debianized 80%
Estesa da:
Verificata da:
Wtf 16:58, 9 ott 2013 (CEST)
mm.barabba
HAL 9000 21:01, 18 ago 2019 (CEST)

Verificare ed estendere la guida | Cos'è una guida Debianized