È 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 is an interactive command, similar to ftp. In a single session, sftp can transfer several files, and it is possible to manipulate remote files with it (delete, rename, change permissions, etc.). Many FTP clients, including filezilla, support it.
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. Combining authentication methods
Besides the already mentioned password based, key based, and the certificate based authentication, other methods like using a TOTP exist as well. Not only is this an abundance of options. They can also be combined. On the server side, the AuthenticationMethods directive can define an order of authentication methods a user has to successfully pass, before they are allowed to enter the system. It is even possible to define multiple alternative sequences:
AuthenticationMethods publickey,password publickey,keyboard-interactive:pam
This setting, for example, allows users to login after initially completing the public key authentication, followed by either a successful password authentication or entering a valid TOTP set up via PAM. On the user side, the sequence of methods can be defined using the PreferredAuthentications directive.
9.2.1.4. Utilizzo di applicazioni X11 remote
The SSH protocol allows forwarding of graphical data (“X11” session, from the name of the most widespread graphical system in Unix); the server then keeps a dedicated channel for those data. Specifically, a graphical program executed remotely can be displayed on the X.org server of the local screen, and the whole session (input and display) will be secure. Since this feature allows remote applications to interfere with the local system, it is disabled by default. You can enable it by specifying X11Forwarding yes in the server configuration file sshd_config(5) or by prepending the public key with the X11-forwarding keyword in the authorized_keys(5) file. Finally, the user must also request it by adding the -X option to the ssh command-line.
9.2.1.5. 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.
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 → (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 → → ). 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.
