Truedoc

h1. Accesso SSH a reti interne tramite _bastion host_ (in maniera sicura)

Esistono diversi casi in cui può essere necessario fornire a singoli utenti un accesso con SSH a delle macchine disposte in una rete interna, e non si vuole fornire un accesso generico con una VPN, ma solo un collegamento SSH verso una singola macchina. Per ottenere questo risultato si può sfruttare, posto che sia raggiungibile con SSH, un firewall (o in generale un bastion host che si affacci su detta rete) appoggiandosi ad una delle funzionalità avanzate del servizio, il cosiddetto "Proxy Jump", introdotto con OpenSSH 7.3 (rilasciata nell'agosto 2016) e ormai disponibile su tutte le distribuzioni recenti.

Questa funzionalità prevede che si possa, passando attraverso una macchina a cui si ha accesso in SSH (che farà da proxy), avere un reinoltro in maniera trasparente della connessione SSH verso un'altra macchina da questa raggiungibile. 

In questo modo si può effettuare una connessione verso un IP di una rete interna avendo cura di indicare qual è la macchina che si intende usare come proxy con l'opzione @-J@.  Solo quest'ultimaa dovrà essere raggiungibile da Internet, ma passando attraverso di essa ci si potrà collegare utilizzando direttamente l'indirizzo interno (o un nome a piacere, come vedremo più avanti). 

!bastion.png!

Uno schema elementare della rete è quello illustrato in figura, per collegarsi alla macchina server sull'indirizzo interno @192.168.42.105), si potrà allora utilizzare il comando:

<pre>

ssh -J utenteX@bastion.truelite.it utenteY@192.168.42.105

</pre>

e una volta autenticati (su entrambe le macchine) si otterrà l'accesso al server interno.

Ovviamente se lo scopo è quello di fornire accesso solo alla macchina interna ad un utente esterno, fornire un utente 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, non è particolarmente comodo. Fortunatamente l'autenticazione a chiavi di SSH ci viene incontro, e permette di semplificare notevolmente le operazioni, rendendo al contempo il servizio molto più sicuro.

Il primo passo è quello di creare un utente sul _bastion host_ da dedicare a questo servizio, privandolo al contempo 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.

<pre>

useradd -r sshproxy -s /sbin/false

</pre>

per l'accesso creeremo una coppia di chiavi senza passphrase per fornire accesso a questo utente, per semplicità lo faremo direttamente nella home dell'utente, copiando poi la chiave pubblica sotto @.ssh/authorized_keys@, con:

<pre>

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

</pre>

In questo modo si evita che l'utente @sshproxy@ possa ottenere una shell sul bastion host, ma restano diverse altre funzionalità, come il reinoltro delle porte o i tunnel, che di nuovo non vogliamo siano  disponibili. Per questo limiteremo ulteriormente le capacità dell'utente, 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 al'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:

<pre>

Match User sshproxy

     AllowAgentForwarding no

     AllowTcpForwarding yes

     X11Forwarding no

     PermitTunnel no

     GatewayPorts no

</pre>

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 configuraione 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 è valida, usando @sshd -T@.

Il secondo metodo è più flessibile e di nuovo 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:

<pre>

restrict,port-forwarding ssh-rsa AAAAB3NzaC ...

</pre>