SSH è tuo amico

OpenSSH_logo
Quando tutto si muove verso la nuvola,  SSH diventa uno strumento importantissimo per gestire i nostri sistemi lassù. Ogni sviluppatore ormai dovrebbe saper maneggiare questo strumento con disinvoltura, ma nonostante sia in circolazione già da un po’ di anni,  spesso ho riscontrato che non ne vengono sfruttate potenzialità e scorciatoie che questo ci offre.

Nello specifico parlo di OpenSSH, il più diffuso sulle varie distribuzioni Linux e Mac (su Windows non so come sia la situazione, a parte usare putty saltuariamente), questo post vuole mostrare qualche piccolo accorgimento che aiuti tutti quelli che quotidianamente su una shell scrivono “ssh qualchecosa”.

Alias di connessione

Stufi di scrivere cose del tipo:

ssh root@123.10.20.30 -p 2222

Nel file ~/.ssh/config è sufficiente avere

Host myserver
  Hostname 123.10.20.30
  Port 2222
  User root

Per farlo diventare:

ssh myserver

Con l’utilizzo degli alias diventa anche più pratico utilizzare porte non standard SSH, cosa che nel suo piccolo aiuta ad evitare di finire tra i bersagli di bot che cercano connessioni su cui poi tentare di ricavarne un accesso.

Piccola curiosità: l’alias funziona anche con altri programmi esterni che si appoggiano ad ssh, ad esempio Midnight Commander (altro utilissimo strumento da avere se si lavora su shell)

Non far cadere la connessione

Sempre nel file ~/.ssh/config

Host *
  ServerAliveInterval 60

Ogni 60 secondi verrà inviato al server un pacchetto per indicare che il client è ancora connesso. È facilmente intuibile che con “Host *” l’opzione sarà utilizzata per ogni alias di connessione.

Tunnel

Quello che si fa veramente quando si utilizza un tunnel SSH è istruire il computer di fare qualcosa di questo tipo: “In quel server laggiù c’è un servizio (es. mysql) che ascolta alla porta 3306. Fai finta che giri sul mio computer locale alla porta 3307”

Un tunnel quindi ha il compito di rendere accessibile alla macchina locale un servizio su una macchina remota altrimenti inaccessibile. Questo avviene scegliendo la porta del servizio remoto e “proiettandola” come un servizio in ascolto sulla macchina locale.

Esempio: accedere a un database mysql su un server remoto

Descrizione delle macchine coinvolte:

  • mylocal: macchina locale dalla quale voglio poter accedere al database come se ascoltasse alla porta 3307
  • myserver: macchina remota su cui mysql ascolta alla porta 3306 (non esposta verso internet… per questo usiamo ssh!)
io@mylocal ~$ ssh root@myserver -L 3307:localhost:3306

Analizziamo il comando:

  • “ssh root@myserver” – stabilisce la connessione SSH, tutto come al solito…
  • “-L” – parametro per indicare che sto facendo un tunnel”
  • “3307” – porta locale su cui SSH si metterà in ascolto facendo da tunnel
  • “localhost:3306” – indirizzo della macchina e porta del servizio da “proiettare” in locale. Questo indirizzo viene risolto dalla macchina remota appena fatta la connessione, per questo motivo “localhost” sarà la macchina stessa a cui ci siamo connessi, cioè “myserver”, alla porta 3306.

L’ultima parte risulta molto interessante perchè se una volta connessi alla macchina myserver, possiamo indirizzare un servizio “localhost:3306”, chi ci impedisce di indirizzare un altro servizio magari su un’altra macchina accessibile a myserver ma non a noi direttamente? Nessuno!

Quindi se mysql fosse in realtà in ascolto su una macchina di nome “dbserver” accessibile da “myserver” (ma non da noi) il comando diventerebbe:

io@mylocal ~$ ssh root@myserver -L 3307:dbserver:3306

Mettere il tunnel in background

Eseguendo il comandi nell’esempio, noterete che viene comunque aperta una shell su “myserver”. Se volete creare solo il tunnel senza accedere alla shell può essere pratico istruire SSH di andare in background.

io@mylocal ~$ ssh root@myserver -fN -L 3307:localhost:3306
  •  -f : mette il processo in background
  • -N: disabilita l’invio di comandi remoti verso la shell

Accesso con chiavi pubbliche/private

Non si può non accennare l’argomento che tratterò più in dettaglio in altre occasioni.

Ribadisco tuttavia l’importanza di questa modalità di accesso che è uno dei pochi casi in cui per l’utente (più che per l’amministratore di un sistema) si incrementano sia sicurezza che praticità d’uso, fattori tipicamente in contrapposizione, ma che al costo di una configurazione iniziale danno grandi benefici nell’uso quotidiano, e permettono anche qualche “trucchetto” se gestite ad esempio repository mercurial (non anticipo altro!)

Leave a Reply

Your email address will not be published. Required fields are marked *