OpenSSH: X11 forwarding

Da Guide@Debianizzati.Org.
Versione del 28 nov 2015 alle 14:45 di HAL 9000 (discussione | contributi) (aggiunta configurazione lato server e requisiti)
Vai alla navigazione Vai alla ricerca
Document-page-setup.png Attenzione: questo articolo è ancora incompleto e in fase di scrittura da parte del suo autore.

Sentitevi liberi di contribuire, proponendo modifiche alla guida tramite l'apposita pagina di discussione, in modo da non interferire con il lavoro portato avanti sulla voce. Per altre informazioni si rimanda al template.


Edit-clear-history.png Attenzione. Questa guida è da considerarsi abbandonata, per via del tempo trascorso dall'ultima verifica.

Potrà essere resa obsoleta, previa segnalazione sul forum, se nessuno si propone per l'adozione.


Debian-swirl.png Versioni Compatibili

Debian 7 "wheezy"
Debian 8 "jessie"
OpenSSH

Sommario


Introduzione

L'uso del comando ssh, una volta configurato il server e aggiunte le credenziali di autenticazione dell'utente del client, permette l'esecuzione di comandi su una macchina remota, ma soltanto tramite una shell testuale. Perciò un'applicazione può essere lanciata con interfaccia grafica soltanto se fa uso delle librerie ncurses o comunque che non richiedono la presenza di un server grafico X attivo.

Per poter lanciare un'applicazione grafica che richiede l'esecuzione di un server grafico X (per esempio perché sviluppata con uso delle librerie GTK, Qt, ecc...) e interagirvi come si farebbe con una qualsiasi applicazione, è necessario reindirizzare (forwarding) tutte le chiamate dirette al server X della macchina remota sul server X locale, ossia la stessa del client ssh.

Si noti quindi che non è necessario né che sia in esecuzione né che sia installato un server grafico X sulla macchina remota. Per poter avviare un'applicazione grafica è invece necessario che sia installato e in esecuzione un server X sulla macchina client.

Warning.png ATTENZIONE
Si presume che la macchina di destinazione sia fidata, perché anche se i comandi sono eseguiti soltanto su quella macchina, tutte le chiamate alle librerie che fanno uso del server grafico sono eseguite sulla macchina locale. Di conseguenza c'è la possibilità di subire un attacco sulla macchina client da quella remota: in particolare rivolto a tutte le altre applicazioni (di qualunque utente) eseguite sullo stesso server X, che potrebbero essere monitorate e/o manipolate, anche riguardo all'input immesso dall'utente attraverso mouse e tastiera.


Lato server

Requisiti:

  • installare e in esecuzione il server SSH';
  • autorizzare gli accessi (con chiave per utente/host o password) come per la connessione normale (senza X11 forwarding);
  • abilitare X11Forwarding (vedere la sezione successiva), di default disabilitata.

Non è necessario che sia in esecuzione o anche solo installato un server grafico X sul server.

Abilitare X11Forwarding

È necessario che sia presente (e non commentata) in /etc/ssh/sshd_config la direttiva:

X11Forwarding yes

Con privilegi di amministrazione è sufficiente aprire il file con il proprio editor di testo preferito (per esempio nano):

# nano /etc/ssh/sshd_config

aggiungere la riga su X11Forwarding yes o decommentarla (rimuovendo il carattere # iniziale) e salvare (con nano premere Ctrl-o e poi Ctrl-x per uscire).

Infine ricaricare la configurazione del server:

# service ssh reload

È da notare che disabilitare X11Forwarding non incrementa la sicurezza della macchina remota che esegue il server ssh, tuttavia potrebbe comunque essere nell'interesse di chi amministra ridurre i rischi per gli utenti autorizzati a collegarsi dalle loro postazioni, e per questo è stata pensata questa opzione.

Per altre possibili configurazioni si rimanda a questa parte della guida.

Lato client

Requisiti:

  • installato e in esecuzione il server grafico Xorg;
  • aperta una sessione grafica per l'utente corrente (è sufficiente un login da un display manager come gdm3/kdm/lightdm/xdm/... oppure l'uso di startx da un terminale virtuale /dev/tty1, /dev/tty2, ecc...);
  • installato il client ssh.

