Qualche informazione su ssh + chiavi

Alcuni punti preliminari:

  1. il server ssh effettivamente non utilizza l'autenticazione locale tramite password se la negoziazione della sessione tramite l'uso delle chiavi RSA/DSA va a buon fine
  2. è possibile avere un numero pressoché illimitato di chiavi e di identità diverse

La generazione delle chiavi viene portata a termine dal programma ssh-keygen; è necessario specificare all'atto della generazione il tipo di chiave richiesta e per la versione 2 del protocollo ssh è possibile utilizzare indifferentemente chiavi RSA o DSA:

ssh-keygen -t rsa

genera una chiave privata in ~/.ssh/id_rsa ed una pubblica in ~/.ssh/id_rsa.pub; durante la generazione è richiesta una passphrase, che può essere eventualmente nulla. Il file ~/.ssh/id_rsa viene creato con i permessi che impediscono la lettura a tutti tranne che al proprietario: il programma ssh (e gli altri derivati: scp, sftp, etc.) non effettuano alcuna operazione se questo è leggibile anche da altri soggetti.

Una volta trasferita la chiave pubblica sul computer remoto, questa chiave deve essere salvata in ~/.ssh/authorized_keys per permettere al server ssh di utilizzarla durante la negoziazione di ogni nuova sessione. Questo file può contenere più di una chiave ed il server le prova tutte nell'ordine in cui compaiono: se nessuna delle chiavi da seguito ad una risposta corretta da parte del client ssh allora il server ssh ricorre all'autenticazione locale tramite password, quindi è possibile disabilitare completamente l'account in questione (passwd -l <account>) pur continuando ad utilizzarlo[1]. Inutile dire che la chiave pubblica può essere utilizzata per un numero qualsiasi di account remoti.

La struttura di una chiave pubblica RSA è:

ssh-rsa <caterva di numeri e lettere> <commento>

Prima di "ssh-rsa" è possibile aggiungere alcune opzioni, tra cui:

from="pattern-list" per indicare di restringere l'elenco dei computer dai quali è possibile connettersi a questo pc utilizzando questa chiave particolare
command="comando" invece del comando predefinito (una shell) o del comando che il client ssh può richiedere venga eseguito, il server esegue solo questo comando e termina la sessione immediatamente (NB: tanto per essere chiari, se si utilizza quest'opzione non è possibile effettuare scp con la chiave in questione!)

Le chiavi private generate da ssh-keygen possono essere salvate in file con un nome qualsiasi ed è possibile utilizzare di volta in volta chiavi differenti specificando il nome del file che contiene la chiave privata:

# Utilizza la chiave in ~/.ssh/id_rsa
ssh pinco@pallino.com

# Utilizza la chiave in ~/.ssh/unaltrachiave
ssh -i ~/.ssh/unaltrachiave pinco@pallino.com

Con questa base è abbastanza semplice automatizzare alcuni compiti su pc remoti o la comunicazione con alcuni pc evitando l'interazione diretta con l'operatore e senza lasciare aperte troppe "porte": l'account remoto, una volta "bloccato" dovrebbe essere difficilmente manomissibile dall'esterno (dato che solo il possessore della chiave privata può utilizzarlo) e all'account locale che contiene la chiave privata potrebbe essere, per esempio, inibito il login sul computer locale via ssh (vedere sshd_config(8), direttive AllowUsers e DenyUsers); aggiungiamo che non passa alcuna informazione in chiaro... insomma, dormo abbastanza tranquillo :-)

Tralasciando i dettagli della configurazione della versione preistorica di PostgreSQL (viva la Debian stable!!! :-( ) che mi costringono ad una vera e propria mostruosità per evitare che venga richiesta la password all'atto del dump (all'ora in cui avverranno spero di essere ancora nel mondo dei sogni), per automatizzare almeno in parte il dump dei database ed il trasferimento in locale degli stessi ho creato un nuovo utente locale (che non può effettuare il login sul server dell'ufficio di M.I. via ssh) ed un paio di chiavi RSA con passphrase nulla (si poteva risolvere tutto con una chiave sola, ma non volevo appesantire lo script che cicla sui vari database): alla prima chiave, quella di default, è stato aggiunto in testa il comando per effettuare il dump dei database su XXX.YYY e non può essere utilizzata per altri scopi; la seconda chiave viene utilizzata immediatamente dopo la terminazione del dump per effettuare scp e trasferire in locale il file:

for u in <lista database>; do
  # Ritorna immediatamente il controllo al termine del dump.
  ssh ${u}@XXX.YYY
  scp -i ~/.ssh/altrachiave ${u}@XXX.YYY:~/dump.${u}.* .
done

Ovviamente, su XXX.YYY i dump devono essere rimossi dopo il trasferimento, ma a questo pensa il crontab di root il giorno dopo. (Prima che me lo chiedi, quell'asterisco è necessario perché i dump si chiamano tutti dump.<database>.$(date +%Y%m%d-%H%M%S), cioè con la data e l'ora in uno dei formati iso per avere uno storico dei backup e non mi è venuto in mente alcuna soluzione su come comunicare allo script locale la data e l'ora remota :-))

Eventuali commenti/suggerimenti/insulti/maledizioni sono sempre bene accetti (magari per iscritto, se si tratta di commenti e suggerimenti: verba volant, scripta manent).

[1] Sarebbe meglio disabilitare globalmente l'autenticazione tramite password impostando PasswordAuthentication al valore no in /etc/ssh/sshd_config.

Ultima modifica: Fri Aug 19 17:46:44 CEST 2005

Valid HTML 4.01! Valid CSS!