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), mentre il pacchetto task-ssh-server, spesso scelto durante prima installazione del sistema, dipende soltanto dal pacchetto contenente il server.

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.
Si può generare una coppia di chiavi sulla macchina client usando ssh-keygen -t rsa; la chiave pubblica così generata è salvata in ~/.ssh/id_rsa.pub, mentre la corrispondente chiave privata è salvata in ~/.ssh/id_rsa. Si può poi utilizzare ssh-copy-id server per aggiungere le sue chiavi pubbliche al file ~/.ssh/authorized_keys presente sul server, o, se l'accesso SSH non è ancora stato abilitato, si deve chiedere all'amministratore di aggiungerle manualmente.
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 e commentando use-ssh-agent. Per una sessione della console, è possibile avviare l'agent manualmente tramite eval $(ssh-agent).

9.2.1.2. Autenticazione basata su certificato

Le chiavi SSH non possono essere protette soltanto con una password (o senza). Una caratteristica spesso sconosciuta è che è possibile firmarle tramite un certificato, sia la chiave dell'host che quella del client. Questo approccio presenta diversi vantaggi. Al posto di mantenere un file authorized_keys per utente, come descritto nella sezione precedente, il server SSH può essere configurato per dare fiducia a tutte le chiavi dei client firmate dallo stesso certificato (vedere anche Sezione 10.2.2, «Infrastruttura a chiave pubblica: easy-rsa») usando le direttive TrustedUserCAKeys e HostCertificate presenti in /etc/ssh/sshd_config.
TrustedUserCAKeys /etc/ssh/ssh_users_ca.pub

HostKey /etc/ssh/ssh_host_ecdsa_key
HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub
Viceversa i client possono essere anche configurati per fidarsi delle chiavi degli host firmate dalla stessa autorità, rendendo più semplice il mantenimento del file known_hosts (anche a livello di sistema tramite /etc/ssh/known_hosts).
@cert-authority *.falcot.com ssh-rsa AAAA[..]
Le autenticazioni con chiave pubblica e con certificato possono essere usate contemporaneamente.

9.2.1.3. 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.4. 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 FONDAMENTALE 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 include questa opzione tramite ImpostazioniCondivisioni (contrariamente alle precedenti versioni di Debian dove si doveva installare ed eseguire vino). Per far sì che questo funzioni occorre che network-manager stia gestendo la rete utilizzata (ad esempio abilitare la modalità managed (gestita) per dispositivi gestiti da ifupdown in /etc/NetworkManager/NetworkManager.conf). KDE Plasma 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 o i comandi tightvncserver (dal pacchetto Debian con lo stesso nome) o tigervncserver (tigervnc-standalone-server) servono per lo stesso scopo e forniscono il pacchetto virtuale vnc-server; è possibile renderli entrambi disponibili per l'utente con un elemento esplicito del menu o del desktop.
Quando la sessione grafica è messa a disposizione da VNC, l'amministratore deve connettersi con un client VNC. GNOME fornisce 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 xtightvncviewer nel pacchetto omonimo o xtigervncviewer dal pacchetto tigervnc-viewer. Una volta connesso, l'amministratore può vedere cosa sta succedendo, lavorare sulla macchina in remoto e mostrare all'utente come procedere.