Manovrare X da remoto: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
(rimosse parti coperte da altre guide, aggiunto warning)
m (verificata)
 
(7 versioni intermedie di uno stesso utente non sono mostrate)
Riga 1: Riga 1:
{{Guida da adottare|[[Utente:HAL 9000|HAL 9000]]}}
{{Versioni compatibili|Jessie|Stretch|Buster}}
== Introduzione ==
== Introduzione ==
Nelle distribuzioni GNU/Linux e POSIX l'interfaccia grafica (''GUI'') non è parte del kernel ma gestita da un programma a parte: l' ''X window system'' o semplicemente server '''X'''. In particolare [[Xorg]] è l'implementazione del server X più utilizzata attualmente.
Nelle distribuzioni GNU/Linux e in generale nei sistemi UNIX e Unix-like l'interfaccia grafica (''GUI'') non è parte del kernel ma gestita da un programma a parte: l' ''X window system'' o semplicemente server '''X''', di cui [[Xorg]] rappresenta l'implementazione attualmente più diffusa.


Le richieste dagli X-client di gestire le finestre rivolte al server avvengono di solito localmente, ma nulla impedisce di gestire le finestre attraverso la rete, permettendo a utenti remoti di effettuare il login sul server grafico locale.
Le richieste dai client X di gestire le finestre avvengono di solito localmente, ma nulla impedisce di gestire le finestre attraverso la rete, permettendo a utenti remoti di effettuare il login sul display manager (<code>xdm</code>, <code>gdm</code>, <code>kdm</code>, <code>lightdm</code>, ecc...) per accedere al server X locale attraverso ''XDMCP'' ('''''X''' '''D'''isplay '''M'''anager '''C'''ontrol '''P'''rotocol'').
 
Per semplicità di configurazione, e per la stabilità dimostrata attraverso i passaggi di versione di Debian, in questa guida si considera unicamente '''<code>xdm</code>'''.


