Accesso SSH via bastion host a reti private » Cronologia » Versione 3
Versione 2 (Simone Piccardi, 21-07-2020 13:58) → Versione 3/12 (Simone Piccardi, 23-07-2020 12:56)
h1. 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 a delle macchine presenti nella propria disposte in una rete interna, senza però dare e non si vuole fornire un accesso generico alla stessa con una VPN. In sostanza si vuole poter consentire ad VPN, ma solo un utente esterno +solo+ un collegamento SSH verso una specifica macchina interna. singola macchina. Per ottenere questo risultato si può sfruttare sfruttare, posto che sia raggiungibile con SSH, 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 del 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. distribuzioni recenti. Questa funzionalità prevede che si possa, passando attraverso una macchina a cui si ha accesso SSH, in SSH (che farà da proxy), avere un reinoltro in maniera trasparente della connessione SSH verso un'altra macchina da questa raggiungibile. Si tratta in sostanza In questo modo si può effettuare una connessione verso un IP di usare l'SSH presente sul _bastion host_ come proxy del protocollo. La funzionalità una rete interna avendo cura di proxy deve essere richiesta dal client che esegue la connessione, usando l'opzione l'opzione @-J@ del comando per indicare qual è la macchina da che si intende usare come proxy. Può proxy con l'opzione @-J@. Solo quest'ultimaa dovrà essere inoltre essere indicata nella propria configurazione client (quella mantenuta nel file @.ssh/config@ nella propria home directory) con la direttiva @ProxyJump@. 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! Nel prosieguo faremo riferimento allo Uno schema di elementare della rete è quello illustrato nella figura precedente; in figura, per collegarsi alla macchina server sull'indirizzo interno @192.168.42.105, @192.168.42.105), si dovrà potrà allora utilizzare un comando simile: il comando: <pre> ssh -J utente_a@bastion.truelite.it utente_b@192.168.42.105 utenteX@bastion.truelite.it utenteY@192.168.42.105 </pre> e una volta autenticatisi prima sul bastion host che fa da proxy con @utente_a@ e poi sul server finale @con utente_b@, autenticati (su entrambe le macchine) si otterrà l'accesso al server interno. Ovviamente se lo scopo è quello di fornire accesso ad una solo alla macchina interna ad un utente esterno, fornire un accesso utente oridnario 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. comodo. Fortunatamente l'autenticazione a chiavi di SSH ci viene incontro, e permette di semplificare notevolmente le operazioni lato client, operazioni, rendendo al contempo l'accesso il servizio molto più sicuro. Il primo passo è quello di creare un utente sul _bastion host_ un utente dedicato da dedicare a questo servizio, privandolo al servizio contempo 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: accesso. <pre> useradd -r sshproxy -s /sbin/false </pre> Per fornire ad un esterno per 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 passphrase per fornire accesso a tutte le persone a cui si vuole fare usare il servizio. Per questo utente, per semplicità creeremo la coppia di chiavi lo faremo direttamente nella home dell'utente @sshproxy@, predisponendo l'accesso, con i seguenti comandi: 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 chiunque abbia a disposizione la coppia di chiavi potrà usarla per autenticarsi si evita che l'utente @sshproxy@ possa ottenere una shell sul bastion host, pur ma restano diverse altre funzionalità, come il reinoltro delle porte o i tunnel, che di nuovo non potendosi collegare allo stesso. vogliamo siano disponibili. Per migliorare la sicurezza sarà comunque opportuno bloccare anche tutte questo limiteremo ulteriormente le funzionalità di SSH non necessarie all'utilizzo della connessione ad uso di proxy, 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 all'uso 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 PasswordAuthentication 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 configurazione 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 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: <pre> restrict,port-forwarding ssh-rsa AAAAB3NzaC ... </pre> 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: <pre> ssh -J sshproxy@bastion.truelite.it -i .ssh/ proxy_id utente@192.168.42.105 </pre> 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: <pre> Host bastion.truelite.it User sshproxy IdentityFile ~/.ssh/proxy_rsa_id Host 192.168.42.105 testserver othername ProxyJump sshproxy@bastion.truelite.it </pre>