rsync ssh

par julien - dec. 2005

Peutite problématique à la base de ce hack: au cours de ma formidable vie d'étudiant, j'ai l'occasion de travailler et sur mon portable et sur ma tour. Jusque là, rien de formidable… sauf que j'ai la même arboressence de répertoire sur les deux machines et que c'est une galére sans nom pour tenir ca propre !!!

Donc, aprés moultes reports, je me suis décidé à mettre en place une synchro avec rsync par dessus ssh. Pour celà, plusieurs étapes: 1.configurer l'ouverture de session ssh par clé publique rsa 2.configurer rsync sur les répertoires 3.synchroniser 2 sources vers 1 destination 4.admirer le boulot en buvant une biére ;

C'est parti !!!

Les paires de clés RSA, c'est un peu comme un seconde nature chez moi. J'adore ça ! j'en fout partout dés que j'ai une petite place. Dans le cas présent, c'est bien pratique mais attention a la config client/serveur.

Pour que l'ordinateur client puisse se connecter a un serveur par cette methode, il a besoin d'une paire de cle RSA. La cle publique doit etre connue du serveur et la cle privee doit evidemment rester sur le client. La premiere etape est donc de generer cette fameuse paire de cles :

switcher@zerhuel:~$ ssh-keygen -t rsa

Generating public/private rsa key pair.
Enter file in which to save the key(/home/switcher/.ssh/id_rsa):
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been save in /home/switcher/.ssh/id_rsa.
Your public key has been save in /home/switcher/.ssh/id_rsa.pub.
The key fingerprint is:
41:9a:23[.......]:4f switcher@zerhuel.linuxwall.info

Pour le chemin, celui du home est bien (enfin c'est pas trés grave…). Pensez a laissez le champ de mot de passe vierge, il serais dommage de créer des scripts qui attendent un mot de passe de l'entrée standard à chaque exécution !

Maintenant que nous avons notre paire de clés, il faut configurer le client ssh pour lui dire où les trouver.

$ cat /etc/ssh/ssh_config |grep -v '#'
Host *
PasswordAuthentication yes
IdentityFile ~/.ssh/id_rsa
Protocol 2

Rien de sorcier, on dit juste que les régles suivantes s'appliquent à tous les clients, que l'on autorise l'accès pas password et que pour l'accès par clés rsa, la clé privée se trouve au chemin ~/.ssh/id_rsa. Enfin, on précise qu'on ne veux que sshv2 (la v1 est une passoire).

Bon, une derniere chose a faire est d'exporter la clé publique du client au serveur. On commence donc par créer un dossier et ensuite on envoie la clé dans le fichier “authorized_keys”

$ssh <serveur> "mkdir .ssh; chmod 700 .ssh"
$scp .ssh/id_rsa.pub <serveur>:.ssh/authorized_keys

Maintenant, le client peut s'authentifier aupres du serveur en utilisant ses cles RSA. Il faut toutefois configurer le serveur pour qu'il accepte ce mode d'authentification.

Ici c'est pas trés compliqué, tout se fait dans sshd_config

# cat sshd_config	
Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility DAEMON
LogLevel VERBOSE
LoginGraceTime 600	
#pas d'accès root c'est plus "secure"
PermitRootLogin no	
#indispensable pour auth par clé (voir le man)
StrictModes no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
#les rhosts c'est plein de failles, demandez a mitnick ;)
IgnoreRhosts yes
#le mec qui veut faire de la secu et qui met YES ici se prend
#une baffe !!!
PermitEmptyPasswords no
#auth par challenge est plus secu que l'auth classique
ChallengeResponseAuthentication yes
PasswordAuthentication no
#pas de X11 sur un serveur...
X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
KeepAlive yes
#divers
Banner /etc/issue.net
Subsystem       sftp    /usr/lib/sftp-server
UsePAM yes

Ba voilà, c'est tout :p Reste plus qu'a relancer le serveur (via init.d) et a tester depuis le client avec “ssh <serveur>” et normalement ca roule. Et pour faignantiser un peu plus, rajoutez un alias dans .bashrc ;)

Rsync est un formidable et vénérable outil de sauvegarde bien connu mais trop peu utilisé du grand public. Nous allons ici l'utiliser avec SSH pour sauvegarder le contenu de zerhuel sur <serveur>. En fait, c'est tout simple:

$rsync -av -e "ssh -p <port>" /home/switcher/Cours \
<serveur>:/priv/

En détail, ca donne:

