Molti utenti avanzati danno per scontato alcune funzionalità del procollo SSH, cio nonostante alcuni amministratori di sistema pensano che questo protocollo serva solamente a connettersi da remoto alle shell dei servers e non lo sfruttano appieno.

Il protocollo SSH ha moltissime features che vanno oltre alla gestione remota, come la possibilità di utilizzarlo per trasferire files (SFTP), oppure la possibilità di utilizzarlo come proxy per inoltrare le connessioni di altri servizi.

In questo articolo verranno analizzate le funzionalità di “Port Forwarding” per inoltrare le connessioni e le direttive ProxyCommand e ProxyJump per sfruttare dei servers come jumps per raggiungerne altri dietro ai dei firewall.

Inoltre, verrà mostrato come configurare il proprio client SSH, sia su sistemi POSIX (come Linux e MacOS), che su Windows mediante la funzionalità aggiuntiva.

INSTALLAZIONE DEL CLIENT SSH SU WINDOWS

Il client SSH è una Windows Capability a partire da Windows 10 ed è possibile abilitarlo mediante PowerShell.

Per verificare se la funzionalità è già attiva eseguire il seguente comando in una PowerShell amministrativa:

Se il client è abilitato l’output mostrato dovrebbe essere simile al seguente:

Altrimenti, è possibile installarlo con il seguente comando:

Affinché il comando sia utilizzabile da terminale (CMD o PowerShell) potrebbe essere necessario ricaricare l’ambiente, per farlo chiudere e riaprire il terminale.

Sui sistemi POSIX il client SSH è quasi sempre già presente senza la necessità di installare pacchetti aggiuntivi.

 

CONFIGURAZIONE DELLE CHIAVI SSH

L’autenticazione mediante chiavi SSH è estremamente consigliata al posto dell’utilizzo di username e password, poichè oltre che essere decisamente più sicura, è anche più pratica, poichè evita di dover inserire le credenziali ogni volta che ci si connette ad un server.

È possibile utilizzare chiavi diverse per gruppi di server differenti, oppure sempre la stessa, inoltre la chiave privata può venir cifrata mediante una passphrase, oppure può rimanere in chiaro per praticità.

Per generare una coppia di chiavi SSH (pubblica e privata) è possibile eseguire su un terminale con il proprio utente il seguente comando:

L’output è simile al seguente:

In questo caso la chiave viene generata con l’argoritmo ED25519, che ha il vantaggio di utilizzare chiavi più brevi, ma in alcuni sistemi l’argoritmo di default potrebbe essere RSA.

Se si vuole specificare l’argoritmo è possibile aggiungere l’opzione “-t” al comando, in seguito un esempio per RSA:

Se non viene specificato diversamente quando viene chiesto “Enter file in which to save the key” la coppia di chiavi viene salvata nelle seguenti posizioni.

Chiavi RSA:

• Privata: ~/.ssh/id_rsa
• Pubblica: ~/.ssh/id_rsa.pub

Chiavi ED25519:

• Privata: ~/.ssh/id_ed25519
• Pubblica: ~/.ssh/id_ed25519.pub

Quando viene chiesto Enter passphrase è possibile specificare un passphrase per cifrare la chiave privata, che poi sarà necessario inserire quando ci si collega in SSH ad un server utilizzando quella chiave per autenticarsi.

Altre opzioni utili sono -b per specificare la dimensione della chiave e -C per modificare il commento, in seguito un esempio:

Da riga di comando per specificare la chiave da utilizzare è possibile utilizzare il flag -i:

Successivamente in questo articolo verrà mostrato, modificando i files di configurazione, come evitare di dover specificare ogni volta che ci si connette che chiave utilizzare.

Se in fase di autenticazione con un server remoto viene mostrato un errore permissions are too open, significa che i permessi della chiave privata consentono ad altri utenti oltre che al proprio di leggerla e perciò il client SSH si rifiuta di utilizzarla.

