Remote X Apps mini-HOWTO <author><htmlurl url="http://www.xs4all.nl/~zweije/" name="Vincent Zweije">, <htmlurl url="mailto:zweije@xs4all.nl" name="zweije@xs4all.nl"> <date>v, 14 luglio 1998 <abstract> Questo mini-HOWTO descrive come eseguire applicazioni X in remoto. Ovvero, come avere un programma X che scrive su un computer diverso da quello su cui sta girando. O viceversa: come far sí che un programma X giri su un computer diverso da quello a cui uno è seduto. L'accento in questo mini-HOWTO è sulla sicurezza. </abstract> <toc> <sect> Introduzione Questo mini-HOWTO è una guida a come far andare le applicazioni X in remoto. È stato scritto per parecchie ragioni. <enum> <item> Sono apparse su usenet molte domande su come far andare applicazioni X in remoto. <item> Vedo molti, molti suggerimenti di ``usare <tt/xhost +hostname/'' o perfino ``<tt/xhost +/'' per permettere le connessioni X. <bf/Questo è ridicolmente insicuro/, e ci sono metodi migliori. <item> Non conosco un documento semplice che descriva le opzioni che uno <em/davvero/ ha. Per favore informatemi <htmlurl url="mailto:zweije@xs4all.nl" name="zweije@xs4all.nl"> se ne sapete di più. </enum> Questo documento è stato scritto avendo in mente sistemi di tipo unix. Se il vostro sistema locale o remoto è di un altro tipo, potrete trovare qua come vanno le cose. Nonostante ciò, dovrete tradurre da soli gli esempi per adattarli al vostro sistema/i. La versione [inglese] più recente di questo documento è sempre disponibile sul WWW all'indirizzo <htmlurl url="http://www.xs4all.nl/~zweije/xauth.html" name="http://www.xs4all.nl/˜zweije/xauth.html">. È anche disponibile come il Linux Remote X Apps mini-HOWTO all'indirizzo <htmlurl url="http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps" name="http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps">. I Linux (mini-)HOWTO sono disponibili via http o ftp da <htmlurl url="http://sunsite.unc.edu/LDP/HOWTO/HOWTO-INDEX-2.html" name="sunsite.unc.edu">. La traduzione italiana può essere trovata sul sito <htmlurl url="http://pluto.linux.it" name="http://pluto.linux.it"> e mirror. Questa è la versione 0.5.1. Non ci sono garanzie, solo buone intenzioni. Sono disponibile a suggerimenti, idee, aggiunte, indicazioni utili, correzioni tipografiche, ecc... Tuttavia vorrei che questo rimanesse un documento semplice e leggibile, nello stile HOWTO inteso al meglio. I flame finiscono in <tt>/dev/null</tt>. Contenuto aggiornato l'ultima volta il 14 Luglio 1998 da <htmlurl url="http://www.xs4all.nl/~zweije/index.html" name="Vincent Zweije">. Traduzione italiana a cura di <htmlurl url="mailto:n.pero@mi.flashnet.it" name="Nicola Pero">. <sect> Letture Scelte Un documento correlato sul WWW è ``Che cosa fare quando Tk dice che il tuo display è insicuro'' [in inglese], <htmlurl url="http://ce-toolkit.crd.ge.com/tkxauth/" name="http://ce-toolkit.crd.ge.com/tkxauth/">. È stato scritto da <htmlurl url="http://ce-toolkit.crd.ge.com/people/kennykb.html" name="Kevin Kenny">. Suggerisce una soluzione all'autenticazione X simile a quella suggerita in questo documento (xauth). Tuttavia, Kevin ha più come obiettivo di usare xdm per guidare xauth per voi. X System Window System Vol. 8, ``Guida dell'Amministratore di X Window System'' [in inglese] da <htmlurl url="http://www.ora.com/" name="O'Reilly and Associates"> è stato anche portato alla mia attenzione come una buona fonte di informazione. Sfortunatamente, non ho potuto provarla. Tuttavia un altro documento molto simile a quello che state leggendo, intitolato ``Rendere X Windows Sicuro'' [in inglese], è disponibile presso <htmlurl url="http://ciac.llnl.gov/ciac/documents/ciac2316.html" name="http://ciac.llnl.gov/ciac/documents/ciac2316.html">. Potete anche provare usenet newsgroup, come <tt/comp.windows.x/, <tt/comp.os.linux.x/, e <tt/comp.os.linux.networking/. <sect> Lo Scenario State usando due computer. State usando l'X window system del primo per scrivere e guardare. State usando il secondo per fare qualche importante lavoro grafico. Volete far sí che il secondo mostri il suo output sul display del primo. X window system lo rende possibile. Naturalmente, avete bisogno di una connessione di rete per fare ciò. Preferibilmente una connessione veloce; il protocollo X mangia molte risorse di rete. Ma con un poco di pazienza e un protocollo di compressione adatto, potete eseguire applicazioni perfino attraverso un modem. Per la compressione del protocollo X, potreste voler provare dxpc <htmlurl url="http://ccwf.cc.utexas.edu/~zvonler/dxpc/" name="http://ccwf.cc.utexas.edu/˜zvonler/dxpc/"> o LBX <url url="http://www.ultranet.com/~pauld/faqs/LBX-HOWTO.html" name="http://www.ultranet.com/˜pauld/faqs/LBX-HOWTO.html"> (anche noto come <htmlurl url="http://suncite.unc.edu/LDP/HOWTO/mini/LBX" name="LBX mini-HOWTO">). Dovete fare due cose per ottenere tutto ciò <enum> <item> Dire al display locale (il server) di accettare connessioni dal computer remoto. <item> Dire all'applicazione (il client) di redirigere il suo output verso il display locale. </enum> <sect> Un Poco di Teoria La parola magica è <tt/DISPLAY/. Nell'X window system, un display consiste (semplificando) di una tastiera, un mouse e uno schermo. Un display è gestito da un programma server, conosciuto come server X. Il server mette a disposizione le capacità di visualizzazione agli altri programmi che si connettono a lui. Un display è indicato con un nome, per esempio: <itemize> <item> <tt/DISPLAY=light.uni.verse:0/ <item> <tt/DISPLAY=localhost:4/ <item> <tt/DISPLAY=:0/ </itemize> Il display consiste di uno hostname (come <tt/light.uni.verse/ e <tt/localhost/), due punti (<tt/:/), e un numero di sequenza (come <tt/0/ e <tt/4/). L'hostname del display è il nome del computer dove gira il server X. Se l'hostname è omesso si intende il local host [computer locale]. Il numero di sequenza è solitamente 0 -- può variare se ci sono più di un display connessi ad un solo computer. Se mai vi capita di incontrare una indicazione di display con un <tt/.n/ in più attaccato, si tratta del numero dello schermo. Un display può in realtà avere più di uno schermo. Di solito tuttavia c'è un solo schermo, che ha numero <tt/n=0/, per cui questo è il default. Esistono altre forme di <tt/DISPLAY/, ma le precedenti sono sufficienti per i nostri scopi. <sect> Dirlo al Client Il programma client (per esempio, la vostra applicazione grafica) sa a quale display deve connettersi da un esame della variabile di ambiente <tt/DISPLAY/. Tuttavia questo settaggio può essere cambiato, dando al client l'argomento di linea di comando <tt/-display hostname:0/ quando viene fatto partire. Alcuni esempi potrebbero rendere le cose più chiare. Il nostro computer è noto al mondo esterno come light, e siamo nel dominio uni.verse. Se stiamo facendo andare un server X normale, il display è conosciuto come <tt/light.uni.verse:0/. Vogliamo far partire il programma di disegno xfig su un computer remoto, chiamato <tt/dark.matt.er/, e stampare il suo output qua su light. Supponete di avere già fatto un telnet dentro al computer remoto, <tt/dark.matt.er/. Se avete csh che sta andando sul computer remoto: <tscreen><verb> dark% setenv DISPLAY light.uni.verse:0 dark% xfig & </verb></tscreen> o alternativamente: <tscreen><verb> dark% xfig -display light.uni.verse:0 & </verb></tscreen> Se avete sh che sta andando sul computer remoto: <tscreen><verb> dark$ DISPLAY=light.uni.verse:0 dark$ export DISPLAY dark$ xfig & </verb></tscreen> o, alternativamente, <tscreen><verb> dark$ DISPLAY=light.uni.verse:0 xfig & </verb></tscreen> o, naturalmente, anche: <tscreen><verb> dark$ xfig -display light.uni.verse:0 & </verb></tscreen> Sembra che alcune versioni di telnet trasportino automaticamente la variabile <tt/DISPLAY/ all'host remoto. Se avete una di queste, siete fortunati, e non dovete settarlo a mano. Altrimenti, la maggior parte delle versioni di telnet trasportano la variabile d'ambiente <tt/TERM/; con qualche hacking giudizioso è possibile "piggyback" [lett., portare indietro a maialino] la variabile <tt/DISPLAY/ sulla variabile <tt/TERM/. La idea con il piggybacking è di prepare degli script per ottenere le cose seguenti: prima di fare il telnet, si attacca il valore di <tt/DISPLAY/ a <tt/TERM/. Quindi si fa il telnet. All'estremità remota, nel file <tt/.*shrc/ appropriato, si legge il valore di <tt/DISPLAY/ da <tt/TERM/. <sect> Dirlo al Server Il server non accetterà connessioni da dovunque come niente fosse. Non volete che tutti possano visualizzare finestre sul vostro schermo. O leggere quello che state scrivendo -- ricordate che la tastiera è parte del vostro display! Troppa poca gente sembra realizzare che permette di accedere al proprio display pone a rischio la sicurezza. Qualcuno che ha accesso al vostro display può leggere e scrivere sui vostri schermi, leggere che tasti premete, e leggere quello che fa il vostro mouse. La maggior parte dei server conosce due modi di autenticare le connessioni verso di lui: con la lista di host (xhost) e con i magic cookie (xauth). Infine c'è ssh, la shell sicura, che può trasportare le connessioni X. <sect1> Xhost Xhost permette l'accesso sulla base degli hostname. Il server mantiene una lista di host che hanno il permesso di connettersi a lui. Può anche disabilitare completamente il controllo degli host. Attenzione: questo significa che non viene fatto nessun controllo, per cui <em/qualunque/ host può connettersi! Potete controllare la lista di host del server con il programma xhost. Per usare questo meccanismo nell'esempio precedente, fate: <tscreen><verb> light$ xhost +dark.matt.er </verb></tscreen> Questo permette tutte le connessioni dall'host <tt/dark.matt.er/. Non appena il vostro client X ha fatto la sua connessione e ha visualizzato una finestra, per sicurezza, revocate i permessi di altre connessioni con: <tscreen><verb> light$ xhost -dark.matt.er </verb></tscreen> Potete disabilitare il controllo degli host con: <tscreen><verb> light$ xhost + </verb></tscreen> Questo disabilita il controllo di accesso degli host e perciò permette a <em/chiunque/ di connettersi. Non dovete <em/mai/ fare questo in una rete in cui non vi fidate di <em/tutti/ gli utenti (come nel caso di Internet). Potete ri-abilitare il controllo degli host con: <tscreen><verb> light$ xhost - </verb></tscreen> xhost - da solo <em/non/ rimuove tutti gli host dalla lista di accesso (il che sarebbe abbastanza inutile - non potreste connettervi da nessun host, nemmeno dal vostro host locale). <em/Xhost è un meccanismo molto insicuro./ Non distingue fra utenti diversi sull'host remoto. Ancora, gli hostname (in realtà gli indirizzi) possono essere spoofati [=falsificati]. Questo è male se vi trovate in una rete di cui non fidarsi (per esempio già con un accesso ad Internet con PPP, via rete telefonica). <sect1> Xauth Xauth permette l'accesso a chiunque conosca il segreto giusto. Un tale segreto è chiamato codice di autorizzazione, o magic cookie [lett, biscottino magico]. Questo schema di autorizzazione è formalmente chiamato MIT-MAGIC-COOKIE-1. I cookie per display differenti sono memorizzati insieme nel file <tt>˜/.Xauthority</tt>. Il vostro <tt>˜/.Xauthority</tt> deve essere inaccessibile al gruppo/ad altri utenti. Il programma xauth amministra questi cookies, da cui il nomignolo xauth per questo schema di autorizzazione. Iniziando una sessione, il server legge un cookie dal file che è indicato dall'argomento <tt/-auth/. Fatto questo, il server permette connessioni solo da client che conoscono questo stesso cookie. Quando il cookie in <tt>˜/.Xauthority</tt> cambia, <em/il server non si accorgerà del cambiamento/. Server più recenti possono generare al volo cookies per i client che lo richiedono. Tuttavia i cookie sono ancora mantenuti dentro il server; non finiscono in <tt>˜/.Xauthority</tt> a meno che un client non li metta là. Secondo David Wiggins: <quote> Un ulteriore espediente che vi potrebbe interessare è stato aggiunto in X11R6.3. Attraverso la nuova estensione SECURITY, il server X stesso può generare e restituire nuovi cookie al volo. Per di più, i cookie possono essere designati come ``untrusted'' [di cui non fidarsi] in modo che applicazioni che fanno connessioni con tali cookie avranno delle restrizioni nelle operazioni. Per esempio, non potranno rubare input di tastiera/mouse, o contenuti di finestre, da altri client di cui ci si fida. C'è ora un sottocomando ``genera'' di xauth per rendere questa funzionalità almeno possibile da usare, se non semplice. </quote> Xauth ha un chiaro vantaggio di sicurezza sopra xhost. Potete limitare l'accesso a utenti specifici su computer specifici. Non soffre per lo spoofing [falsificazione] di indirizzi come fa xhost. E se volete, potete ancora usare xhost insieme a xauth per permettere connessioni. <sect2> Costruire i Cookie Se volete usare xauth, dovete far partire il server X con l'argomento <tt/-auth authfile/. Se usate lo script startx, è il posto giusto per farlo. Create una registrazione di autorizzazione, come mostrato sotto, nel vostro script startx. Passi scelti da <tt>/usr/X11R6/bin/startx</tt>: <tscreen><verb> mcookie|sed -e 's/^/add :0 . /'|xauth -q xinit -- -auth "$HOME/.Xauthority" </verb></tscreen> Mcookie è un programma minuscolo del pacchetto util-linux, sito primario <htmlurl url="ftp://ftp.math.uio.no/pub/linux/" name="ftp://ftp.math.uio.no/pub/linux/">. In alternativa, potete usare md5sum per rielaborare dei dati casuali (per esempio, presi da <tt>/dev/urandom</tt> o <tt/ps -axl/) in formato cookie: <tscreen><verb> dd if=/dev/urandom count=1|md5sum|sed -e 's/^/add :0 . /'|xauth -q xinit -- -auth "$HOME/.Xauthority" </verb></tscreen> Se non potete editare il file startx (perché non siete root), fate sistemare per bene startx al vostro amministratore di sistema, o fategli invece mettere su xdm. Se non può o non vuole, potete fare uno script <tt>˜/.xserverrc</tt>. Se avete questo script, xinit lo esegue al posto del vero server X. Poi potete far partire il vero server X da questo script con gli argomenti adeguati. Per fare questo, fate usare al vostro <tt>˜/.xserverrc</tt> la linea per i magic cookie vista prima per creare un cookie e quindi eseguire il vero server X: <tscreen><verb> #!/bin/sh mcookie|sed -e 's/^/add :0 . /'|xauth -q exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority" </verb></tscreen> Se usate xdm per controllare le vostre sessioni X, potete usare xauth facilmente. Definite la risorsa .authDir del DisplayManager in <tt>/etc/X11/xdm/xdm-config</tt>. Xdm passerà l'argomento <tt/-auth/ al server X server quando parte. Quando poi voi fate un log in sotto xdm, xdm mette il cookie nel vostro <tt>˜/.Xauthority</tt> per voi. Si veda xdm(1) per maggiori informazioni. Per esempio, il mio <tt>/etc/X11/xdm/xdm-config</tt> contiene la seguente linea: <tscreen><verb> DisplayManager.authDir: /var/lib/xdm </verb></tscreen> <sect2> Transportare il Cookie Ora che avete incominciato la vostra sessione X sull'host server <tt/light.uni.verse/ e che avete il vostro cookie in <tt>˜/.Xauthority</tt>, dovrete trasferire il cookie all'host client, <tt/dark.matt.er/. La cosa più semplice è quando le vostre directory su light e dark sono condivise. I file <tt>˜/.Xauthority</tt> sono gli stessi, per cui il cookie è trasportato simultaneamente. Tuttavia, c'è un inganno: quando mettete un cookie per <tt/:0/ in <tt>˜/.Xauthority</tt>, dark penserà che sia un cookie per sé stesso invece che per light. Dovete usare un host name esplicito quando create un cookie; non potete tralasciarlo. Potete installare lo stesso cookie sia per <tt/:0/ che per <tt/light:0/ con: <tscreen><verb> #!/bin/sh cookie=`mcookie` xauth add :0 . $cookie xauth add "$HOST:0" . $cookie exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority" </verb></tscreen> Se le home directory non sono condivise, potete trasportare il cookie per mezzo di rsh, la shell remota: <tscreen><verb> light$ xauth nlist :0 | rsh dark.matt.er xauth nmerge - </verb></tscreen> <enum> <item> Estrae il cookie dal vostro <tt>˜/.Xauthority</tt> locale (<tt/xauth nlist :0/). <item> Lo trasferisce a dark.matt.er (<tt/| rsh dark.matt.er/). <item> Lo mette nel <tt>˜/.Xauthority</tt> là (<tt/xauth nmerge -/). </enum> È possibile che rsh non vada bene per voi. A parte questo, rsh ha anche un incoveniente per quanto rigurda la sicurezza (host spoofati [falsificati] di nuovo, se non ricordo male). Se non potete o non volete usare rsh, potete anche trasferire il cookie manualmente, tipo: <tscreen><verb> light$ echo $DISPLAY :0 light$ xauth list $DISPLAY light/unix:0 MIT-MAGIC-COOKIE-1 076aaecfd370fd2af6bb9f5550b26926 light$ rlogin dark.matt.er Password: dark% setenv DISPLAY light.uni.verse:0 dark% xauth add $DISPLAY . 076aaecfd370fd2af6bb9f5550b26926 dark% xfig & [15332] dark% logout light$ </verb></tscreen> Si vedano anche rsh(1) e xauth(1x) per maggiori informazioni. Potrebbe essere possibile fare un ``piggyback'' del cookie nella variabile <tt/TERM/ o <tt/DISPLAY/ quando fate un telnet all'host remoto. Questo funzionerebbe nello stesso modo in cui si fa il piggyback della variabile <tt/DISPLAY/ sulla variabile <tt/TERM/. Si veda la sezione 5: Dirlo al Client. Dal mio punto di vista qua sono fatti vostri, ma sono interessato se qualcuno potesse confermarlo o negarlo. <sect2> Usare il Cookie Una applicazione X su dark.matt.er, come la xfig di prima, guarderà automaticamente in <tt>˜/.Xauthority</tt> là per il cookie con cui autenticarsi. <sect1> Ssh Le registrazioni di autorità sono trasmesse senza crittografia. Se siete anche solo impensieriti dall'idea che qualcuno possa snoopare [annusare] le vostre connessioni, usate ssh, la shell sicura. Andrà bene per trasportare X sopra connessioni crittate. E inoltre, è grande anche per molti altri motivi. È un buon miglioramento strutturale del vostro sistema. Visitate semplicemente <htmlurl url="http://www.cs.hut.fi/ssh/" name="http://www.cs.hut.fi/ssh/">, la home page di ssh. Chi conosce qualcosa d'altra sugli schemi di autenticazione o di crittografia delle connessioni X? Forse kerberos? <sect> Risoluzione dei Problemi La prima volta che cercate di lanciare una applicazione X remota, di solito non funziona. Ecco qua qualche comune messaggio di errore, le sue probabili cause, e soluzioni per aiutarvi. <tscreen><verb> xterm Xt error: Can't open display: </verb></tscreen> Non c'è una variabile <tt/DISPLAY/ nell'ambiente, e non avete neanche parlato all'applicazione con il flag <tt/-display/. L'applicazione assume una stringa vuota, ma questa è sintatticamente invalida. Per risolvere questo problema, assicuratevi di aver settato correttamente la variabile <tt/DISPLAY/ nell'ambiente (con <tt/setenv/ o <tt/export/ a seconda della vostra shell). <tscreen><verb> _X11TransSocketINETConnect: Can't connect: errno = 101 xterm Xt error: Can't open display: love.dial.xs4all.nl:0 </verb></tscreen> L'Errno 101 è ``Network is unreachable'' [rete irraggiungibile]. L'applicazione non ha potuto fare una connessione di rete al server. Controllate di avere settato correttamente <tt/DISPLAY/, e che la macchina server sia raggiungibile dal vostro client (lo deve essere, dopotutto siete probabilmente loggati nel server e state facendo un telnet al client). <tscreen><verb> _X11TransSocketINETConnect: Can't connect: errno = 111 xterm Xt error: Can't open display: love.dial.xs4all.nl:0 </verb></tscreen> L'Errno 111 è ``Connection refused'' [Connessione rifiutata]. La macchina server a cui state cercando di connettervi è raggiungibile, ma là il server indicato non esiste. Controllate di stare usando l'host name giusto e il numero di display giusto. <tscreen><verb> Xlib: connection to ":0.0" refused by server Xlib: Client is not authorized to connect to Server xterm Xt error: Can't open display: love.dial.xs4all.nl:0.0 </verb></tscreen> Il client ha potuto fare una connessione al server, ma il server non permette al client di usarlo (non è autorizzato). Assicuratevi di avere trasportato il magic cookie corretto al client, e che non sia espirato (il server usa un nuovo cookie quando incomincia una nuova sessione). </article>