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

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
(verificata per Stretch e Buster, rimosse informazioni relative a versioni obsolete di Debian)
 
(37 versioni intermedie di 8 utenti non mostrate)
Riga 1: Riga 1:
Ho provato a rendere pi� leggibile il codice della pagina lasciando un rigo vuoto per ogni entry. In questo modo si evita di usare i br e non � necessario mettere pi� link sulla stessa riga per avere una spaziatura verticale omogenea. Secono me � importante renedere facilmente modificabile questa pagina.
{{File_System
|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).


In questo modo aumenta leggermenta la spaziatura verticale (confrontare la sezione "Browser Web" con il resto) ma aumenta parecchio la facilit� di editing IMHO.
'''<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]].


: [[Utente:TheNoise|~ The Noise]] 14:08, Nov 9, 2005 (EST)
== Installazione ==
Il pacchetto <code>sshfs</code> e le utility per gestire FUSE sono già presenti in Debian, quindi l'installazione si riduce ad un semplice:
<pre>
# apt install sshfs
</pre>
(da eseguirsi con [[privilegi di amministrazione]])


Ottimo!
== 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 <code>fuse</code> se è installato; né ha più alcuna importanza l'appartenenza al gruppo ''fuse'', in precedenza richiesta.


Pensavo che, anche se una descrizione di ogni programma sarebbe comoda, la cosa sia praticamente irrealizzabile (o meglio, non mantenibile)...
== Utilizzo e Test ==
L'utilizzo è semplice:
'''sshfs''' [user@]host''':'''[dir] mountpoint [options]
anche se spesso si può semplicemente usare senza opzioni:
<pre>
$ sshfs user@host:/dir/to/mount /mnt/sshdir
</pre>
dove
; <code>user</code>: è l'utente della macchina remota, se omesso verrà utilizzato l'username dell'utente che lancia il comando;
; <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;


eventualmente, quando � presente una scheda, la si potrebbe linkare a fianco del nome...:
per controllare la riuscita del comando, si può analizzare l'output del comando:
<pre>
<pre>
nomeprogramma - scheda
$ findmnt
</pre>
</pre>


che ne dite?
Per quanto riguarda lo smontaggio (unmounting) il comando è il seguente:
<pre>
$ fusermount -u /mnt/sshdir
</pre>


altra cosa...
per le opzioni consultare il file
si potrebbe variare leggermente la struttura...
<pre>
magari:
$ man sshfs
{|
</pre>
|Categoria
tra le più comuni:
|Closed
'''-p''' ''PORT'' equivalente a <code>-o port=PORT</code>
|Free
'''-C''' equivalente a <code>-o compression=yes</code>
|-
'''-F''' ''ssh_configfile'' specifica un file di configurazione alternativo
|Browser Web
'''-1''' equivalente a <code>-o ssh_protocol=1</code>
|Opera
|Firefox
|}
usando la 'sezione' che utilizziamo ora per la singola applicazione per le categorie...


: [[Utente:MaXeR|MaXeR]] 12:10, Nov 13, 2005 (EST)
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!):
<pre>$ sshfs user@host:/dir/to/mount /mnt/sshdir -o IdentityFile=/percorso/chiave -p numero_porta</pre>


Ottima l'idea di affincare il link della scheda se presente ;-). In questo modo possiamo tranquillamente inserire i link alle homepage, che poi non devono essere rimossi se c'� anche una scheda. Inoltre cos� � facilissimo vedere i programmi che hanno la scheda.
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.


Per la modifica sulla struttura... ehm non ho capito cosa intendi.
=== Utenti e gruppi proprietari ===


: [[Utente:TheNoise|~ The Noise]] 02:46, Nov 14, 2005 (EST)
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


ho apportato qualche miglioria grafica...
<pre># sshfs user@host:/dir/to/mount /mnt/sshdir -o idmap=user,uid=1001</pre>


ho pensato di aggiungere delle icone, cos� da vedere subito quali sistemi operativi sono supportati da questi programmi...
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).


Altra cosa: ho suddiviso il tutti in categorie pi� grandi... resta solo da ordinare le voci alfabeticamente :-D
==== Accesso ad altri utenti ====


[[Utente:MaXeR|MaXeR]] 11:22, Nov 24, 2005 (EST)
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>


Bellissimo lavoro MaXeR! La nuova veste grafica � di gran lunga pi� accattivante.
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>).


: [[Utente:TheNoise|~ The Noise]] 13:15, Nov 24, 2005 (EST)
È pertanto '''sconsigliato''' utilizzare tale impostazione, se si può fare altrimenti.


ho modificato ed ampliato la sezione degli editor di testo... ma manca ancora un sacco di roba! :-D
== FAQ ed Errori Frequenti ==
 
=== failed to open <code>/dev/fuse</code>: No such file or directory ===
pensavo che moltissimi software open source possono anche girare, previa ricompilazione, su MacOSX e anche su win+Cygwin, ed � probabile che esistano in rete anche gi� ricompilati.
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>
magari si pu� aggiungere una nota a riguardo nell'intro, voi che dite?
# modprobe fuse
 
</pre>
:[[Utente:Tindal|Tindal]] 10:10, Dic 18, 2005 (EST)
 
D'accordo sulla nota iniziale. Dovremmo comunque decidere quando un programma � considerato compatibile con un dato sistema.
 
Si dovrebbe fare un po' di chiarezza anche riguardo il software Mac: intendiamo MacOS oppure MacOSX? Io direi di orientarci su quest'ultimo dato che ormai MacOS � solo una versione obsoleta IIRC. Con MacOSX la questione della compatibilit� � '''molto''' diversa che con MacOS (e quanto meno nelle entry da me inserite mi riferivo a MacOSX). Se dite si aggiungo la X a MacOS nella legenda ;-).
 
Inoltre come regola generale direi di focalizzarci sui programmi principali (in base a maturit�/funzionalit�/usabiltit�) pittosto che elencare proprio ogni programma di cui si conosce l'esistenza (ad esempio eviterei i programmi di cui siano disponibili solo versioni CVS).
 
: [[Utente:TheNoise|~ The Noise]] 12:18, Dic 18, 2005 (EST)
 
Effettivamente non avevo valutato la differenza tra MacOS e MacOSX... ne sono un po' fuori...
 
riguardo le accoppiate ''win+Cygwin'', metterei, come avete gi� proposto, una nota nell'introduzione, ma non di pi�...altrimenti diventerebbe un po' troppo pesante come cosa...
 
Sono completamente d'accordo, inoltre, sulla scelta delle applicazioni secondo la maturit�... sia per seriet� (non si pu� suggerire ad un utente un programma in alpha) sia per stabilit� :-)
 
[[Utente:MaXeR|MaXeR]] 08:35, Dic 20, 2005 (EST)
 
== riguardo la scheda dei singoli programmi... ==
 
anche secondo me � un'ottima idea... solo che invece di:
 
::nomeprogramma - <nowiki>{{icone}}</nowiki> - scheda
 
si potrebbe fare un template anche per le schede e metterci un'icona, una cosa tipo
 
::nomeprogramma - <nowiki>{{icone}} - {{scheda}}</nowiki>
 
--[[Utente:Hanska|hanska]] 05:06, Gen 8, 2006 (EST)
---------------
avrei qualche dubbio su protools, nella sezione audio: forse sono rimasto un po' in dietro, ma da quello che mi risulta protools dipende da hardware dedicato, e non so se c'entra con il resto.
 
:[[Utente:Tindal|Tindal]] 17:47, 10 Apr 2006 (EDT)
----
Si protools richiede hardware dedicato a livello di consolle di missagio e interfacce audio varie, ma ''che io sappia'' gia su dei mac. Ovviamente non l'ho mai provato dato che si parla di hd/sw da 10.000� a salire, e non lo conosco di persona.
 
Tuttavia lo conosco dai continui raffronti che se ne fa con ardour. Infatti, fin dalla homepage, ardour viene presentato come una DAW in grado si sostituire le soluzioni HW/SW dedicate: http://ardour.org/key_features. Diversi studi di registrazione usano gi� ardour (certo sono ancora una minoranza ;-). Inoltre sulla ml LAU (linux-audio-users) vengono continuamente fatte comparazioni tra le features dei due, quindi accostarli mi � apparso del tutto naturale.
 
Effettivamente l'accostamento � un p� al limite per gli scopi della tabella. Ma il concetto � che con un pc ad-hoc ed interfacce audio standard (schede audio multicanale e superfici di controllo) puoi fare un sistema di HD recording realtime a 24 canali, che con soluzioni proprietarie costerebbe un occhio della testa.
 
Comunque... se pensi sia forzato come accostamento lo togliamo. Pensi che la parte pro-audio sia troppo specialistica per la tabella software (al limite potremmo spostarla in una pagina separata)?


Ciao ;-)
=== mountpoint is not empty ===
: [[Utente:TheNoise|~ The Noise]] 03:51, 11 Apr 2006 (EDT)
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>


== Categoria video ==
=== 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
}}


Manca la categoria video, sia per l'editing (esiste un equivalente di virtualdub per linux?) che per l'acquisizione video e gestione schede TV.
[[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