Oggi più che mai abbiamo bisogno di accedere in remoto ad altri computer, per fornire assistenza, per scopi didattici, per esigenze lavorative di smart working ma anche per accedere a dispositivi presenti nelle reti di casa. Ma giustamente l’accesso ai computer all’interno delle reti locali casalinghe è protetto dalle caratteristiche dei router e modem che i provider forniscono. Quindi in configurazioni standard non è possibile, o almeno semplice, concedere l’accesso ai nostri computer anche se questo è a nostro beneficio. Esistono diverse soluzioni anche commerciali per permettere assistenza remota, qui ne vediamo una completamente open source e di cui abbiamo il completo controllo.
Oltre al computer dell’utente a cui vogliamo accedere (“U”), abbiamo il computer che offre assistenza da cui accediamo (“A”) e l’elemento chiave un server internet di cui disponiamo accessi ssh. Oggi si hanno a disposizione server virtuali nel cloud a costi molto ridotti.
Il sistema operativo usato per entrambi i computer “utente” e “assistenza” è stato Linux Mint 19.3, ma dovremmo poter usare altre distribuzioni di Linux senza grosse modifiche.
Installazione del server VNC
Esistono diverso server VNC, qui proponiamo x11vnc. L’ howto su linuxmint.com [1] spiega correttamente le operazioni per installare il server x11vnc, ma vediamo alcuni passi da fare dopo l’installazione del pacchetto:
sudo x11vnc --storepasswd /etc/x11vnc/vncpwdPermette di creare una password per accedere da remoto e la memorizza nel file vncpwd. Attenzione: usando il comando sudo il file che viene creato sarà di proprietà root e sarà accessibile solo ai servizi eseguiti al boot.
Il servizio di sistema che andiamo a definire si chiamerà x11vnc.service ed è definito nel file /lib/systemd/system/x11vnc.service. Il parametro ExecStart nella sezione Service definisce il comando che verrà eseguito al lancio del servizio:
ExecStart=/usr/bin/x11vnc -auth guess -forever -noxdamage -repeat -rfbauth /etc/x11vnc/vncpwd -rfbport 5900 -shared
Possiamo riconoscere il file dove leggere la password di accesso (vncpwd) e la porta TCP/IP per accedere al servizio (5900).
Attivato il servizio possiamo accedere con un client per effettuare un test magari da un computer sulla stessa rete locale, ad esempio remmina [3]:
Attenzione: l’uso della profondità colore di default (8 bpp) può mandare in crash il programma, probabilmente per una modalità non supportata dal server. L’aspetto qualitativo sarebbe comunque scarso. Usare valori di 24 bpp o 32 bpp.
Creazione dei canali di comunicazione
Il sistema di comunicazione completo userà tre elementi:
- Un server esterno con accesso ssh che faccia da ponte
- Un tunnel ssh tra il computer dell’assistenza (“A”) ed il server
- Un tunnel ssh tra il computer dell’utente che chiede assistenza (“U”) ed il server
Nei prossimi passi si assume che il pacchetto openssh sia installato e configurato su tutti i computer e che sia possibile accedere con una utenza “user1” e “assistenza1” al server, ad esempio con:
ssh user1@linux.livorno.it
E’ consigliato usare identità e chiavi pubbliche e private ed evitare accessi ssh con password.
Tunnel dal computer dell’assistenza “A”
Per default il client vnc in esecuzione sul computer dell’assistenza “A” vuole connettersi alla porta 5900 del vnc server. Impostiamo quindi un redirect della porta 5900 dal computer locale (localhost) ad una porta di servizio (i.e. 21000) sul server esterno “linux.livorno.it”:
ssh -L 5900:localhost:21000 assistenza1@linux.livorno.it
L’opzione “-L” indica a SSH di creare un tunnel che accetta connessioni sulla macchina locale dove è stato dato il comando.
Una volta dato il comando ci troveremo collegati ad una shell sul computer remoto. Abbiamo l’occasione per testare il tunnel con il comando:
nc -l -p 21000
Il comando nc (netcat) crea una porta in ascolto (-l) sulla porta (-p) 21000 e rimane in attesa di dati che verranno mostrati sullo schermo.
Sul computer “A” apriamo un’altra shell e diamo il comando:
telnet localhost 5900
e scriviamo alcune righe: il testo apparirà sulla server remoto. Il telnet scrive sulla porta 5900 della propria macchina (localhost, computer “A”), ma il tunnel SSH redireziona tutto il traffico da quella porta verso la porta 21000 del server remoto.
Verificato il funzionamento possiamo uscire dalla shell remota e dare il comando finale con l’opzione “-f” per mandare il comando in background:
ssh -f -N -T -L 5900:localhost:21000 assistenza1@linux.livorno.it
Tunnel dal computer utente “U”
Qui vogliamo che tutto il traffico proveniente dal server remoto (porta 21000) venga trasferito sulla porta locale 5900 del computer “U”
ssh -R 21000:localhost:5900 user1@linux.livorno.it
L’opzione “-R” indica che il tunnel ssh dovrà accettare connessioni sulla parte remota del tunnel.
Qui faremo il test analogo: su una shell del computer “U” daremo il comando:
nc -l -p 5900
Mentre sul server remoto daremo il comando:
telnet localhost 21000
Tutto ciò che scriveremo sul server remoto apparirà sul computer utente.
Il comando finale per stabilire la connessione sarà:
ssh -N -T -R 21000:localhost:5900 user1@linux.livorno.it
Configurazione del server ponte
Il lavoro di comunicazione verrà svolto dal daemon sshd, opportunamente configurato per gestire comunicazioni protette:
/etc/ssh/sshd_config:
AllowTcpForwarding remote
AllowStreamLocalForwarding
Il servizio dovrà essere riavviato con
service sshd.service restart
Sessione di assistenza
Il tunnel sul computer utente può essere creato all’avvio del computer rendendo il computer accessibile in qualunque momento. Ma può essere creato solo al momento del bisogno con un semplice script.
Attivato il server VNC (x11vnc) ed il tunnel sul computer “U”, rimane da lanciare un client VNC sul server assistenza. Qui occorre ricordare che l’host per la connessione deve essere “localhost” e non l’indirizzo del computer remoto.
Esistono numerosi client VNC, segnaliamo remmina, un client che permette anche connessioni a più computer contemporaneamente, gestibili tramite semplici tab.
Ulteriori possibilità
Il sistema di tunnelling descritto usa la porta standard del VNC 5900, ma si possono usare altre porte per supportare altre applicazioni client/server ad esempio desktop remoti che usano il protocollo RDP 3389.
Il sistema illustrato può essere esteso per supportare più richieste contemporanee di supporto da parte di più utenti. Ogni utente o dispositivo remoto può avere una porta sul server dedicata: 21000, 21001, 21002, etc… Rispettivamente il client di assistenza potrà configurare più tunnel ssh, eventualmente usando anche diverse porte locali (es: 5900, 5901, etc…) per accedere contemporaneamente a più macchine remote.
Nota di sicurezza
Una volta ottenuto l’accesso al server ponte, il tunnel ssh renderà accessibile macchine all’esterno di un’azienda: è necessario concordare la funzione con gli amministratori di sistema. Per una migliore sicurezza è consigliabile usare solo chiavi pubbliche/private per accedere al server ponte ed impiegare password complesse per proteggere l’accesso al server VNC.
Riferimenti
[1] https://community.linuxmint.com/tutorial/view/2334
[2] https://linux.die.net/man/1/x11vnc
[3] https://remmina.org/