Using Rsync and SSH - Keys, Validating, and Automation

Questo articolo è la traduzione dell’articolo di Troy Johnson sul sito www.jdmz.net/ssh è descrive un metodo per effettuare la sincronizzazione fra directory utilizzando il programma ‘rsync’.

Siccome a me piace effettuare il backup di alcuni log, della posta e delle informazioni sulla configurazione a volte utilizzando degli host che si trovano sulla rete e su internet e qui è descritto un metodo che ho trovato per fare ciò.

E’ necessario che i seguenti pacchetti siano installati:

• rsync
• openssh
• cron (o vixie-cron)

Vi prego notare che queste istruzioni potrebbero essere specifiche alla Red Hat Linux dalla versione 7.3 alla 9, ma spero che non sarà troppo difficile adattarle a quasi tutti i sistemi operativi *NIX. Le “man pages” relative a ‘ssh’ e ‘rsync’ vi dovrebbero essere d’aiuto nel caso aveste bisogno di cambiare qualcosa.

1 - Verifichiamo di avere tutto funzionante

Per prima cosa definirò alcune variabili. Nella mia spiegazione, sincronizzerò dei files (copiando solo quelli nuovi o modificati) in una sola direzione, e inizierò questo processo dall’host su cui voglio copiare i dati. In altre parole, andrò a sincronizzare i files da /remota/dir su host_remoto autenticandoci come utente_remoto verso /locale/dir su host_locale come utente_locale.

Prima di automatizzare il processo, mi voglio assicurare che ‘rsync’ e ‘ssh’ funzionino correttamente, così li testerò prima come utente_locale:

$ rsync -avz -e ssh utente_remoto@host_remoto:/remota/dir /locale/dir/ 

inserendo la password di utente_remoto@host_remoto quando richiesto. In sostanza devo essere sicuro che utente_remoto abbia i permessi di lettura (read) sulla directory /remoto/dir su host_remoto e che utente_locale abbia i permessi di scrittura (write) nella directory /local/dir su host_locale. Inoltre, ‘rsync’ e ‘ssh’ dovrebbero essere nel percorso di ricerca (path) di utente_locale (utilizzate “which ssh” e “which rsync”), ‘rsync’ deve essere nel path di utente_remoto e ‘sshd’ dovrebbe essere in esecuzione su host_remoto.

Se tutto ha funzionato correttamente, o comunque l’ho fatto andare, sono pronto al passo successivo.

2 - Generazione di un paio di chiavi pubbliche/private

A questo punto ho bisogno di generare una coppia di chiavi pubbliche/private per consentire una connessione ‘ssh’ senza che mi venga richiesta la password. Questa cosa sembrerebbe abbastanza pericolosa… ed in effetti lo è! Ma è comunque sempre meglio che memorizzare la password utente (o key password) in chiaro nello script. E inoltre io posso porre alcune limitazioni su ciò che le connessioni possono fare con questa chiave. OK, adesso genererò la chiave che utilizzerò su host_locale (come utente_locale):

$ ssh-keygen -t dsa -b 2048 -f /home/utente_locale/cron/host_locale-rsync-key
Generating public/private dsa key pair.
Enter passphrase (empty for no passphrase): [press enter here]
Enter same passphrase again: [press enter here]
Your identification has been saved in /home/utente_locale/cron/host_locale-rsync-key.
Your public key has been saved in /home/utente_locale/cron/host_locale-rsync-key.pub.
The key fingerprint is:
2e:28:d9:ec:85:21:e7:ff:73:df:2e:07:78:f0:d0:a0 utente_locale@host_locale
$ 

Bene, adesso ho una chiave con nessuna password nei due files menzionati qui sopra (host_locale-rsync-key e host_locale-rsync-key.pub) [1]. Mi assicuro che nessun altro utente non autorizzato possa leggere il file della chiave privata (quello senza l’estensione ‘.pub’).

Questa chiave non serve a niente fino a quando non metterò la porzione pubblica nel file ‘authorized_keys’ su host_remoto, specificatamente per utente_remoto:

/home/utente_remoto/.ssh/authorized_keys

$ scp /home/utente_locale/cron/host_locale-rsync-key.pub utente_remoto@host_remoto

3 - A questo punto passo a preparare le cose su host_remoto.

Faccio ‘ssh’ su host_remoto per farci qualche lavoretto:

$ ssh utente_remoto@host_remoto
utente_remoto@host_remoto's password: [digita la password corretta]
$ echo I am now $USER at $HOSTNAME
I am now utente_remoto at host_remoto

Ho bisogno di essere sicuro di avere le directory e i files di cui ho bisogno per autorizzare le connessioni con questa chiave:

