Product SiteDocumentation Site

9.2. Accesso remoto

È essenziale per un amministratore essere in grado di connettersi ad un computer remoto. I server, confinati nella propria stanza, sono raramente dotati di tastiere e monitor permanenti, ma sono connessi alla rete.

9.2.1. Accesso remoto sicuro: SSH

Il protocollo SSH (Secure SHell) è stato progettato tenendo a mente sicurezza ed affidabilità. Le connessioni con SSH sono sicure: il partner è autenticato e tutti gli scambi di dati sono cifrati.
SSH offre anche due servizi di trasferimento di file. scp è uno strumento a riga di comando che può essere utilizzato come cp, tranne che qualsiasi percorso a un altro computer è fatto precedere dal nome della macchina, seguito da due punti («:»).
$ file macchina scp:/tmp/
sftp è un comando interattivo, simile a ftp. In una singola sessione, sftp è in grado di trasferire più file, ed è possibile usarlo per manipolare i file remoti (eliminare, rinominare, modificare i permessi, ecc.).
Debian utilizza OpenSSH, una versione libera di SSH, mantenuta dal progetto OpenBSD (un sistema operativo libero basato sul kernel BSD, incentrato sulla sicurezza) e fork del software originale SSH sviluppato dalla società finlandese SSH Communications Security Corp. Questa società ha inizialmente sviluppato SSH come software libero, ma alla fine ha deciso di continuare il suo sviluppo sotto una licenza proprietaria. Il progetto OpenBSD quindi ha creato OpenSSH per mantenere una versione free di SSH.
OpenSSH è diviso in due pacchetti: la parte client è nel pacchetto openssh-client, mentre il server è nel pacchetto openssh-server. Il metapacchetto ssh dipende da entrambe le parti e facilita l'installazione di entrambi (apt install ssh).

9.2.1.1. Autenticazione basata su chiave

Ogni volta che qualcuno si collega tramite SSH il server remoto richiede una password per autenticare l'utente. Questo può essere problematico se si vuole automatizzare una connessione, o se si utilizza uno strumento che richiede collegamenti frequenti su SSH. È per questo che SSH offre un sistema di autenticazione basato su chiave.
L'utente genera una coppia di chiavi sulla macchina client con ssh-keygen -t rsa; la chiave pubblica è conservata in ~/.ssh/id_rsa.pub, mentre la corrispondente chiave privata è conservata in ~/.ssh/id_rsa. Successivamente l'utente usa ssh-copy-id server per aggiungere la propria chiave pubblica nel file ~/.ssh/authorized_keys presente sul server. Se la chiave privata non è stata protetta con una «passphrase» al momento della sua creazione, tutti gli accessi successivi sul server funzioneranno senza una password. In caso contrario, la chiave privata dovrà essere decifrata ogni volta inserendo la «passphrase». Fortunatamente, ssh-agent ci permette di mantenere in memoria le chiavi private in modo da non dover reinserire continuamente la password. Per questo, è sufficiente utilizzare ssh-add (una volta per ogni sessione di lavoro), a condizione che la sessione sia già associata ad un'istanza funzionante di ssh-agent. Debian la attiva come impostazione predefinita nelle sessioni grafiche, ma è possibile disattivare questo comportamento cambiando /etc/X11/Xsession.options. Per una sessione della console, è possibile avviarla manualmente tramite eval $(ssh-agent).

9.2.1.2. Utilizzo di applicazioni X11 remote

Il protocollo SSH consente la trasmissione dei dati grafici (sessione «X11», dal nome del più diffuso sistema grafico in Unix), il server mantiene un canale dedicato per tali dati. In particolare, un programma grafico eseguito da remoto può essere visualizzato sul server X.org dello schermo locale e l'intera sessione (ingresso e visualizzazione) sarà sicura. Poiché questa funzionalità consente alle applicazioni remote di interferire con il sistema locale, è disabilitata in modo predefinito. È possibile abilitare questa funzionalità specificando X11Forwarding yes nel file di configurazione del server (/etc/ssh/sshd_config). Infine, l'utente deve anche richiederla aggiungendo l'opzione -X alla riga di comando di ssh.

9.2.1.3. Creazione di tunnel cifrati con il port forwarding