-a pour le mode “archive”

-v est, comme dab', dédié a la verbosité (parle mon petit, parle)

-e appel un remote shell, ici ssh

“ssh -p <port>” ⇒ je n'utilise pas le port par défaut… et vous ?

/home/switcher/Cours est le chemin de la source. Si vous mettez un / aprés le dernier dossier, il ne crééra pas le dossier Cours mais juste son contenu

<serveur>:/priv/ est la destination. /priv existe sur mon serveur, c'est une partition dédié a la synchro de mes fichiers. Mettez ce que vous voulez tant que le user sur la machine source a les droits pour écrire dans le répertoire cible.

On lance. Rsync liste tous les fichiers à synchroniser avec leur taille. Une fois la synchro terminée, vous devez avoir exactement la même chose dans la source que dans la destination.

Pour vérifier si la synchro marche quand vous modifiez des fichiers dans la source, aller dans un répertoire lancez:

switcher@zerhuel:~/Cours/BTS/oraux$ touch *

Cette commande vas juste “toucher” les fichiers, donc en changer la date de dernier accès. Relancez ensuite la commande rsync avec un '/' a la fin de Cours et tous les fichiers “touchés” sont resynchronisés sur le serveur ! Ca arrache hein ? :)

Maintenant pour synchroniser facilement, on vas créer un alias dans ~/.bashrc comme suis:

$vim ~/.bashrc
[.....blablabla.....]
alias <NOM_COMMANDE>='<COMMANDE RSYNC>'

<NOM_COMMANDE> est la commande que vous taperez dans le shell. Chez moi, j'ai mis “sachielsync” (nom du srv et sync pour la synchro) <COMMANDE RSYNC> est la commande que vous avez tapé en shell pour les synchro précédente.

L'idée initiale c'est bien que je puisse travailler sur mon portable et sur mon fixe tout en conservant le contenu des répertoires sur les deux machines identique.

Pour celà, il faut soulever certaines problématiques. Rsync travaille en observant les dates de modifications des fichiers. Par défault, il ne prend pas les fichiers les plus récent, il synchronise automatiquement le fichier source dont la date de modif est DIFFERENTE du fichier dest. Ainsi, si vous modifiez rene.txt sur la machine A (vous ne synchronisez pas encore) puis vous modifiez rene.txt sur la machine B un peu plus tard. Cette fois, vous synchronisez. rene.txt sur le serveur est donc la version de la machine B. Maintenant, vous vous rendez compte que vous avez oublié de synchro la machine A, donc vous lancez rsync qui constate que la date de modif de rene.txt sur A n'est pas la meme que sur le serveur. Donc il le synchronise…. et écrase la version plus récente qui venait de la machine B !!!

Pour celà, on vas intégrer le commutateur '-u' dans nos commandes rsync. Ce dernier vas s'assurer que seuls les fichiers sources ayant une date de modif PLUS RECENTE que les fichiers de dest. sont synchronisés.

Bon, ça c'est fait ! Mais il faut bien garder le problème des date en mémoire… si vous voulez que votre système soit intégre, il faut que vous lanciez rsync JUSTE APRES UNE SESSION DE BOULOT !!! Sinon, vous allez oublier, faire des modifs un peu partout et ça va partir en vrille à chaque synchro….

Je vous laisse mettre de l'ordre dans vos synchro, l'idéal pour éviter les ennuis lors de la premiére synchro est de tout avoir sur une machine et de tout importer sur une autre…

Nous avons vu comment synchroniser avec un alias (auquel nous rajoutons -u pour gérer les dates). Maintenant, nous allons faire l'inverse, c'est à dire synchroniser les machines depuis le serveur. Pour celà, c'est tout simple:

$rsync -auv -e "ssh -p <port>" <serveur>:/priv/ \
/home/switcher/

Mettez le tout dans un alias. Comme nommage j'ai choisi l'inverse du précédent, c'est à dire 'syncsachiel'.

Bien voilà, c'est finit !! :D Lancez vos synchro⇒ une fois 'sachielsync' sur chaque machine puis une fois 'syncsachiel' sur chaque machine. Pour la biére, je conseille une pelforth brune ou une grimbergen double! Au choix ;)

Normalement, si vous avez bien travaillé, quand vous lancerez sachielsync & syncsachiel plusieurs fois sur les deux machines, il ne fera rien car les répertoires sont synchrones sur les 3 entités…

ENJOY ! ~~DISCUSSION~~