$ if [ ! -d .ssh ]; then mkdir .ssh ; chmod 700 .ssh ; fi
$ mv host_locale-rsync-key.pub .ssh/
$ cd .ssh/
$ if [ ! -f authorized_keys ]; then touch authorized_keys ; chmod 600 authorized_keys ; fi
$ cat host_locale-rsync-key.pub >> authorized_keys

Adesso la chiave può essere usata per fare delle connessioni a questo host, ma queste connessioni possono arrivere da qualunque direzione (fra quelle permesse dal demone ssh su host_remoto) e una volta connessi si può fare qualunque cosa (che l’utente_remoto sia abilitato a fare), ma noi non vogliamo questo. Editiamo (con vi) il file ‘authorized_keys’ è modifichiamo le informazioni contenute nela riga con ‘host_locale-sync-key.pub’. Aggiungeremo solo poche cose davanti a quello che già c’è, cambiando la riga da così:

ssh-dss AAAAB3NzaC1kc3MAAAEBAKYJenaYvMG3nHwWxKwlWLjHb77CT2hXwmC8Ap+fG8wjlaY/9t4u
A+2qx9JNorgdrWKhHSKHokFFlWRj+qk3q+lGHS+hsXuvta44W0yD0y0sW62wrEVegz+JVmntxeYc0nDz
5tVGfZe6ydlgomzj1bhfdpYe+BAwop8L+EMqKLS4iSacNjoPlHsmqHMnbibn3tBqJEq2QJjEPaiYj1iP
5IaCuYBhuTKQGa+oyH3mXEif5CKdsIKBj46B0tCy0/GC7oWcUN92QdLrUyTeRJZsTWsxKpRbMliD2pBh
4oyX/aXEf8+HZBrO5vQjDBCfTFQA+35Xrd3eTVEjkGkncI0SAeUAAAAVAMZSASmQ9Pi38mdm6oiVXD55
Kk2rAAABAE/bA402VuCsOLg9YS0NKxugT+o4UuIjyl6b2/cMmBVWO39lWAjcsKK/zEdJbrOdt/sKsxIK
1/ZIvtl92DLlMhci5c4tBjCODey4yjLhApjWgvX9D5OPp89qhah4zu509uNX7uH58Zw/+m6ZOLHN28mV
5KLUl7FTL2KZ583KrcWkUA0Id4ptUa9CAkcqn/gWkHMptgVwaZKlqZ+QtEa0V2IwUDWS097p3SlLvozw
46+ucWxwTJttCHLzUmNN7w1cIv0w/OHh5IGh+wWjV9pbO0VT3/r2jxkzqksKOYAb5CYzSNRyEwp+NIKr
Y+aJz7myu4Unn9de4cYsuXoAB6FQ5I8AAAEBAJSmDndXJCm7G66qdu3ElsLT0Jlz/es9F27r+xrg5pZ5
GjfBCRvHNo2DF4YW9MKdUQiv+ILMY8OISduTeu32nyA7dwx7z5M8b+DtasRAa1U03EfpvRQps6ovu79m
bt1OE8LS9ql8trx8qyIpYmJxmzIdBQ+kzkY+9ZlaXsaU0Ssuda7xPrX4405CbnKcpvM6q6okMP86Ejjn
75Cfzhv65hJkCjbiF7FZxosCRIuYbhEEKu2Z9Dgh+ZbsZ+9FETZVzKBs4fySA6dIw6zmGINd+KY6umMW
yJNej2Sia70fu3XLHj2yBgN5cy8arlZ80q1Mcy763RjYGkR/FkLJ611HWIA= utente_locale@host_locale

a così:

