Nell’immagine precedente, abbiamo voluto illustrare lo schema di rete al quale ci riferiremo, da ora in avanti. Per collegarsi al server nella rete interna sull’indirizzo interno 192.168.1.15,  passando dal bastion host  fw.notjustacloud.com raggiungibile da Internet, si dovrà utilizzare il comando:

ssh -J user1@fw.notjustacloud.com user2@192.168.1.15

e autenticatisi prima su fw.notjustacloud.com che fa da bastion host con user1 e poi sul server finale con  user2, si otterrà l’accesso al terminale sul server.

E’ importante non dimenticare mai che non è necessario usare l’indirizzo per il server di destinazione finale, si può anche utilizzare un nome a dominio, o un qualunque altro nome che sia risolubile dal bastion host; la connessione verso la destinazione finale (nell’esempio user2@192.168.1.15) infatti viene sempre eseguita a partire dal bastion host.

Nel momento in cui lo scopo sarà quello di fornire un accesso ristretto ad un utente esterno verso un server interno specifico, l’idea di fornire un accesso utente ordinario sul bastion host può apparire, correttamente, come una scelta non appropriata dal punto di vista della sicurezza. In più, con questo meccanismo, chi si collegherà dovrà anche autenticarsi due volte, e dare una password, possibilmente anche diversa, per ben due volte, una modalità di accesso tutt’altro che comoda. 

Per fortuna la possibilità di utilizzare l’autenticazione a chiavi di SSH, di cui abbiamo già parlato qui, e le funzionalità di controllo ad esse associate, ci consentono sia di semplificare notevolmente le operazioni lato client, che di rendere al contempo l’accesso sicuro.

Ecco perchè il primo passo sarà quello di creare, sul bastion host, un utente da utilizzare solo per il servizio di proxy, privandolo di qualunque altra capacità. Nel nostro caso sceglieremo di usare un utente sshproxy, da impostare come utente di sistema, senza password e senza possibilità di accesso alla macchina, con il seguente comando:

useradd -s /usr/bin/nologin -m -r proxyssh

Per dare l’accesso agli utenti esterni,  devono poi essere create una coppia di chiavi senza passphrase. Questa operazione potrà essere effettuata su qualsiasi macchina, per l’accesso sarà sufficiente inserire la chiave pubblica nel file .ssh/authorized_keys dell’utente proxyssh sul bastion host e distribuire la coppia di chiavi a chi si vorrà fare usare il servizio. Per semplicità creeremo la coppia di chiavi direttamente sul bastion host nella home dell’utente proxyssh, per farlo e predisporre l’accesso, si dovranno usare i seguenti comandi:

root@fw:~# su -s /bin/bash - proxyssh 
proxyssh@fw:~$ ssh-keygen 
Generating public/private rsa key pair.
Enter file in which to save the key (/home/proxyssh/.ssh/id_rsa): 
Created directory '/home/proxyssh/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/proxyssh/.ssh/id_rsa.
Your public key has been saved in /home/proxyssh/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:Ex/uuTVd0OhyYX235aubl7QN7Lef9fZJ+16oxw7pWOM proxyssh@bookworm
The key's randomart image is:
+---[RSA 3072]----+
|                 |
|               + |
|        . .   = *|
|         + . o +=|
|        S o ..o.o|
|         o . =o+.|
|          o Bo++*|
|           B =B+@|
|          o E*+O@|
+----[SHA256]-----+
proxyssh@fw:~$ cat .ssh/id_rsa.pub >> .ssh/authorized_keys
proxyssh@fw:~$ chmod 600 .ssh/authorized_keys

Gli utenti a cui abbiamo fornito la coppia di chiavi, a questo punto, potranno usarla per autenticarsi sul bastion host, nonostante non possano collegarsi allo stesso, in quanto l’utente non ha una shell. 

Questa operazione comunque non è sufficiente, occorrerà anche bloccare  tutte le funzionalità di SSH lasciando solo quelle necessarie all’utilizzo della connessione per ill “Proxy Jump“, cosa che si può fare in due modi diversi:

Il primo consiste nel rimuovere completamente le capacità aggiuntive dell’utente, ricorrendo all’uso della direttiva Match nella configurazione del server in /etc/ssh/sshd_config. Questa direttiva, come dice il nome stesso, consente di applicare configurazioni specifiche a tutte le connessioni che corrispondono ad un criterio di scelta indicato come parametro, che sia indicato con parola chiave per specificare cosa filtrare, come User, Group, Address, ecc. Nel nostro caso filtreremo in base all’utente, per restringere al massimo le capacità di sshproxy, pertanto occorrerà aggiungere in coda a /etc/ssh/sshd_config le seguenti direttive:

Match User proxyssh
     AllowAgentForwarding no
     AllowTcpForwarding yes
     X11Forwarding no
     PermitTunnel no
     GatewayPorts no
     PasswordAuthentication no

E’ fondamentale considerare che si è specificato “in coda”: questo è essenziale, in quanto la direttiva Match si applica a tutte le righe successive e supporta l’indicazione soltanto di un sottoinsieme delle direttive di sshd_config. Dunque se la si inserisce in mezzo al file tutto quello che segue verrà applicato all’utente proxyssh; infine se nelle righe successive si è utilizzata una delle direttive non consentite da Match si otterrà una configurazione non valida ed al riavvio il servizio non partirà.