Per correggere i permessi bisogna seguire due procedure diverse in base a se si sta utilizzando Windows o un sistema POSIX.

Per i sistemi POSIX eseguire con il proprio utente i seguenti comandi:

Su Windows selezionare la cartella .ssh nella propria HOME, tipicamente nel percorso C:\Users\<username>\.ssh, fare click destro e selezionare Properties:

Navigare nel tag Security e selezionare Advanced per aprire la gestione dei permessi avanzata.

Cliccare su Disable inheritance per disabilitare l’ereditarietà dei permessi ed assegnare Full control al proprio utente, a SYSTEM ed agli Administrators, come mostrato nel seguente screenshot:

Confermare ed uscire cliccando su Ok nelle due finestre.

CONFIGURAZIONE DEL FILE CONFIG

Il file ~/.ssh/config (su Windows C:\Users\<username>\.ssh) è la configurazione principale del client SSH, in questo file è possibile configurare le opzioni globali ed aggiungere i servers a cui ci si vuole connettere, tuttavia al fine di mantenere la configurazione ordinata, si consiglia suddividere gli hosts in più files.

Se il file config non esiste è possibile crearlo, però, in particolare su Windows, bisogna fare attenzione a non aggiungere un’estensione (tipo .txt); per modificarlo è possibile utilizzare qualsiasi editor di testo.

Aggiungere in cima al proprio file config la seguente direttiva:

Inoltre, è possibile inserire alcune opzioni globali, in seguito un esempio:

Con la configurazione precedente il client SSH aggiungerà in automatico le hostkeys per i nuovi servers, abiliterà la Command Line (vedi prossimo paragrafo) ed utilizzerà i keepalive ogni 30 secondi di inattività, in modo che le connessioni inattive non vengano terminate da apparati stateful presenti tra il client ed il server SSH.

È possibile specificare qualsiasi opzione che verrà mostrata nei seguenti passaggi, se esistono due opzioni uguali vince quella caricata per prima, per questo motivo potrebbe essere utile utilizzare una nomenclatura per i files di configurazione che contenga un numero (esempio: 00-customer.conf, 01-customer-prod.conf, 02-customer-dev.conf…).