from="10.1.1.1",command="/home/host_remoto/cron/validate-rsync" ssh-dss AAAAB3NzaC1kc3MAAAEBAKYJenaYvMG3nHwWxKwlWLjHb77CT2hXwmC8Ap+fG8wjlaY/9t4u
A+2qx9JNorgdrWKhHSKHokFFlWRj+qk3q+lGHS+hsXuvta44W0yD0y0sW62wrEVegz+JVmntxeYc0nDz
5tVGfZe6ydlgomzj1bhfdpYe+BAwop8L+EMqKLS4iSacNjoPlHsmqHMnbibn3tBqJEq2QJjEPaiYj1iP
5IaCuYBhuTKQGa+oyH3mXEif5CKdsIKBj46B0tCy0/GC7oWcUN92QdLrUyTeRJZsTWsxKpRbMliD2pBh
4oyX/aXEf8+HZBrO5vQjDBCfTFQA+35Xrd3eTVEjkGkncI0SAeUAAAAVAMZSASmQ9Pi38mdm6oiVXD55
Kk2rAAABAE/bA402VuCsOLg9YS0NKxugT+o4UuIjyl6b2/cMmBVWO39lWAjcsKK/zEdJbrOdt/sKsxIK
1/ZIvtl92DLlMhci5c4tBjCODey4yjLhApjWgvX9D5OPp89qhah4zu509uNX7uH58Zw/+m6ZOLHN28mV
5KLUl7FTL2KZ583KrcWkUA0Id4ptUa9CAkcqn/gWkHMptgVwaZKlqZ+QtEa0V2IwUDWS097p3SlLvozw
46+ucWxwTJttCHLzUmNN7w1cIv0w/OHh5IGh+wWjV9pbO0VT3/r2jxkzqksKOYAb5CYzSNRyEwp+NIKr
Y+aJz7myu4Unn9de4cYsuXoAB6FQ5I8AAAEBAJSmDndXJCm7G66qdu3ElsLT0Jlz/es9F27r+xrg5pZ5
GjfBCRvHNo2DF4YW9MKdUQiv+ILMY8OISduTeu32nyA7dwx7z5M8b+DtasRAa1U03EfpvRQps6ovu79m
bt1OE8LS9ql8trx8qyIpYmJxmzIdBQ+kzkY+9ZlaXsaU0Ssuda7xPrX4405CbnKcpvM6q6okMP86Ejjn
75Cfzhv65hJkCjbiF7FZxosCRIuYbhEEKu2Z9Dgh+ZbsZ+9FETZVzKBs4fySA6dIw6zmGINd+KY6umMW
yJNej2Sia70fu3XLHj2yBgN5cy8arlZ80q1Mcy763RjYGkR/FkLJ611HWIA= thisuser@thishost

dove “10.1.1.1” è l’indirizzo IP di host_locale e “/home/host_remoto/cron/validate-rsync” è uno script che assomiglia a qualcosa di simile a questo:

#!/bin/sh

RSYNC=/usr/bin/rsync
SSH=/usr/bin/ssh
KEY=/home/utente_locale/cron/host_locale-rsync-key
RUSER=utente_remoto
RHOST=host_remoto
RPATH=/remota/dir
LPATH=/locale/dir/
$RSYNC -az -e "$SSH -i $KEY" $RUSER@$RHOST:$RPATH $LPATH

Se host_locale ha un indirizzo variabile oppure condivide il proprio indirizzo (via NAT o qualcosa di simile) con degli host che ritieni non sicuri, ometti la parte con ‘from=“10.1.1.1”,’ dalla riga (compresa la virgola), ma lascia la parte con ‘command’. In questa maniera solo l’ ‘rsync’ sarà possibile da connessioni che useranno questa chiave.

NOTA BENE:

La chiave privata, sebbene adesso in qualche maniera limitata in quello che può fare (e si spera anche sul “da dove”), permette al suo possessore di copiare qualunque file da host_remoto. Questo è pericoloso ed è quindi necessario prendere qualunque precauzione si ritenga necessaria per mantenere la sicurezza e la segretezza di questa chiave. Alcune possibilità sarebbero quelle di assicurarsi di avere assegnato correttamente i permessi al file, di usare un ‘key caching daemon’ e considerare se in effetti io abbia veramente bisogno di questo processo automatizzato a fronte del potenziale rischio.

Adesso, che ho la chiave senza password configurata, ho bisogno di testare tutto il procedimento prima di metterlo in un cron job (che ha il suo piccolo insieme di problemini). Adesso quindi esco dalla sessione ssh su host_remoto e provo a dare il seguente comando:

$ rsync -avz -e "ssh -i /home/utente_locale/cron/host_locale-rsync-key" utente_remoto@host_remoto/remota/dir /locale/dir/ 

Se questo non funzionasse, tirerò via la restrizione “command” sulla chiave e riproverò. Se mi verrà richiesta la password, controllerò i permessi sul file della chiave privata (su host_locale) e su ‘authorized_keys’ (su host_remoto). Si spera che a parte questo, il tutto funzioni senza ulteriori problemi, così da non dover essere costretto ad ampliare le informazioni di ’troubleshooting’ riportate qui.

L’ultimo passo è lo script del cron. Io ne uso uno simile a questo: Quando sarò riuscito ad eseguire senza errori lo script, userò ‘crontab -e’ per inserire una riga per questo nuovo cron job:

0 5 * * * /home/utente_locale/cron/rsync-host_remoto-backups

per un sync giornaliero alle 5 del mattino, oppure

0 5 * * 5 /home/utente_locale/cron/rsync-host_remoto-backups

per un backup settimanale (tutti i venerdì alle 5 del mattino).

Le sicronizzazioni mensili o addirittura annuali sono molto più rare per quello che mi riguarda, così date un’occhiata a ‘man crontab’ per informazioni su questo punto.Molto bene! Il mio lavoro è fatto.
Buon divertimento!