In particolare si controlli che siano definite le variabili d'ambiente $DISPLAY e $XAUTHORITY:

$ echo "$DISPLAY"
:0
$ echo "$XAUTHORITY"
/la-propria-home/.Xauthority

Access control

Per limitare l'esposizione delle applicazioni eseguite sul server X locale, rispetto a possibili attacchi da parte dell'applicazione eseguita su macchina remota (ma a cui è dato accesso allo stesso server X locale per potervi interagire), Xorg dispone di un primitivo controllo di accesso (access control), che consente di marcare alcune applicazioni come non fidate (untrusted), in base alla sessione con cui si sono registrate presso il server X.

Ciò non risolve completamente le problematiche di sicurezza, ma limita la possibilità di ascolto alle sole applicazioni untrusted. Come risultato di questa impostazione, un'applicazione remota non avrà gli stessi permessi di una eseguita localmente, per cui alcune operazioni potrebbero essergli precluse: in caso questo interferisca con il suo normale funzionamento, sarà però necessario dargli totale accesso, ossia considerarla fidata (trusted), consci però dei possibili rischi di sicurezza per tutte le applicazioni (anche di altri utenti) eseguite sullo stesso server X e per gli input immessi dall'utente.

Utilizzo

Dalla macchina client, è sufficiente lanciare ssh con l'opzione -X:

$ ssh -X username_remoto@host_remoto
username_remoto@host_remoto:~$       (<-- sessione SSH)

per avviare una nuova sessione della shell testuale predefinita.

All'interno di questa sessione sarà possibile avviare applicazioni grafiche sulla macchina remota, che saranno visualizzate e si potrà interagirvi sul server X locale, come se si trattasse di una qualsiasi altra applicazione, ma con access control attivo per isolare parzialmente questa applicazione (untrusted) da quelle locali.

Per esempio:

username_remoto@host_remoto:~$ evince

lancia il programma evince sulla macchina remota, visualizzandolo sul server X locale in esecuzione. Se si apre un documento, si noterà infatti che si sta esplorando il file system dell'utente remoto sulla macchina remota.

Quando si ha terminato, è sufficiente chiudere la connessione, chiudendo il terminale oppure con exit:

username_remoto@host_remoto:~$ exit  (<-- sessione SSH)
$                                    (<-- shell locale)

Compressione del traffico

Un'opzione utile è -C, per abilitare la compressione del traffico, e in particolare quello reindirizzato al server X locale, il che può velocizzare i tempi di risposta delle applicazioni remote:

$ ssh -X -C username_remoto@host_remoto

Senza access control

Warning.png ATTENZIONE
Un'applicazione remota, in riferimento alla visualizzazione sul server X locale, avrà gli stessi permessi di una eseguita localmente, rendendo possibile il monitoraggio e la manipolazione delle altre applicazioni grafiche eseguite sullo stesso server (anche da parte di altri utenti) e dell'input immesso dall'utente con mouse e tastiera.

Essere certi di avere necessità di una connessione trusted prima di effettuarla, e soltanto se si può considerare sicura la macchina di destinazione.


Per disattivare il controllo di accesso, effettuando una connessione fidata (trusted X11 forwarding), si deve utilizzare l'opzione -Y:

$ ssh -Y username_remoto@host_remoto
username_remoto@host_remoto:~$        (<-- sessione SSH)

Configurazione

Per rendere automatiche tali configurazioni, si rimanda a questa parte della guida.




Guida scritta da: HAL 9000 11:25, 28 nov 2015 (CET) Swirl-auth20.png Debianized 20%
Estesa da:
Verificata da:

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