E’ possibile rimuovere l’applicazione di eventuali direttive successive all’utente proxyssh, facendo seguire una ulteriore direttiva Match all al precedente estratto, che riporterà l’applicazione del resto delle direttive a tutte le connessioni, ma questa soluzione non risolve il problema di un eventuale uso nel resto del file di una direttiva non consentita da Match. Infatti aggiungere in coda l’estratto precedente, evita questi problemi alla radice. Prima di riavviare il servizio comunque si verifichi sempre che la nuova configurazione sia corretta con il comando sshd -T.

Il secondo metodo è molto più flessibile e consente anche di variare le restrizioni a seconda di chi si collega, senza dover toccare la configurazione del server; questo meteodo però richiede più lavoro. Anche in questo caso si utilizzerà una delle funzionalità avanzate di SSH: che permette di restringe l’ambito di applicazione di una chiave, inserendo all’inizio della riga in cui è elencata dentro .ssh/authorized_keys, prima dell’indicazione del tipo di chiave, le opportune restrizioni. In buona sostanza si tratterà di modificare /home/proxyssh/.ssh/authorized_keys inserendo in testa alla chiave autorizzata qualcosa come:

restrict,port-forwarding ssh-rsa AAAAB3NzaC1y ... TMPzwWwys4GE0= proxyssh@fw

che blocca tutte le capacità di accesso tranne quella del reinoltro delle connessioni che è necessaria per il “Proxy Jump“.

Attravsrso questa configurazione, un utente esterno si potrà collegare ad una macchina sulla rete interna passando dal  bastion host usato come proxy, ma per farlo sarà necessario di reconfigurare il proprio client cosi da poter utilizzare la coppia di chiavi che abbiamo creato allo scopo. Pertanto assumeremo di aver copiato queste chiavi sul client come rsa_proxy_id e rsa_proxy_id.pub e di averle messe nella directory .ssh della propria home directory. Per effettuare il collegamento si potrebbe pensare di usare  un comando come:

ssh -J sshproxy@fw.notjustacloud.com -i .ssh/rsa_proxy_id  user2@192.168.1.15

ma questo non funziona in quanto l’opzione -i si applicherebbe al collegamento verso 192.168.1.15 ottenendo una richiesta della password per  proxyssh nell’accesso al bastion host.

Considerando che non esiste un’opzione di ssh per indicare la chiave da utilizzare per il bastion host, e usare -J comporterebbe comunque di dover scrivere un comando più lungo, è possibile inserire i parametri per la connessione nella configurazione client di SSH usando il file .ssh/config della propria home, ottenendo in questo modo, che sia valida oltre che per ssh, anche per scp e tutti gli altri comandi che usano il servizio.

All’interno di questo file potremo indicare sia come collegarsi alla macchina fw.notjustacloud.com usando le chiavi distribuite per l’accesso, sia l’uso della stessa macchina come proxy per le connessioni verso il server su  192.168.1.15; questo lo si può ottenere aggiungendo le righe seguenti:

Host fw.notjustacloud.com
    User proxyssh
    IdentityFile ~/.ssh/rsa_proxy_id 

Host 192.168.1.15 intserver othername
    Hostname 192.168.1.15
    ProxyJump proxyssh@fw.notjustacloud.com

ottenendo di potersi collegare usando semplicemente il comando:

ssh user2@192.168.1.15

oppure, usando uno degli alias aggiunti alla configurazione, con il comando:

ssh user2@intserver

Scegliere di distribuire una coppia di chiavi dedicate presenta il vantaggio che non si ha bisogno di nessuna modifica alla configurazione di SSH sul bastion host e che sullo stesso, si dovrà configurare l’accesso in /home/proxyssh/.ssh/authorized_keys una sola volta, distribuendo poi i file delle chiavi agli utenti ai quali si vorrà dare accesso.

Tale scelta però prtesenta lo svantaggio di non poter bloccare l’utilizzo del proxy ad uno degli utenti a cui si è distribuita la coppia di chiavi, a meno di non cambiarla per tutti.

Ecco perchè, anche se tutto ciò comporta un maggior lavoro di configurazione sul bastion host, è più sicuro e flessibile farsi inviare la propria chiave pubblica SSH da ogni utente esterno, così da inserirla in /home/proxyssh/.ssh/authorized_keys, sempre con una configurazione analoga alla precedente:

restrict,port-forwarding ssh-rsa AAAAB3NzaC ... G0F3ICPaOXw== esternal@place.com

in modo che ogni utente acceda con la propria chiave.

A questo punto avremo una configurazione che permette di revocare l’accesso ad un singolo utente semplicemente cancellando da /home/proxyssh/.ssh/authorized_keys  la riga con la sua chiave e non sarà più necessaria la generazione di una coppia di chiavi da distribuire. Si faccia attenzione anche che se compieremo questa scelta, la chiave pubblica che corrisponde all’identità di default dell’utente che accede, potrà essere utilizzata anche sul server di destinazione, e si potrà ridurre le configurazione che egli dovrà fare sul proprio client a:

Host 192.168.1.15 intserver othername
    Hostname 192.168.1.15
    ProxyJump proxyssh@fw.notjustacloud.com

ottenendo l’accesso esterno desiderato senza necessità di dover distribuire una password utente, rendendo in questo modo più semplice e sicuro l’accesso (una modalità di configurazione degli accessi sul server della rete interna che è comunque consigliabile anche se si fosse adottata la strategia precedente di una chiave comune per proxyssh).

Speriamo che questo tutorial vi sia utile per i vostri bisogni, in ogni caso, per qualsiasi aggiornamento o chiarimento, non esitate a contattarci tramite mail a info@notjustacloud.com o sulla sezione contatti del nostro sito.

                                                                                             La redazione