{{Warningbox | Ogni comunicazione da e verso il server X avverrebbe in chiaro, e sarebbe pertanto manipolabile e/o ascoltabile sulla rete. '''Questo rappresenta un <u>enorme rischio</u> per la sicurezza del sistema!'''
{{Warningbox | Ogni comunicazione da e verso il server X avverrebbe in chiaro, e sarebbe pertanto manipolabile e/o ascoltabile sulla rete. '''Questo rappresenta un <u>enorme rischio</u> per la sicurezza del sistema!'''
Riga 9: Riga 11:
Se è possibile, si raccomanda caldamente invece di configurare una connessione [[SSH]] e di abilitare l'[[OpenSSH: X11 forwarding|X11 forwarding]] per avviare un'applicazione grafica o anche un'intera sessione.}}
Se è possibile, si raccomanda caldamente invece di configurare una connessione [[SSH]] e di abilitare l'[[OpenSSH: X11 forwarding|X11 forwarding]] per avviare un'applicazione grafica o anche un'intera sessione.}}


== Configurazione ==
== Lato server ==
Il server X di solito viene iniziato da un X Display Manager.Un X display manager è xdm,gdm,kdm che forniscono svariati X displays locali o remoti specificati in Xservers usando XDMCP come specificato nel file Xaccess.
=== Installazione ===
Con [[privilegi di amministrazione]] è necessario installare <code>xdm</code>, oltre ovviamente al server [[Xorg]], se ancora non presente nella macchina che farà da server. Per esempio con [[apt]] basta:
<pre>
# apt install xdm xorg
</pre>
 
=== Configurazione di xdm ===
Sempre con [[privilegi di amministrazione]], è sufficiente modificare i file di configurazione indicati in questa sezione con un editor di testo, per esempio [[nano]]:
<pre>
# nano /etc/X11/xdm/xdm-config
</pre>


In <code>/etc/X11/xdm/xdm-config</code> commenta:
In <code>/etc/X11/xdm/xdm-config</code> commenta:
 
<pre>
DisplayManager.requestPort:  0
DisplayManager.requestPort:  0
 
</pre>
che diventa:
che diventa:
<pre>
!DisplayManager.requestPort:  0
</pre>


!DisplayManager.requestPort:  0
Salva il file (con <code>nano</code> premi <code>Ctrl-o</code> e per uscire <code>Ctrl-x</code>).
In <code>/etc/X11/xdm/Xaccess</code> togli il comento a
 
#*        #any host can get a login window


In modo analogo, apri il file <code>/etc/X11/xdm/Xaccess</code> e togli il comento a:
<pre>
#*        #any host can get a login window
</pre>
che diventerà:
che diventerà:
       
<pre> 
*        #any host can get a login window
*        #any host can get a login window
</pre>


Questo metterà l'Xserver in broadcast mode che butterà giù una lista di tutti gli Xserver in Willing di accetare di connettersi all'X server.
Al posto di <code>*</code> è possibile anche specificare, uno a uno, gli [[host]] da cui si intende accettare la connessione, anche con uso di pattern. Per esempio basta scrivere (al posto di <code>*</code>):
<pre>
192.168.0.*
</pre>
per accettare connessioni dagli host appartenenti alla rete <code>192.168.0.0/24</code>, ossia tutti gli indirizzi compresi da <code>192.168.0.1</code> a <code>192.168.0.254</code>. Sono permessi anche [[hostname]], per esempio se definiti in <code>/etc/hosts</code>, e l'uso di indirizzi multicast a cui limitare l'ascolto. Per maggiori informazioni si consultino gli esempi scritti nel file.


Se vuoi permettere connesioni solo da parte di certi host che un sezione nello stesso file che si chiama CHOOSER
Per finire è necessario specificare di restare in ascolto sulla porta TCP, modificando il file <code>/etc/X11/xdm/Xservers</code>:
 
In <code>/etc/X11/fs/config</code> commenta così:
 
#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 già installato. L'X server può essere lanciarlo con un semplice:
<pre>
<pre>
# X &
:0 local /usr/bin/X :0 vt8 -nolisten tcp
</pre>
</pre>
Questo farà partire un server X in background. Comparirà uno schermo con lo sfondo grigio e un X come puntatore del mouse che puoi muovere per lo schermo... niente di speciale nè di carino da vedere .... inutile.
che diventerà:
 
Il comando di sopra quindi inizia un X server, che semplicemente sta lì 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 ciò non sarebbe molto pratico nè di facile utilizzo.
 
C'è bisogno di un ''X-client'' e di un ''window-manager''.
 
Un window manager puo dare quell'usabilità 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 è partito un window-manager muovere e gestire finestre diventa interattivo e lanciare applicazioni diventa più facile. Il <code>-display :0</code> per aprire finestre sull X-server. Un display non è nient'altro che uno schermo al quale collegarsi. Di default quando X parte lui inizia un display sul 'canalè :0 della macchina locale.
 
Quando parte una sessione X automaticamente va a piazzare il display al quale è collegata nella variabile $DISPLAY. Se non dovesse essere stata dichiarata alcuna variabile di default X si andra a piazzare sul display <code>:0.0</code>.
 
In ogni caso per lanciare X dalla console è un sufficiente lanciare uno ''startx'', che inizierà un X-server su display <code>:0</code>.
 
Molti X-server specialmente nel mondo GNU/Linux usano ''xdm'' o ''gdm'' o ''kdm''. Xdm stà per "X Display Manager"; questi hanno lo scopo di accogliere l'utente con un X-client che è 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>
 
Questo permetterà connessioni dalla macchina 192.168.0.2.
Sul client invece digita :
<pre>
<pre>
$ xterm -display 192.168.0.1(ip Xserver):0
:0 local /usr/bin/X :0 vt8
</pre>
</pre>
Sul server X adesso dovresti vedere un finestra di xterm. &Egrave; successo che un X-client si è collegato ad un xserver aprendo una finestra di xterm lì.
dove:
 
* '''<code>:0</code>''' è l'identificativo del server X che sarà avviato e dev'essere libero; se ce n'è già uno in esecuzione, utilizzarne un altro (<code>:1</code>, <code>:2</code>, ecc...);
Riguardo la sicurezza il protocollo X è apllicabile solo in ambienti fidati Lan e non è cosigliabile avere sessioni X attraverso la grande rete. Se vuoi utilizzare X attraverso la rete è 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 è xhost ma anche meglio con un programma xauth utilizzato per autenticare i clients: ''Xauth'' può funzionare in vari modi: uno di essi è 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 rifiuterà la connessione. Xserver di default è in ascolto sulla porta
* '''vt8''' è il terminale virtuale da utilizzare, in questo caso <code>tty8</code> (accessibile con <code>Ctrl-Alt-F8</code>). Sceglierne uno qualsiasi libero (<code>vt9</code>, <code>vt10</code>, ecc...).


* 6000 per il display :0
È possibile anche specificare più linee, se si intendono avviare più server X simultaneamente. In tal caso è consigliabile lasciare l'opzione '''<code>-nolisten tcp</code>''' su quelli per cui non è previsto l'accesso remoto, come misura di sicurezza.
* 6001 per display:01 
''ecc.''


Programmi come xdm , gdm o kdm sono demoni che vanno in background, sono soliti essere iniziati da init al boot e sono sempre in attività. 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 così via.  
{{Warningbox | Si ricorda nuovamente che, anche se l'accesso deve essere autenticato, la comunicazione non è criptata. Per cui chiunque nella rete potrebbe ascoltare le credenziali di accesso e il suo uso è '''altamente sconsigliato''' al di fuori della LAN, e anche in questo caso esclusivamente se tutti gli host e gli utenti connessi alla LAN possono sempre essere considerati fidati.}}


Xdm può 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.
Per rendere effettive le modifiche, è necessario riavviare il display manager:
<pre>
<pre>
X -query 192.168.1.2
# service xdm restart
</pre>
</pre>
o
e questo conclude la configurazione lato server. <code>xdm</code> resterà in ascolto sulla porta 177 del protocollo UDP per ricevere richieste di autenticazione, secondo il protocollo XDMCP, dagli host specificati nel file <code>Xaccess</code>. Il server <code>Xorg</code> resta invece in ascolto sulla porta 6000 del protocollo TCP e successive, in base al display utilizzato, e permetterà l'accesso soltanto previa autenticazione, di default in base alla conoscenza di una sequenza casuale generata in precedenza: il ''magic cookie'' (per maggiori informazioni si rimanda alla lettura del manuale di <code>xauth</code>), comunicato da <code>xdm</code> per permettere l'autenticazione.
 
== Lato client ==
=== Installazione ===
È necessario il solo pacchetto <code>xorg</code>, per cui se non fosse installato, con [[privilegi di amministrazione]]:
<pre>
<pre>
X -broadcast
# apt install xorg
</pre>
</pre>


L'uso di X attraverso la rete può delle volte causare dei problemi di rendimento e performance. Il protocollo X trasmetterà tutte le righe, tutte le aree anche non necessarie, non c'è una cache nè alcun tipo di funzionalità "trasmetto solo cosa è cambiato".Significa che se un' area è stata ridisegnata tre volte il protocollo X trasmetterà tutte le volte che quell'area è stata cambiata mentre basterebbe trasmettere solo l'ultima delle tre e questo potrebbe risultare un pò dannoso su connessioni lente. Il protocollo VNC è 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 è 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'è bisogno della presenza di un vncserver da essere lanciato manualmente. Per prima cosa bisogna impostare una vncpasswd che poi verrà usata per il login. Ci si collega con ssh senza l'opzione ''-X'':
=== Utilizzo ===
Se l'indirizzo IP del server è <code>192.168.0.2</code>, dal client sarà sufficiente il comando:
<pre>
<pre>
ssh username@hostremoto
# X -query 192.168.0.2 :0 vt8
</pre>
</pre>
Poi una volta collegato lanci ''vncserver :1'' che in pratica mette vncserver in ascolto sul display 1 cioè tcp port 5901.Dopo puoi lanciare il vnc client come per esempio tightvncviewer o vncviewer o svncviewer in questo modo :
per connettersi a <code>xdm</code> sulla macchina server. Si noti che il display e il terminale virtuale non devono combaciare per forza con quelli scelti sul server, l'unica cosa importante è che siano entrambi liberi sul client, in maniera analoga a quanto visto in precedenza per il server.
 
In alternativa, se si è nella stessa rete locale del server, è anche possibile:
<pre>
<pre>
vncviewer hostremoto:1
# X -broadcast :0 vt8
</pre>
</pre>
Poi ti verrà chiesta la password e tu introdurrai quella stabilita in precedenza et voilà eccoti il desktop remoto in locale in tutto il suo splendore.
per mandare il messaggio di richiesta in ''broadcast'' (ossia a tutti gli [[host]] della rete), per effettuare la connessione al server X del primo ''host'' che risponde.
Questa configurazione presenta dei rischi, porta 5900 e 5800 deve essere aperta nel firewall e la comunicazione è in chiara. Per criptarla c'è bisogno di un tunnel ssh. Ancora una volta l'amico ssh ci viene incontro:
<pre>
ssh -C -L 5901:127.0.0.1:5901 user@remotehost
</pre>
questo comando metterà 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 permetterà di criptare la tua connessione verso il server vnc attraverso un tunnel ssh.


== X su altri sistemi operativi ==
Si visualizzerà <code>xdm</code> in esecuzione sul server, che si potrà utilizzare per autenticarsi, utilizzando le credenziali di accesso di un utente che ha accesso alla macchina remota.


Molte persone credono che X sia stato progettato solo per GNULinux e unix-like ma in realtà come ogni prodotto unix il primo intento è la portabilità verso quanti più OS è possibile .
Si avrà così accesso a un'intera sessione grafica, anche se con qualche limitazione di performance. Si noti infatti che il protocollo X11 trasmetterà tutto lo schermo, comprese le aree non necessarie perché non cambiate: non c'è una cache né alcun tipo di funzionalità "trasmetto solo cosa è cambiato".
Altri ottimi progetti sono il [http://www.ltsp.org Linux terminal Server project] che usa tutte le potenzialità 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.''


== Link ==
== Link ==
* [http://www.freesoftwaremagazine.com/articles/what_is_x/ What is X?]: ineretessante articolo che parte dalle basi del funzionamento fino agli utilizzi più avanzati del server X in remoto.
<!-- link commentato: * [http://www.freesoftwaremagazine.com/articles/what_is_x/ What is X?]: interessante articolo che parte dalle basi del funzionamento fino agli utilizzi più avanzati del server X in remoto; -->
* [http://www.tldp.org/HOWTO/XDMCP-HOWTO Linux XDMCP HOWTO]
* [http://www.tldp.org/HOWTO/XDMCP-HOWTO Linux XDMCP HOWTO]


[[Categoria:Xorg]]
{{Autori
|Autore = [[Utente:HAL 9000|HAL 9000]] 17:50, 8 set 2019 (CEST) <br/>(guida originariamente scritta da [[Utente:MaXeR|MaXeR]])
|Estesa_da =
|Verificata_da =
|Numero_revisori = 0
}}
 
[[Categoria:Xorg]][[Categoria:Altri servizi di rete]]

Versione attuale delle 15:50, 8 set 2019

Debian-swirl.png Versioni Compatibili

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

Introduzione

Nelle distribuzioni GNU/Linux e in generale nei sistemi UNIX e Unix-like l'interfaccia grafica (GUI) non è parte del kernel ma gestita da un programma a parte: l' X window system o semplicemente server X, di cui Xorg rappresenta l'implementazione attualmente più diffusa.

Le richieste dai client X di gestire le finestre avvengono di solito localmente, ma nulla impedisce di gestire le finestre attraverso la rete, permettendo a utenti remoti di effettuare il login sul display manager (xdm, gdm, kdm, lightdm, ecc...) per accedere al server X locale attraverso XDMCP (X Display Manager Control Protocol).

Per semplicità di configurazione, e per la stabilità dimostrata attraverso i passaggi di versione di Debian, in questa guida si considera unicamente xdm.

Warning.png ATTENZIONE
Ogni comunicazione da e verso il server X avverrebbe in chiaro, e sarebbe pertanto manipolabile e/o ascoltabile sulla rete. Questo rappresenta un enorme rischio per la sicurezza del sistema!

Se è possibile, si raccomanda caldamente invece di configurare una connessione SSH e di abilitare l'X11 forwarding per avviare un'applicazione grafica o anche un'intera sessione.


Lato server

Installazione

Con privilegi di amministrazione è necessario installare xdm, oltre ovviamente al server Xorg, se ancora non presente nella macchina che farà da server. Per esempio con apt basta: 

# apt install xdm xorg

Configurazione di xdm

Sempre con privilegi di amministrazione, è sufficiente modificare i file di configurazione indicati in questa sezione con un editor di testo, per esempio nano: 

# nano /etc/X11/xdm/xdm-config

In /etc/X11/xdm/xdm-config commenta: 

DisplayManager.requestPort:   0

che diventa: 

!DisplayManager.requestPort:   0

Salva il file (con nano premi Ctrl-o e per uscire Ctrl-x).

In modo analogo, apri il file /etc/X11/xdm/Xaccess e togli il comento a: 

#*         #any host can get a login window

che diventerà: 

  
*         #any host can get a login window

Al posto di * è possibile anche specificare, uno a uno, gli host da cui si intende accettare la connessione, anche con uso di pattern. Per esempio basta scrivere (al posto di *): 

192.168.0.*

per accettare connessioni dagli host appartenenti alla rete 192.168.0.0/24, ossia tutti gli indirizzi compresi da 192.168.0.1 a 192.168.0.254. Sono permessi anche hostname, per esempio se definiti in /etc/hosts, e l'uso di indirizzi multicast a cui limitare l'ascolto. Per maggiori informazioni si consultino gli esempi scritti nel file.

Per finire è necessario specificare di restare in ascolto sulla porta TCP, modificando il file /etc/X11/xdm/Xservers: 

:0 local /usr/bin/X :0 vt8 -nolisten tcp

che diventerà: 

:0 local /usr/bin/X :0 vt8

dove:

  • :0 è l'identificativo del server X che sarà avviato e dev'essere libero; se ce n'è già uno in esecuzione, utilizzarne un altro (:1, :2, ecc...);
  • vt8 è il terminale virtuale da utilizzare, in questo caso tty8 (accessibile con Ctrl-Alt-F8). Sceglierne uno qualsiasi libero (vt9, vt10, ecc...).

È possibile anche specificare più linee, se si intendono avviare più server X simultaneamente. In tal caso è consigliabile lasciare l'opzione -nolisten tcp su quelli per cui non è previsto l'accesso remoto, come misura di sicurezza.

Warning.png ATTENZIONE
Si ricorda nuovamente che, anche se l'accesso deve essere autenticato, la comunicazione non è criptata. Per cui chiunque nella rete potrebbe ascoltare le credenziali di accesso e il suo uso è altamente sconsigliato al di fuori della LAN, e anche in questo caso esclusivamente se tutti gli host e gli utenti connessi alla LAN possono sempre essere considerati fidati.


Per rendere effettive le modifiche, è necessario riavviare il display manager: 

# service xdm restart

e questo conclude la configurazione lato server. xdm resterà in ascolto sulla porta 177 del protocollo UDP per ricevere richieste di autenticazione, secondo il protocollo XDMCP, dagli host specificati nel file Xaccess. Il server Xorg resta invece in ascolto sulla porta 6000 del protocollo TCP e successive, in base al display utilizzato, e permetterà l'accesso soltanto previa autenticazione, di default in base alla conoscenza di una sequenza casuale generata in precedenza: il magic cookie (per maggiori informazioni si rimanda alla lettura del manuale di xauth), comunicato da xdm per permettere l'autenticazione.

Lato client

Installazione

È necessario il solo pacchetto xorg, per cui se non fosse installato, con privilegi di amministrazione: 

# apt install xorg

Utilizzo

Se l'indirizzo IP del server è 192.168.0.2, dal client sarà sufficiente il comando: 

# X -query 192.168.0.2 :0 vt8

per connettersi a xdm sulla macchina server. Si noti che il display e il terminale virtuale non devono combaciare per forza con quelli scelti sul server, l'unica cosa importante è che siano entrambi liberi sul client, in maniera analoga a quanto visto in precedenza per il server.

In alternativa, se si è nella stessa rete locale del server, è anche possibile: 

# X -broadcast :0 vt8

per mandare il messaggio di richiesta in broadcast (ossia a tutti gli host della rete), per effettuare la connessione al server X del primo host che risponde.

Si visualizzerà xdm in esecuzione sul server, che si potrà utilizzare per autenticarsi, utilizzando le credenziali di accesso di un utente che ha accesso alla macchina remota.

Si avrà così accesso a un'intera sessione grafica, anche se con qualche limitazione di performance. Si noti infatti che il protocollo X11 trasmetterà tutto lo schermo, comprese le aree non necessarie perché non cambiate: non c'è una cache né alcun tipo di funzionalità "trasmetto solo cosa è cambiato".

Link



Guida scritta da: HAL 9000 17:50, 8 set 2019 (CEST)
(guida originariamente scritta da MaXeR) 		Swirl-auth20.png Debianized 20%
Estesa da:
Verificata da:

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

Estratto da "https://guide.debianizzati.org/index.php?title=Manovrare_X_da_remoto&oldid=43187"