Accesso SSH a reti interne tramite bastion host (in maniera sicura)¶

Esistono diversi casi in cui può essere necessario fornire a singoli utenti esterni un accesso con SSH su specifiche macchine presenti nella propria rete interna, senza però dare un accesso generico alla stessa con una VPN. In sostanza si vuole poter consentire ad un utente esterno solo un collegamento SSH verso una specifica macchina interna.

Per ottenere questo risultato si può sfruttare un firewall (o in generale un bastion host che si affacci su detta rete) che sia raggiungibile con SSH, appoggiandosi ad una delle funzionalità avanzate di questo servizio, il cosiddetto "Proxy Jump", che è stato introdotto con OpenSSH 7.3 (rilasciata nell'agosto 2016) e è ormai disponibile su tutte le versioni presenti in una qualunque distribuzione recente.

Questa funzionalità prevede che si possa, passando attraverso una macchina a cui si ha accesso SSH, avere un reinoltro in maniera trasparente della connessione SSH verso un'altra macchina da questa raggiungibile. Si tratta in sostanza di usare l'SSH presente sul bastion host come proxy del protocollo.

La funzionalità di proxy deve essere richiesta dal client che esegue la connessione, usando l'opzione l'opzione -J del comando per indicare la macchina da usare come proxy. Può essere inoltre essere indicata nella propria configurazione client (quella mantenuta nel file .ssh/config nella propria home directory) con la direttiva ProxyJump.

Nel prosieguo faremo riferimento allo schema di rete illustrato nella figura precedente; per collegarsi alla macchina server sull'indirizzo interno @192.168.42.105, si dovrà utilizzare un comando simile:

ssh -J utente_a@bastion.truelite.it utente_b@192.168.42.105

e una volta autenticatisi prima sul bastion host che fa da proxy con utente_a e poi sul server finale con utente_b, si otterrà l'accesso al server interno.

Ovviamente se lo scopo è quello di fornire accesso ad una macchina interna ad un utente esterno, fornire un accesso utente ordinario sul bastion host è una scelta abbastanza indesiderata sul piano della sicurezza.

Inoltre chi si collega in questo modo deve anche autenticarsi due volte, e dare due volte una password, possibilmente anche diversa, cosa che non è particolarmente comoda. Fortunatamente l'autenticazione a chiavi di SSH ci viene incontro, e permette di semplificare notevolmente le operazioni lato client, rendendo al contempo l'accesso molto più sicuro.

Il primo passo è quello di creare sul bastion host un utente dedicato al servizio di proxy, privandolo di qualunque altra capacità. Nel nostro caso sceglieremo di usare un utente sshproxy, che creeremo come utente di sistema, senza password e senza possibilità di accesso, con qualcosa del tipo:

useradd -r sshproxy -s /sbin/false

Per fornire ad un esterno l'accesso questo utente creeremo una coppia di chiavi senza passphrase. Questo può essere fatto su qualunque macchina, basterà poi inserire la chiave pubblica nel file .ssh/authorized_keys dell'utente sshproxy sul bastion host e distribuire la coppia di chiavi a tutte le persone a cui si vuole fare usare il servizio. Per semplicità creeremo la coppia di chiavi direttamente nella home dell'utente sshproxy, predisponendo l'accesso, con i seguenti comandi:

root@bastion:~# su - sshproxy -s /bin/bash
sshproxy@bastion:~$ ssh-keygen 
Generating public/private rsa key pair.
Enter file in which to save the key (/home/sshproxy/.ssh/id_rsa): 
Created directory '/home/sshproxy/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/sshproxy/.ssh/id_rsa.
Your public key has been saved in /home/sshproxy/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:6kwKCutHHWIP6R/TVaQgHN+uL7PuOhYdTQTvs7jCjEY sshproxy@bastion
The key's randomart image is:
+---[RSA 2048]----+
|    .o.oo...     |
|     .o +...     |
|    .  .o+.      |
|   = . .oo       |
|  o = + S+       |
|   E * +o o      |
|. + = *o .       |
|.o = % oo        |
|+.o o.O=+.       |
+----[SHA256]-----+
sshproxy@bastion:~$ cp  .ssh/id_rsa.pub .ssh/authorized_keys
sshproxy@bastion:~$ chmod 600 .ssh/authorized_keys

In questo modo chiunque abbia a disposizione la coppia di chiavi potrà usarla per autenticarsi sul bastion host, pur non potendosi collegare allo stesso. Per migliorare la sicurezza sarà comunque opportuno bloccare anche tutte le funzionalità di SSH non necessarie all'utilizzo della connessione ad uso di proxy, cosa che si può fare in due modi diversi.

Il primo metodo è più radicale, e rimuove le capacità aggiuntive in maniera completa per l'utente ricorrendo all'uso della direttiva Match in /etc/ssh/sshd_config per bloccare le stesse. La direttiva consente di applicare configurazioni specifiche a tutte le connessioni che corrispondono al criterio indicato come parametro, questo prevede che si utilizzi una prima parola chiave per specificare cosa filtrare, come User, Group, Address, ecc. Nel nostro caso filtreremo per utente, restringendo al massimo le capacità di sshproxy, pertanto occorrerà aggiungere in coda a /etc/ssh/sshd_config le seguenti direttive:

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

si noti che si è detto in coda: la direttiva Match infatti si applica a tutto quello che segue, e supporta l'indicazione di soltanto un sottoinsieme delle direttive di sshd_config, pertanto se la si inserisce in mezzo al file tutto quello che segue verrà applicato all'utente sshproxy, e se nel seguito si è usata una delle direttive non consentite da Match si avrà una configurazione non valida ed il servizio non ripartirà. Si può chiudere la applicazione specifica facendo seguire il precedente estratto da una direttiva Match all che però non risolve il problema dell'uso di direttive non consentite. Si verifichi sempre che la configurazione aggiuntiva è valida, usando sshd -T.

Il secondo metodo è più flessibile e consente almeno teoricamente di variare le restrizioni a secondo di chi si collega senza modificare la condfigurazione del server. Di nuovo si usa una delle funzionalità avanzate del servizio, che consente di restringe l'ambito di applicazione di una chiave, inserendo in testa alla riga in cui è elencata dentro .ssh/authorized_keys le opportune restrizioni prima dell'indicazione del tipo di chiave. In sostanza nel caso precedente si tratterà si modificare /home/sshproxy/.ssh/authorized_keys inserendo in testa alla chiave autorizzata qualcosa come:

restrict,port-forwarding ssh-rsa AAAAB3NzaC ... 9bgOvM/DkF sshproxy@bastion

Una volta fatta questa configurazione sul bastion host ci si potrà collegare ad una macchina usandolo come proxy, ma per farlo è necessario dire al client di usare la coppia di chiavi che abbiamo creato allo scopo, che assumeremo di aver copiato come proxy_rsa_id e proxy_rsa_id.pub nella directory .ssh della propria home directory. Si potrebbe pensare di farlo con un comando come:

ssh -J sshproxy@bastion.truelite.it -i .ssh/proxy_rsa_id  utente@192.168.42.105

ma in questo caso l'opzione -i si applica al collegamento verso 192.168.42.105 e si otterrà una richiesta della password per sshproxy.

Dato che non esiste una opzione a riga di comando per indicare la chiave da usare per il proxy, e che comunque usare l'opzione -J comporta comunque di scrivere di più, è opportuno inserire i parametri per la connessione dentro la propria configurazione client di SSH (così che sia valida non solo per ssh, ma anche per scp e tutti gli altri comandi che usano il servizio) nel file .ssh/config della propria home.

In questo file si potrà sia indicare come collegarsi alla macchina bastion.truelite.it con le chiavi aggiuntive, sia l'uso della stessa come proxy per le connessioni verso la macchina 192.168.42.105, aggiungendo le righe:

Host bastion.truelite.it
    User sshproxy
    IdentityFile ~/.ssh/proxy_rsa_id 

Host 192.168.42.105 testserver othername
    Hostname 192.168.42.105
    ProxyJump sshproxy@bastion.truelite.it

ottenendo di potersi collegare semplicemente con:

ssh utente@192.168.42.105

o con uno qualunque dei nomi aggiuntivi inseriti nella configurazione, come:

ssh utente@testserver

La scelta di usare una coppia di chiavi dedicate come nell'esempio precedente ha il vantaggio che non serve fare nessuna modifica alla configurazione sul bastion host e limitarsi a distribuire i file, ma non è possibile bloccare l'uso del proxy ad un utente cui si sia dato la coppia di chiavi a meno di non cambiarla per tutti.

Per questo, pur comportando il tutti un maggior lavoro di configurazione, è più sicuro e flessibile farsi inviare dal singolo utente esterno la chiave pubblica con cui questo intenderà accedere, ed aggiungere questa a /home/sshproxy/.ssh/authorized_keys sempre con una configurazione analoga alla precedente:

restrict,port-forwarding ssh-rsa AAAAB3NzaC ... eOze07VFk= esterno@altrove.it

in questo caso, se la chiave corrisponde all'identità di default dell'utente che accede, si potrà anche ridurre la precedente configurazione del client a:

Host 192.168.42.105 testserver othername
    Hostname 192.168.42.105
    ProxyJump sshproxy@bastion.truelite.it

Ed inoltre si potrà usare la stessa chiave sulla macchina di destinazione (192.168.42.105 o qualunque altra) per fornire l'accesso, senza dover distribuire una password utente, cosa che è consigliabile comunque anche qualora si adotto la strategia precedente.