Le opzioni -R e -L consentono a ssh di creare «tunnel cifrati» tra due macchine, inoltrando in modo sicuro una porta TCP locale (vedere il riquadro FONDAMENTALI TCP/UDP) ad un computer remoto o viceversa.
ssh -L 8000:server:25 intermediario stabilisce una sessione SSH con l'host intermediario e ascolta sulla porta locale 8000 (vedere Figura 9.3, «Inoltro di una porta locale con SSH»). Per ogni connessione stabilita su questa porta, ssh avvierà una connessione dal computer intermediario alla porta 25 sul server legando insieme entrambe le connessioni.
Anche ssh -R 8000:server:25 intermediario stabilisce una sessione SSH al computer intermediario, ma è in questa macchina che ssh è in ascolto sulla porta 8000 (vedere Figura 9.4, «Inoltro di una porta remota con SSH»). Ogni connessione stabilita sulla porta farà sì che ssh aprirà una connessione dalla macchina locale alla porta 25 del server legando insieme entrambe le connessioni.
In entrambi i casi, le connessioni sono realizzate sulla porta 25 dell'host server, e passano attraverso il tunnel SSH stabilito tra la macchina locale e la macchina intermediario. Nel primo caso, l'ingresso del tunnel è locale sulla porta 8000, ed i dati si muovono verso la macchina intermediario prima di essere diretti al server sulla rete «pubblica». Nel secondo caso, l'ingresso e l'uscita del tunnel sono invertiti, l'ingresso è la porta 8000 sulla macchina intermediario, l'uscita è sulla macchina locale, ed i dati vengono poi indirizzati al server. In pratica, il server è di solito o la macchina locale o l'intermediario. In questo modo SSH rende sicura la connessione da un'estremità all'altra.
Inoltro di una porta locale con SSH

Figura 9.3. Inoltro di una porta locale con SSH

Inoltro di una porta remota con SSH

Figura 9.4. Inoltro di una porta remota con SSH

9.2.2. Utilizzo di desktop remoti grafici

VNC (Virtual Network Computing) permette l'accesso remoto a desktop grafici.
Questo strumento è usato soprattutto per l'assistenza tecnica; l'amministratore può visualizzare gli errori che l'utente si trova ad affrontare, e mostrargli la cosa corretta da fare, senza dover essere fisicamente presente.
In primo luogo, l'utente deve autorizzare la condivisione della sessione. L'ambiente desktop grafico GNOME in Jessie include questa opzione nel suo pannello di configurazione (contrariamente alle precedenti versioni di Debian, nelle quali l'utente deve installare ed utilizzare vino). KDE richiede ancora l'uso di krfb per consentire la condivisione di una sessione esistente tramite VNC. Per gli altri ambienti desktop grafici, il comando x11vnc (dal pacchetto Debian con lo stesso nome) serve allo stesso scopo; è possibile renderlo disponibile per l'utente con un'icona esplicita.
Quando la sessione grafica è messa a disposizione da VNC, l'amministratore deve connettersi con un client VNC. GNOME ha vinagre e remmina per questo scopo, mentre KDE include krdc (nel menu KInternetClient per connessione a desktop remoto). Ci sono altri client VNC che utilizzano la riga di comando, come ad esempio xvnc4viewer nel pacchetto Debian con lo stesso nome. Una volta connesso, l'amministratore può vedere cosa sta succedendo, lavorare sulla macchina in remoto, e mostrare all'utente come procedere.
VNC funziona anche per utenti mobili, o dirigenti di società, che a volte hanno bisogno di effettuare il login da casa per accedere a un desktop remoto simile a quello che utilizzano sul posto di lavoro. La configurazione di tale servizio è più complicata: per prima cosa si installa il pacchetto vnc4server, si modifica la configurazione del display manager in modo da accettare richieste XDMCP query (per gdm3, ciò può essere fatto aggiungendo Enable=true nella sezione «xdmcp» di /etc/gdm3/daemon.conf) e infine si avvia il server VNC con inetd in modo che una sessione venga avviata automaticamente quando un utente tenta di effettuare l'accesso. Ad esempio, si può aggiungere questa riga a /etc/inetd.conf:
5950  stream  tcp  nowait  nobody.tty  /usr/bin/Xvnc Xvnc -inetd -query localhost -once -geometry 1024x768 -depth 16 securitytypes=none
Deviare le connessioni in entrata al display manager risolve il problema dell'autenticazione, in quanto solo gli utenti con account locali supereranno la schermata di accesso di gdm3 (o l'equivalente di kdm, xdm, ecc.). Poiché questo sistema consente più connessioni simultanee senza alcun problema (se il server è abbastanza potente), può anche essere utilizzato per fornire desktop completi per gli utenti mobili (o per sistemi desktop meno potenti, configurati come thin client). Gli utenti devono semplicemente accedere allo schermo del server con vncviewer server:50, perché la porta utilizzata è 5950.