Aggiungendo la direttiva Include config.d/* all’inizio del file config ci si assicura che le opzioni nel file config abbiano meno priorità rispetto a quelle nei files nella directory config.d.

È anche possibile specificare pattern più complessi, in seguito un esempio per utilizzare username diversi in base all’hostname:

Creare la directory ~/.ssh/config.d in cui sarà possibile aggiungere i files di configurazione suddivisi in base alle proprie necessità, ad esempio un file per ogni cliente, oppure uno per ambiente.

Per crearla sui sistemi POSIX eseguire in una shell con il proprio utente il seguente comando:

Per crearla su Windows eseguire in una PowerShell con il proprio utente il seguente comando:

In seguito un esempio di configurazione di un server nel file ~/.ssh/config.d/prod.conf:

Nell riga Host è possibile specificare i nomi con cui si vuole richiamare il server quando ci si connette, in questo caso:

Oppure:

La direttiva HostName serve ad indicare l’IP o il nome DNS da utilizzare per colleagarsi al server remoto, esso può differire dai nomi specificati con Host.
La direttiva User serve ad indicare lo username da utilizzare per collegarsi al server remoto, se non indicato viene utilizzato lo stesso username della macchina da cui si esegue SSH client.
La direttiva IdentityFile serve ad indicare il path della chiave privata da utilizzare per autenticarsi, se non indicato viene utilizzato il file ~/.ssh/id_rsa oppure il file ~/.ssh/id_ed25519.

Altre configurazioni più complesse verranno analizzate nei prossimi paragrafi di questo articolo.

UTILIZZO DELLA COMMAND LINE SSH

La Command Line viene utilizzata per impartire dei comandi al client SSH quando ci si trova già connessi ad un server.

Nei prossimi capitoli verrà citata, perciò è utile sapere come accedervi.

Per utilizzarla bisogna già essere connessi ad una sessione e poi seguire i passaggi elencati:

1. Premere Invio o Enter (la tilde viene riconosciuta solo all’inizio di una riga)
2. Premere la tilde (~)
3. Premere la lettera C maiuscola

Dovrebbe venir mostrata una riga che inizia con:

In questa riga è possibile inserire il comando e premendo Invio o Enter lo si esegue, in seguito un esempio di Local Forward (vedi prossimo paragrafo):

Se viene mostrato il seguente errore:

Significa che bisogna abilitare la Command Line nella configurazione del proprio client, per farlo aggiungere la seguente direttiva:

Esempio:

Successivamente vengono riportate alcune escape sequences, oltre alla Command Line (~C), che si possono adoperare durante una sessione SSH:

~ . Termina la connessione immediatamente (utile se il server è bloccato e non risponde).
~ ^Z Sospende SSH e ti riporta al terminale locale (usa fg per tornare in SSH).
~ # Elenca tutti i port forward attivi nella sessione corrente.
~ ? Mostra una lista di aiuto con tutte le sequenze di escape disponibili.
~ V Diminuisce il livello di verbosità (meno log).

In seguito un esempio in cui vengono visualizzate le connessioni con forward:

 

CONFIGURAZIONE LOCAL FORWARD MEDIANTE SSH

Spesso capita che si debba accedere ad un servizio di un server remoto che non è raggiungibile dal proprio client a causa di una regola sul firewall che impedisce di contattare alcune porte.

In questi casi è possibile utilizzare un server SSH per effettuare il forwarding delle porte necessarie, in modo da superare il firewall, questo processo si chiama Local Forward.

In seguito due disegni che illustrano questa situazione:

 

Nel primo schema il servizio da raggiungere si trova sulla stessa macchina a cui ci collega in SSH, nel secondo, invece, il servizio è servito da un altro server.

Per effettuare il Local Forward di una o più porte è possibile procedere mediante file di configurazione, flag durante la connessione, oppure Command Line se si è già connessi al server remoto.

Il flag per abilitare il Local Forward è -L ed utilizza la seguente sintassi:

In seguito alcuni esempi:

Nel primo esempio viene effettuato il forward della porta 8080 del client verso la porta 80 del server server-www-01, il binding sul client della porta 8080 avviene solamente per localhost, poichè se LOCAL HOST non viene specificato si assume 127.0.0.1 e ::1.

Nel secondo esempio vengono effettuati due forwards: il primo viene effettuato dalla porta 3306 del client verso la porta 3306 del server server-db-prod-01, il secondo viene effettuato dalla porta 8080 del client verso la porta 80 del server server-www-01 (127.0.0.1).

Il binding nel secondo esempio avviene solamente per localhost per la porta 3306 e su tutte le interfacce IPv4 (0.0.0.0) per la porta 8080, perciò chiunque sia connesso alla stessa rete del client potrà contattare il server server-www-01 utilizzando il tunnel, salvo configurazioni diverse sul firewall del client, ma non potrà contattare il server server-db-prod-01.

Al posto 0.0.0.0 è possibile utilizzare un qualsiasi IP appartenente al client e la porta verrebbe reindirizzata solo per le richiesti provenienti su quell’IP.

Il flag -L può essere combinato con il flag -R, che verrà spiegato nel prossimo paragrafo, per effettuare anche il Remote Forward.

La medesima sintassi è utilizzabile in Command Line per aprire dei tunnel quando si è già connessi al server remoto:

Invece, per configurare il Local Forward mediante file di configurazione è necessario aggiungere la direttiva LocalForward nella configurazione dell’host interessato.

In seguito alcuni esempi:

Nel primo esempio viene effettuato il forward della porta 4443 del client verso la porta 443 del server server-www-01, il binding sul client della porta 4443 avviene solamente per localhost.

Nel secondo esempio vengono effettuati due forwards: il primo viene effettuato dalla porta 3306 del client verso la porta 3306 del server server-db-prod-01, che è raggiungibile dal server remoto, il secondo viene effettuato dalla porta 4443 del client verso la porta 443 del server server-www-01 (127.0.0.1).

Il binding nel secondo esempio avviene solamente per localhost per la porta 3306 e su tutte le interfacce IPv4 (0.0.0.0) per la porta 4443.

Analogamente a come avviene con la sintassi mostrata precedentemente è possibile combinare la direttiva “LocalForward” con la direttiva RemoteForward, che verrà descritta nel prossimo paragrafo, per effettuare anche il Remote Forward.

ATTENZIONE:
Quando si utilizzano nomi DNS al posto di IP per instaurare un Local Forward bisogna considerare che LOCAL HOST viene risolto dal client e REMOTE HOST viene risolto dal server SSH.
Perciò nell’esempio precedente in cui si utilizzava la seguente stringa localhost:3306:server-db-prod-01:3306, localhost viene risolto dal client e server-db-prod-01 dal server remoto.

CONFIGURAZIONE REMOTE FORWARD MEDIANTE SSH

A volte potrebbe capitare di trovarsi nella sitazione opposta a quella descritta dal paragrafo precedente, per cui si ha la necessità di far contattare da un server remoto, raggiungibile in SSH, un servizio locale rangiungibile dal client.

In questi casi mediante il Remote Forward è possibile effettuare il forwarding di alcune porte dal server remoto al proprio client, in modo di superare il firewall nel senso opposto rispetto al Local Forward.

In seguito due disegni che illustrano questa situazione:

 

Nel primo schema il servizio da raggiungere si trova sul client, nel secondo, invece, il servizio è servito da un altro server.

Per effettuare il Remote Forward di una o più porte è possibile procedere mediante file di configurazione, flag durante la connessione, oppure Command Line se si è già connessi al server remoto; inoltre è possibile combinarlo con il Local Forward.

Il flag per abilitare il Remote Forward è -R ed utilizza la seguente sintassi:

In seguito alcuni esempi:

Nel primo esempio viene effettuato il forward della porta 6379 verso la porta 6379 del client, il binding sul server remoto della porta 6379 avviene solamente per localhost.

Nel secondo esempio vengono effettuati due forwards: il primo viene effettuato dalla porta 3306 del server remoto verso la porta 3306 del server server-db-dev-01, che è raggiungibile dal client, il secondo viene effettuato dalla porta 8080 del server remoto verso la porta 80 del client.

Il binding nel secondo esempio avviene solamente per localhost per la porta 3306 e su tutte le interfacce IPv4 (0.0.0.0) per la porta 8080.

La medesima sintassi è utilizzabile in Command Line, per aprire dei tunnel quando si è già connessi al server remoto:

Invece, per configurare il Remote Forward mediante file di configurazione è necessario aggiungere la direttiva RemoteForward nella configurazione dell’host interessato.

In seguito un esempio che contiene sia un Local Forward che due Remote Forwards:

ATTENZIONE:
Quando si utilizzano nomi DNS al posto di IP per instaurare un Remote Forward bisogna considerare che LOCAL HOST viene risolto dal client e REMOTE HOST viene risolto dal server SSH.
Perciò nell’esempio precedente in cui si utilizzava la seguente stringa localhost:3306:server-db-dev-01:3306, localhost viene risolto dal server remoto e server-db-dev-01 dal client.

CONFIGURAZIONE DYNAMIC FORWARD MEDIANTE SSH

Le due tipologie di Port Forwarding descritte fin’ora possono risultare molto utili in moltissimi contesti, tuttavia a causa della limitazione di dover configurare le porte manualmente, risultano poco pratiche nei casi in cui si voglia utilizzare l’SSH come proxy per il traffico del browser o delle app.
In questo paragrafo verrà mostrato come sfruttare questa funzionalità per utilizzare un server SSH come Web Proxy per il traffico HTTP e HTTPS su Windows 11.

In seguito un disegno che ne illustra il funzionamento:

fig 7

Per effettuare il Dynamic Forward di una o più porte è possibile procedere mediante file di configurazione, flag durante la connessione, oppure Command Line se si è già connessi al server remoto; inoltre è possibile combinarlo con il Local Forward ed il Remote Forward.

Il flag per abilitare il “Dynamic Forward” è -D ed utilizza la seguente sintassi:

In seguito alcuni esempi:

Nel primo esempio il proxy sarà utilizzabile solamente dal client, poichè è in ascolto solamente su localhost, invece nel secondo esso è in ascolto su tutte le interfacce del client, perciò potrebbe essere utilizzabile anche da altre macchine.

La medesima sintassi è utilizzabile in Command Line, per aprire dei tunnel quando si è già connessi al server remoto:

Invece, per configurare il Dynamic Forward mediante file di configurazione è necessario aggiungere la direttiva DynamicForward nella configurazione dell’host interessato.

In seguito un esempio:

Quando il tunnel viene stabilito è possibile modificare le impostazioni di sistema o quelle del browser o dell’app interessata.

Per configurare il proxy a livello di sistema, su Windows 11, recarsi nelle impostazioni, navigare su Network & internet e poi selezionare Proxy:

Cliccare su Set up in prossimità di Use a proxy server:

Abilitare l’opzione Use a proxy server, compilare l’IP specificando 127.0.0.1 e la porta specificando quella utilizzata come LOCAL PORT per il binding, infine salvare cliccando su Save:

A questo punto dovrebbe essere possibile navigare dal browser utilizzando il server SSH come Web Proxy, se non funzionasse verificare che la sessione SSH sia stata mantenuta aperta.
Per non dover utilizzare il proxy per tutte le connessioni è possibile non configurarlo a livello di sistema e sfruttare delle estensioni del browser che permettono di indicare per quali IP e per quali nomi DNS le richieste devono passare dal proxy.

 

MENZIONE SSH TUN

Le funzionalità descritte precedentemente, raggruppabili nella categoria Port Forwarding, lavorano sul layer-7 della pila OSI e perciò non è possibile sfruttarle per implementare una VPN.

Mediante la funzionalità SSH TUN è possibile creare delle interfacce di rete virtuali utilizzabili per la compilazione della routing table, però sono necessari i permessi amministrativi sia sul client che sul server remoto.

Non verrà mostrato come configurare una VPN mediante SSH, poichè è più complesso e meno efficace di altri protocolli specifici per questo scopo.

CONFIGURAZIONE PROXY COMMAND PER UTILIZZARE UNA JUMP MEDIANTE SSH

L’ultima funzionalità del protocollo SSH descritta in queso articolo è la mia preferita, poichè permette di lavorare anche in ambienti isolati, dove per raggiungere alcuni servers è necessario superare diversi firewalls.

Essa consente di configurare l’utilizzo di un proxy, o di una catena di proxies, per la connessione SSH e perciò rende possibile raggiungere la destinazione finale passando da tutti i servers necessari in modo semplice e veloce.

La stessa funzionalità può essere utilizzata per collegarsi ai servers mediante dei bastioni, per esempio in un altro articolo viene implementato, mediante HAProxy, un bastione SSH con mTLS che sfrutta proprio questa funzionalità.

In seguito un disegno che illustra questa dinamica:

Quando ci si connette mediante il comando ssh vengono automatiamente creati i tunnels necessari, rendendo l’esperienza utente estremamente fluida, specialmente se si utilizzano le chiavi per l’autenticazione, poichè permettono di autenticarsi senza bisogno del nostro intervento, salvo per digitare eventuali passphrase se si ha cifrato le chiavi private.

Per sfruttare questa funzionalità è sufficiente specificare ProxyCommand o ProxyJump in fase di connessione, o mediante riga di comando, oppure mediante file di configurazione, anche se quest’ultimo è fortemente consigliato poichè consente di stabilire la chain di proxiex senza doverla specificare ad ogni connessione.

In seguito la configurazione necessaria per implementare i tunnels mostrati nello schema, facendo utilizzo di chiavi private (identity files) diverse:

Poichè si trattano tutti di proxies creati mediante SSH, nei clients più recenti, è possibile sostituire ProxyCommand con ProxyJump per ottenere un’esecuzione più efficente:

Per collegarsi al server target-internal-host sarà sufficiente eseguire il seguente comando:

Nella seguente configurazione, invece, come ProxyCommand, al posto di utilizzare un tunnel SSH, viene proposto un tunnel creato mediante OpenSSL:

Per i tunnel non stabiliti mediante SSH non è possibile utilizzare la direttiva ProxyJump, però è possibile mischiare tunnels di natura diversa ed utilizzare questa direttiva per gli hop per cui si usano i tunnel SSH.

Invece, se si volesse specificare l’opzione da riga di comando sarebbe possibile utilizzare il flag -o, in seguito un esempio:

Sui clients più recenti al posto del precedente comando si consiglia di utilizzare il seguente:

È possibile combinare più proxy come nei seguenti esempi:

In modo analogo anche nel file di configurazione è possibile concatenare i proxies, gli esempi precedenti possono essere ricritti come riportato in seguito.

Primo esempio modificato:

Secondo esempio modificato:

Nel secondo esempio non è possibile specificare la chiave privata per i server che fungono da proxy, perciò se si salva la chiave in una posizione di non default (per esempio ~/.ssh/id_rsa-MyKen) sarà necessario aggiungerla al SSH Agent per far sì che venga utilizzata per le connessioni successive senza bisogno di configurarla esplicitamente per la connessione.

Per farlo eseguire il seguente comando:

A questo punto sarebbe anche possibile omettere la direttiva IdentityFile:

Per rimuovere le chiavi dal SSH agent eseguire:

Per rimuoverle tutte in un solo comando eseguire:

Se su Windows viene mostrato il seguente errore:

Significa che il servizio non è in esecuzione ed è necessario attivarlo, per farlo eseguire in una PowerShell come amministratore il seguente comando:

Se si vuole far partire automatiamente il servizio all’avvio del sistema operativo, eseguire il seguente comando:

Invece, sui sistemi POSIX potrebbe venir mostrato il seguente errore:

Eseguire in un terminale con il proprio utente il seguente comando:

 

CONCLUSIONE

Abbiamo visto che il client SSH è estremamente versatile, forse proprio per tutta questa libertà di configurazione a volte i sistemisti preferiscono utilizzare strumenti come Putty per connettersi ai servers, che per qualcuno potrebbero risultare più user friendly.

Una critica al client SSH che ho sentito è che bisogna ricordarsi tutti i servers a memoria ed i relativi IP, però in questo articolo abbiamo visto come la configurazione del client mediante files ne semplifica di molto la gestione e che non è vero che bisogna riscrivere ogni volta gli IP e le credenziali.

Inoltre, la ricerca ricorsiva, presente in moltissimi terminali, consente di connettersi ai propri servers digitando poche lettere del loro hostname, a patto che ci sia connessi almeno una volta e che l’history fosse attiva.

Per effettuare la ricerca ricorsiva, su una riga del terminale vuota, premere Ctrl-r e digitare alcune lettere:

Se ciò che si sta cercando non è il primo risultato è possibile navigare sui risultati successivi cliccando nuovamente Ctrl-r, invece se si ha superato erroneamente ciò che si stava cercando è possibile tornare indietro cliccando Ctrl-s.

Infine, quando viene mostrato il comando che si sta cercando è possibile eseguirlo premendo Invio o Enter.