Outil keychain
Connexion SSH persistante
Date de publication : 22/05/2011. Date de mise à jour : 31/05/2011.
Par
Philippe Beaucart
L'objectif de cet article est de mettre en œuvre un outil (keychain) permettant de s'affranchir de la saisie manuelle de mots de passe lors de la connexion sécurisée distante depuis un client Linux vers un serveur Linux (ssh), tout en conservant la sécurité apportée par l'échange de clés chiffrées. Le seul cas de réinitialisation avec keychain est le redémarrage de la machine cliente (un cas plutôt rare sur une machine physique Linux).
Le prérequis est donc de disposer de deux machines Linux, physiques ou virtuelles, dont l'une est configurée avec un serveur SSH et l'autre disposant du client SSH.
I. Introduction
II. Prérequis
II-A. Installer les paquets nécessaires
II-B. Configurer votre client et serveur SSH
II-B-1. Changer le port d'écoute du serveur SSH
II-B-2. Utiliser le protocole SSH version 2
II-B-3. Interdire la connexion SSH en tant qu'utilisateur root
II-B-4. Autres recommandations de sécurité
III. Installer et configurer le chainage des clés
III-A. Générer un jeu de clés publique et privée
III-B. Autoriser la clé publique de A sur le serveur B
III-C. Vérifier et tester la connexion SSH
III-D. Automatiser le processus de connexion par session
III-E. Une connectivité plus « permanente »
III-E-1. Pour la ligne de commande
III-E-2. Pour vos scripts bash
III-F. Connexions chainées avec les machines A, B, C
IV. Exemple d'utilisation : sauvegarde distante
IV-A. Configuration
IV-B. Script de sauvegarde (rsync)
IV-B-1. Créez le script de sauvegarde
IV-B-2. Automatiser le lancement du script
V. Résumé
VI. Documentation
VI-A. Algorithmes et clés de chiffrement
VI-B. Installer un serveur SSH
VI-C. Aspects sécuritaires
I. Introduction
Ce guide ou « cookbook » est orienté pour des distributions de type Debian (dont Ubuntu fait
partie), sachant que le principe reste identique sur d'autres distributions Linux. La connexion SSH
de chacune des deux machines doit être préalablement configurée et fonctionnelle.
La connexion d'un client SSH vers un serveur SSH est fonction (d'au moins) 3 paramètres principaux :
-
l'utilisateur distant,
-
l'adresse de la machine distante,
-
le port utilisé pour la connexion.
On appellera « machine A » ou « client » la machine cliente depuis laquelle on cherchera
à se connecter sur le serveur SSH de la « machine B ». Les utilisateurs de chaque machine
seront nommés respectivement user_a et user_b.
|
Un tutoriel spécifique à la mise en place d'une connexion SSH se trouve ici
|
L'installation du chainage de clés par keychain permettra à l'utilisateur user_a de la
machine cliente « machine A » de se connecter sur la « machine B » en tant que
user_b sans entrer de mot de passe ou de passphrase.
L'intérêt principal est d'éviter d'entrer un mot de passe ou une passphrase à chaque
connexion SSH mais seulement une fois, lors du lancement de votre « machine A », et pas
du tout pour vos shells en tâches de fond :
Une application possible est de pouvoir utiliser les ressources du serveur SSH au travers de script shell.
Par exemple, les scripts de sauvegarde (avec les commandes scp ou rsync utilisant elles-même le protocole
SSH) d'une « machine A » vers une « machine B » pourront alors être lancés en
tâche de fond (cronjob) sans avoir à se soucier de quoi que ce soit. Presque le bonheur ! On
verra comment réaliser cela dans un exemple en fin de ce tutoriel.
|
Attention cependant à conserver une configuration sécurisée, notamment si vous êtes plusieurs utilisateurs
sur la même machine cliente. En particulier, l'utilisateur root ne doit jamais disposer de
ce mode de connexion « automatisée ».
|
|
Tout le tutoriel est réalisé en ligne de commande mais ces manipulations sont également possibles en
mode graphique.
|
II. Prérequis
L'utilisateur root est requis pour la plupart des installations ci-dessous, même si je n'évoque
ou n'explicite pas l'utilisation de « sudo », à envisager dans le cas des
distributions Ubuntu. Les utilisateurs user_a et user_b devront exister sur
chacune des deux machines, disposer de leur répertoire HOME (man adduser) respectif, et idéalement
être autorisés à exécuter du script bash (vous pouvez vérifier que c'est le cas dans /etc/passwd).
Exemple sur la machine A |
sudo adduser user_a
cat /etc/passwd
user_a:x:1003 :1003 :,,,:/home/user_a:/bin/bash
|
II-A. Installer les paquets nécessaires
Machine A : ligne de commande en tant que root |
aptitude install ssh openssh-client keychain
|
Machine B : ligne de commande en tant que root |
aptitude install ssh openssh-server
|
|
- S'il s'agit d'une réinstallation, pensez bien à stopper tous les processus SSH et « purger »
l'installation existante avant de procéder à la réinstallation,
- aptitude a disparu des installations standards depuis la version ubuntu 10.10.
Il faut donc l'installer si vous êtes dans ce cas (avec sudo apt-get pour les "ubuntistes")
|
II-B. Configurer votre client et serveur SSH
Le but ici n'est pas tant de vous expliquer le détail de la configuration d'un client et d'un serveur
SSH que d'attirer votre attention sur quelques aspects minimalistes de sécurité nécessaires et préalables
aux exemples et explications qui suivront.
Les fichiers de configuration concernés :
Machine A : fichier de configuration côté client SSH |
|
Machine B : fichier de configuration côté serveur SSH |
|
|
Le chemin peut différer quelque peu selon votre distribution. Une petite recherche en ligne de commande
(find /etc -type f -name ssh*_) vous orientera sur le chemin de ces fichiers.
|
II-B-1. Changer le port d'écoute du serveur SSH
|
Il est vivement recommandé de changer le port d'échange SSH tant les tentatives de connexion sur le port
SSH standard sont fréquentes par les hackeurs du dimanche : pas bien violent mais énervant,
et potentiellement destructeur. Ceci est d'autant plus applicable si vous n'avez pas un pare-feu
robuste, voire pas de pare-feu du tout (hormis celui de la box de votre FAI par exemple). Auquel
cas vous devriez envisager au minimum l'installation et la configuration de iptables et
fail2ban, ou similaires selon votre distribution.
|
Pour les exemples et explications ci-dessous, nous utiliserons donc le port d'écoute 222 au lieu du port
SSH par défaut 22 (mais choisissez de préférence un autre port -parmi les ports valides et disponibles
- pour votre propre configuration tant cette « variante » est souvent utilisée) :
machine B : vim /etc/ssh/sshd_config |
|
|
Editeur :
La modification est à effectuer en étant connecté en root. J'utilise ici vim comme
éditeur de texte en ligne de commande (dans un terminal) mais vi, nano ou même gedit
(en mode graphique) font tout aussi bien l'affaire selon vos habitudes ou préférences.
|
|
Autres ports utilisables :
Vous ne pouvez pas choisir n'importe quel port en alternative au port 22. Contrôlez les ports réservés (cat/etc/services)
ou ceux déjà utilisés avec netstat -tulp sur votre machine.
|
II-B-2. Utiliser le protocole SSH version 2
Vous verrez encore la possibilité d'utiliser le protocole SSH en version 1 dans vos fichiers de configuration du serveur
SSH pour des raisons de compatibilité ascendantes, mais il est vivement recommandé de ne plus utiliser
ce protocole au profit du seul protocole SSH en version 2, car il a des défauts de conception qui facilite le crack de mots de passe. Pour les curieux (-ses), les différences entre les
deux protocoles sont décrites
ici.
machine B : vim /etc/ssh/sshd_config |
|
II-B-3. Interdire la connexion SSH en tant qu'utilisateur root
Comme bien décrit dans
ce
tutoriel que je me permets de répéter quasiment mot pour mot pour l'occasion :
« Les scripts automatisés (notamment) qui tentent que se connecter par SSH sur vos serveurs utilisent
principalement les logins couramment utilisés dont [l'utilisateur] root fait bien sûr partie. Le
fait de laisser l'accès à [l'utilisateur] root par [une connexion] SSH fait gagner une étape à
un pirate qui souhaite s'introduire dans votre système. En effet, le fait de bloquer l'accès à
[l'utilisateur] root entraîne la nécessité à un pirate de trouver un nom d'utilisateur autre, existant
sur votre système. Sans cela, le pirate dispose donc du nom d'utilisateur, il ne lui reste plus
qu'à trouver le mot de passe de [l'utilisateur] root pour s'introduire [par effraction dans votre
système]. »
machine B : vim /etc/ssh/sshd_config |
|
|
N'oubliez pas de relancer le daemon (en français : démon, ou « service ») ssh afin que
ces modifications soient prises en compte.
|
machine B : relancer le daemon ssh en tant que root |
/etc/init.d/ssh stop
/etc/init.d/ssh start
|
Vérifions que le port d'écoute est bien actif en ipv4 (et en ipv6 si actif)
machine B : vérifier le port d'écoute SSH |
netstat -na | grep 222
tcp 0 0 0 .0 .0 .0 :222 0 .0 .0 .0 :* LISTEN
tcp6 0 0 :::222 :::* LISTEN
|
II-B-4. Autres recommandations de sécurité
Cela peut paraître évident, mais il est inutile d'utiliser une connexion sécurisée en SSH si vous avez
des trous béants de sécurité par ailleurs : il s'agit donc de s'assurer que ces failles éventuelles
disparaissent de votre configuration, présentes par défaut sur une Debian.
Nous supposerons que nmap n'est pas installé et nous supprimerons les services telnet, portmap et inetd, et nous interdirons l'accès au compilateur
éventuel (gcc), aux installateurs (apt-get, aptitude et dpkg) à tout autre utilisateur que root
par un petit script shell :
Machine B : connecté en root dans un terminal, exécutez ce script |
echo -n " Removing and shutting down unsecure services : "
[[ $ (dpkg -l | grep portmap | cut -d" " -f1) = " ii " ]] & & aptitude remove portmap & & update-rc.d -f portmap remove
update-rc.d -f inetd remove 1 > /dev/null
[[ $ (dpkg -l | grep ppp | cut -d" " -f1) = " ii " ]] & & aptitude remove ppp
[[ $ (dpkg -l | grep telnet | cut -d" " -f1) = " ii " ]] & & aptitude remove telnet
echo " done "
echo -n " Removing compile and install rights to others : "
chmod o-x /usr/bin/gcc-4 .3
chmod o-x /usr/bin/make
chmod o-x /usr/bin/apt-get
chmod o-x /usr/bin/aptitude
chmod o-x /usr/bin/dpkg
echo " done "
|
|
-
portmap est utilisé notamment pour les services RPC (Remote Procedure Call) à bannir sur un serveur sécurisé.
Ce qui sous-entend aussi que vous n'avez pas installé d'interface graphique (Gnome). Si ce n'est pas le cas, ou que vous avez besoin de ce service,
il reste cependant possible de le conserver et de gérer l'aspect sécurité au travers du reglage de votre parefeu (iptables),
-
ppp est le service du protocole "Point to Point Protocol" à bannir sur un serveur sécurisé,
-
telnet est l'ancêtre peu sécurisé de SSH,
-
inetd (Internet Super Server) est l'ancêtre peu sécurisé de Xinetd, un démon Unix qui permet de gérer les connexions à des services réseau.
|
|
Insérer ce bout de script dans votre script principal de mise en production d'un serveur peut s'avérer
utile. Bien sûr, n'oubliez pas de rendre le script lisible et exécutable uniquement pour l'utilisateur
root ou votre compte administrateur.
|
|
Ces quelques recommandations sont nécessaires mais loin d'être suffisantes pour sécuriser un serveur.
Entre autres, il convient de rappeler trois actions indispensables :
- Vérifier la robustesse des mots de passe
(cf la note sur john the ripper) et les changer régulièrement,
- Mettre régulièrement son systeme à jour
(aptitude update et aptitude safe-upgrade) en ayant bien sûr référencé les dépôts (http://security.debian.org/) dans votre liste de sources,
- Protéger son systeme, et notamment regler correctement son parefeu : limiter l'accès aux ports strictement nécessaires et "drop" de l'icmp
Pour les distributions debian, voir également ces recommandations supplémentaires.
Enfin, pour clore ce point, une bonne action complémentaire peut être d'installer et configurer fail2ban en combinaison avec votre parefeu et votre serveur.
|
III. Installer et configurer le chainage des clés
Bon, on y est maintenant. Comme évoqué, le chainage des clés par keychain permettra une connexion
SSH sans entrer de mot de passe (passphrase), sauf en cas de redémarrage de la
machine cliente.
III-A. Générer un jeu de clés publique et privée
On utilisera ssh-keygen afin de générer un jeu de clés sur la machine cliente, qui pourra ainsi
échanger sa clé publique avec la machine serveur et être autorisée à se connecter sur celle-ci.
|
Deux algorithmes de chiffrement sont disponibles avec l'outil que nous utiliserons :
- RSA : Rivest-Shamir-Adleman
- DSA : Digital Signature Algorithm
A taille identique de clés, la difficulté pour casser les clés est la même pour les deux algorithmes.
Il y a deux différences principales entre ces algorithmes :
- l'algorithme DSA n'assure que la signature alors que RSA réalise à la fois la signature et le
chiffrement (souvent réalisé par négligence ou simplification dans un fichier unique), ce qui peut
être interprété comme une faiblesse, car le protocole SSH n'utilise la clé que pour la signature.
Or il est préférable de limiter la quantité d'informations concentrée dans un fichier, notamment
s'il est chiffré. On peut considérer cela comme un avantage au chiffrement DSA.
- La taille de clé de l'algorithme DSA est figée à 1024 bits alors que RSA permet un chiffrement
par défaut à 2048 bits (sauf si l'argument -b de la commande ssh-keygen est précisé
avec une autre valeur - de 768 à 4096 bits). On pourrait considérer cela comme un avantage au chiffrement
RSA.
En conclusion, les différences sont minces et le choix est donc dans l'épaisseur du trait. Il doit
plutôt porter sur la taille de la clé servant à la signature. 1024 bits sont a priori suffisants,
donc nous utiliserons ici la clé DSA. Utilisez l'algorithme RSA si vous souhaitez chiffrer sur 2048
ou 4096 bits.
|
|
On quitte l'utilisateur root (ou les commandes sudo de votre compte administrateur) et
on se connecte avec le compte de l'utilisateur user_a de la machine cliente.
|
|
Pour la passphrase :
- définissez et notez votre passphrase à ce stade,
- il est recommandé de tester la robustesse de votre passphrase avec l'utilitaire
John the ripper (cf exemple ci-dessous),
- il faut toujours entrer une passphrase même si ssh-keygen permet de ne pas le faire,
- la robustesse de la passphrase est testée par ssh-keygen. Vérifiez de
ne pas avoir reçu de message d'erreur (et donc que la clé ait bien été générée).
|
Machine A : tester la robustesse des mots de passe |
aptitude install john
john /etc/shadow
|
Machine A : connecté en tant que user_a dans un terminal |
su user_a
cd ~
ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/user_a/.ssh/id_dsa):
Created directory ' /home/user_a/.ssh ' .
Enter passphrase (empty for no passphrase): doit être robuste
Enter same passphrase again:
Your identification has been saved in /home/user_a/.ssh/id_dsa.
Your public key has been saved in /home/user_a/.ssh/id_dsa.pub.
The key fingerprint is:
54 :3e:fc:3d:bd:b3:55 :bb:2e:ed:78 :ed:4c:b3:6c:6e user_a@machineA
The key' s randomart image is:
+--[ DSA 1024]----+
| . |
| + |
| . + |
| . o . . |
| S . o o|
| .+|
| .=+|
| .oEO|
| .OXo|
+-----------------+
|
|
Vérification des permissions sur le jeu de clés :
ls -lstha ./.ssh/
4,0K -rw------- 1 user_a user_a 736 2011-05-21 09:12 id_dsa_dvp
4,0K -rw-r--r-- 1 user_a user_a 612 2011-05-21 09:12 id_dsa_dvp.pub
Ce qui signifie :
- accès à la clé privée en lecture/écriture uniquement pour l'utilisateur user_a (chmod
600)
- accès à la clé publique en lecture/écriture pour l'utilisateur user_a et en lecture seule
pour les autres (chmod 644)
|
|
Vous pouvez changer a posteriori la passphrase en utilisant l'option -p comme suit :
ssh-keygen -p
A noter que vous devrez effectuer à nouveau les étapes qui suivent si vous opérez le changement
de passphrase et que vous souhaitez automatiser la connexion.
|
III-B. Autoriser la clé publique de A sur le serveur B
A ce stade, on ne peut pas encore se connecter à la machine B sans entrer de passphrase.
Il faut informer le serveur que la clé publique de la machine A est autorisée pour initier une connexion
SSH.
Pour cela, il faut copier la clef publique de l'utilisateur user_a de la machine cliente dans le fichier
~/.ssh/authorized_keys de la machine B (serveur SSH) à laquelle l'utilisateur user_a voudra se connecter
depuis sa machine A via le protocole SSH. Tout s'opère donc depuis la machine cliente.
Sur les distributions de type debian, on peut utiliser la commande toute faite ssh-copy-id :
Machine A : copier la clé publique sur la machine B dans les clés autorisées |
ssh-copy-id -p222 -i ~/.ssh/id_dsa.pub user_b@ip_machine_B
|
En alternative pour les autres distributions, mais également valable pour les debian :
Machine A : copier la clé publique sur la machine B dans les clés autorisées |
scp -P 222 /home/user_a/.ssh/id_dsa.pub user_b@ip_machineB:~/.ssh
ssh -p 222 user_b@ip_machineB " cat ~ / . ssh / id_dsa . pub > > ~ / . ssh / authorized_keys "
ssh -p 222 user_b@ip_machineB " rm ~ / . ssh / id_dsa . pub "
|
Enfin, on vérifie que la clé publique de la machine A ait bien été ajoutée aux clés autorisées sur
la machine B :
Machine A : vérifier le résultat |
ssh -p 222 user_b@ip_machineB " cat ~ / . ssh / authorized_keys "
cat ~/.ssh/id_dsa.pub
|
III-C. Vérifier et tester la connexion SSH
A ce stade, on a d'ores et déjà utilisé la connexion SSH pour copier la clé publique de l'utilisateur
user_a vers la machine B. Vous avez donc pu rencontrer quelques problèmes dès cette étape, pour
lesquels on va essayer d'anticiper les solutions possibles. Sachant que la plupart du temps, ce
type de problème est lié à la configuration de votre client SSH (machine A), et dans une moindre
mesure, parfois à votre serveur SSH (machine B).
|
Pensez à utiliser le mode verbeux de la commande ssh, cela vous aidera à résoudre les problèmes éventuels
ou à poser vos questions sur les forums avec des éléments concrets : ssh -p 222 -vvv
user_b@machineB
|
|
Pensez à vérifier les points suivants :
- /home/user_a/.ssh : permission du répertoire réglé sur chmod 700
- /home/user_a/.ssh/known_hosts : chmod 644
- /home/user_a/.ssh/known_hosts: supprimer la clé publique (RSA) de la machine B
- /home/autres_users/.ssh/known_hosts : ne contient pas déjà la clé publique de la machine B
que le serveur ssh de la machine B est bien en écoute sur le port que vous adressez (ici 222) :
netstat -na | grep 222
|
Host Key verification failed
C'est vraisemblablement l'erreur la plus commune. Plusieurs raisons
peuvent causer cette erreur. Plutôt que de les évoquer de façon exhaustive, je vous propose une
solution potentielle, ou tout du moins une configuration minimaliste du client, évitant tout risque
de destruction massive : le principe est de créer une configuration client spécifique pour l'utilisateur
user_a afin d'éviter les erreurs de manipulations.
Voilà un exemple de configuration SSH cliente et de son mode d'utilisation :
Machine A : configuration SSH client |
sudo cp /etc/ssh/ssh_config /home/user_a/.ssh/ssh_config
sudo chown user_a:user_a /home/user_a/.ssh/ssh_config
su user_a
> /home/user_a/.ssh/known_hosts
vim /home/user_a/.ssh/ssh_config
Host *
CheckHostIP no
StrictHostKeyChecking no
Port 222
Protocol 2
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
|
Machine A : utilisation de la configuration spécifique de l'utilisateur user_a |
ssh -p 222 -F /home/user_a/.ssh/ssh_config user_b@ip_machineB
exit
scp -P 222 -F /home/user_a/.ssh/ssh_config /home/user_a/.ssh/id_dsa.pub user_b@ip_machineB:~/.ssh
ssh -p 222 -F /home/user_a/.ssh/ssh_config user_b@ip_machineB " cat ~ / . ssh / id_dsa . pub > > ~ / . ssh / authorized_keys "
ssh -p 222 -F /home/user_a/.ssh/ssh_config user_b@ip_machineB " rm ~ / . ssh / id_dsa . pub "
|
Autres problèmes connus :
-
oubli de recharger la configuration ssh côté serveur après avoir effectué des modifications (taper /etc/init.d/ssh
reload),
-
permissions incorrectes sur les répertoires et fichiers SSH : cela peut être le cas si vous n'avez
pas utilisé les moyens standards (ssh-copy-id par exemple). Auquel cas il faudrait rétablir
la situation telle que décrite ci-dessous :
Machine cliente « A »
(propriétaire : user_a)
|
Machine serveur SSH « B »
(propriétaire : user_b)
|
fichier
|
droits
|
fichier
|
droits
|
Clé privée
|
700
|
Répertoire /home/user_b/.ssh
|
700
|
Clé publique
|
600
|
Fichier
/home/user_b/.ssh/authorized_keys
|
600
|
known_hosts
|
644
|
Recharger config si modification /etc/init.d/ssh reload
|
-
|
III-D. Automatiser le processus de connexion par session
Afin d'éviter de ressaisir systématiquement sa passphrase à chaque connexion lors la session de
l'utilisateur user_a de la machine cliente, il faut utiliser ssh-agent, qui conservera la clef en
mémoire.
Il faudra alors informer l'agent SSH de l'existence de votre clé par la commande ssh-add. Quand on lancera
la connexion SSH, l'agent SSH communiquera la clé publique au processus SSH afin d'assurer les échanges
de clés et donc la connexion.
Le seul bémol (mais qui est aussi une gage de sécurité) est que ce processus d'automatisation est
valide uniquement pendant la durée de votre session. Nous verrons dans les étapes suivantes comment
le rendre plus permanent.
Machine A: lancer l'agent SSH |
eval $ (ssh-agent)
Agent pid 29993
|
Machine A: communiquer la clé à l'agent SSH |
ssh-add ~/.ssh/id_dsa
Enter passphrase for /home/user_a/.ssh/id_dsa: entrez votre passphrase
Identity added: /home/user_a/.ssh/id_dsa
|
C'est évident mais je préfère le rappeler : il faut entrer la même
passphrase que celle
que vous aviez pris le soin de noter lors de sa
création.
III-E. Une connectivité plus « permanente »
III-E-1. Pour la ligne de commande
Il y a deux solutions principales pour éviter de recommencer l'ajout de la clé à l'agent SSH à chaque
nouvelle ouverture de session :
-
intégrer l'agent SSH ssh-agent directement dans le profil utilisateur
-
utiliser l'outil keychain
On ne décrira pas la première solution car elle est très bien expliquée
ici.
Focalisons notre attention sur l'outil keychain disponible dans la majorité des distributions
Linux (par exemple, disponible pour Debian, Ubuntu, Gentoo, Mandriva) :
Machine A : lancer keychain à la connexion en ligne de commande |
MON_PROFIL =~/.bashrc
test -f $ MON_PROFIL & & echo " profil : ok " | | echo " Cherchez le fichier de votre profil svp ( dépend de votre distribution ) "
echo " # SSH machine A vers machine B " > > $ MON_PROFIL
echo " / usr / bin / keychain ~ / . ssh / id_dsa " > > $ MON_PROFIL
echo " source ~ / . keychain / $ HOSTNAME - sh > / dev / null " > > $ MON_PROFIL
exit
su user_a
|
|
La passphrase de la clé d'identification de la machine A et le mot de passe de l'utilisateur user_b
ne vous seront plus demandés.
La passphrase ne vous sera plus demandée que dans le cas du redémarrage de la machine A.
|
III-E-2. Pour vos scripts bash
Aussi bien pour vos scripts lancés manuellement que ceux lancés en tâche de fond (cronjobs), il faut
lancer l'agent SSH. Pour cela, il suffit d'ajouter quelques lignes en début de script (bash) :
Machine A : script bash |
KEYCHAIN_INSTALLED =$ (aptitude search keychain | egrep " ^ i " )
[[ ! -z $ KEYCHAIN_INSTALLED ]] & & [[ -f ~/.keychain/$ HOSTNAME -sh ]] & & source ~/.keychain/$ HOSTNAME -sh
[[ ! -f ~/.keychain/$ HOSTNAME -sh ]] & & (echo " Backup stopped : keychain problem " | tee -a $ LOG ) & & exit 1
|
|
Pensez à adapter la source si vous utilisez d'autres interpréteurs (csh, fish)
|
III-F. Connexions chainées avec les machines A, B, C
Une remarque s'impose sur la connexion SSH d'une machine A vers une machine C en passant par la machine
B. Dans ce cas, il faut que le couple des machines B/C soit configuré comme on l'a fait précédemment
pour le couple A/B, et utiliser l'option -A afin de transmettre l'agent SSH :
Machine A : shell |
SSH_PORT_B =222
SSH_PORT_C =222
ssh -A -p $ SSH_PORT_B user_b@ip_machineB " ssh - p $ SSH_PORT_C user_C @ ip_machineC "
|
IV. Exemple d'utilisation : sauvegarde distante
On se restreint à la sauvegarde de quelques répertoires choisi d'une machine cliente « A »
vers une machine serveur « B » en utilisant rsync. Sachant que rsync utilise
le protocole SSH, on va ainsi pouvoir écrire un petit script de sauvegarde automatique.
IV-A. Configuration
On conserve la même configuration que précédemment (machines A et B avec les utilisateurs user_a et user_b) et on installe rsync.
Machine A : installer rsync |
|
Machine B : créer un répertoire de backup pour le user_b |
|
IV-B. Script de sauvegarde (rsync)
On va distinguer deux points : le script lui-même et son automatisation.
IV-B-1. Créez le script de sauvegarde
Machine A : script shell « /etc/cron.daily/remotebackup » |
SRC =~
DEST =" user_b @ ip_machineB : ~ / backup "
EXCLUDED_DIRS =" - - exclude - from = / etc / rsync . exclude "
LOG =" / var / log / rsync . log "
DELIMITER =" - - - - - - - - - - - - - - - - - - - - - - - \n "
WHEN =$ (date " + % F % H : % M : % S " )
WHO =$ (whoami)
WHAT =$ (echo " $ 0 ( PID $ $ ) " )
echo -e $ DELIMITER $ WHEN $ WHO $ WHAT > > $ LOG
REMOTE_SSH =" - e ssh "
OPTIONS =" - avrz - - stats - - force - - delete - excluded "
function pls_wait (){
local count =$ 1
local total =$ 2
local progress =$ (((100 *$ count /$ total )))
local char =" \x08\x08 "
[[ $ progress -lt 10 ]] & & char =" \x08 "
echo -ne " $ char $ progress % $ char "
}
STARTED =$ (date " + % s " )
TIMEOUT =300
SLEEP_FREQ =$ ((TIMEOUT/10 ))
other_rsync_running =$ (ps -ef | grep rsync | grep -v grep)
[[ ! -z $ other_rsync_running ]] & & \
echo " Other rsync process ( es ) are running , - pls wait till 100 % of $ TIMEOUT sec "
while :; do
other_rsync_running =$ (ps -ef | grep rsync | grep -v grep)
[[ -z $ other_rsync_running ]] & & echo -e " \nno other rsync running : Ok " & & break
CURRENT =$ (date " + % s " )
RUNNING_SINCE =$ (( CURRENT - STARTED ))
[[ " $ RUNNING_SINCE " -ge " $ TIMEOUT " ]] & & \
echo -e " \nOther rsync ' s pid running for too long Vs TimeOut $ TIMEOUT - process aborted " | tee -a $ LOG & & \
exit 1
pls_wait $ RUNNING_SINCE $ TIMEOUT
sleep $ SLEEP_FREQ
done
KEYCHAIN_INSTALLED =$ (aptitude search keychain | egrep " ^ i " )
[[ ! -z $ KEYCHAIN_INSTALLED ]] & & [[ -f ~/.keychain/$ HOSTNAME -sh ]] & & source ~/.keychain/$ HOSTNAME -sh
[[ ! -f ~/.keychain/$ HOSTNAME -sh ]] & & (echo " Backup stopped : keychain problem " | tee -a $ LOG ) & & exit 1
echo " Running / usr / bin / rsync $ REMOTE_SSH $ OPTIONS $ EXCLUDED_DIRS $ SRC $ DEST " | tee -a $ LOG
(/usr/bin/rsync $ REMOTE_SSH $ OPTIONS $ EXCLUDED_DIRS $ SRC $ DEST > > $ LOG ) &
RET =$ (echo $? )
echo -n " Waiting for the rsync pid ' s end : " | tee -a $ LOG
wait
echo " Ok " | tee -a $ LOG
|
Et voila le fichier contenant les répertoires à exclure de la copie synchronisée. Dans notre cas de sauvegarde
du répertoire /home de l'utilisateur user_a, c'est inutile, mais il peut être intéressant
de voir comment vous pouvez exclure des sous-répertoires de votre répertoire /home, ou d'autres
répertoires, si vous étendez la portée de la sauvegarde :
Machine A : créer un fichier des répertoires à exclure de la synchronisation |
/tmp/
/proc/
/sys/
/dev/
/mnt/
/sys/
/media/
/lost+found/
/var/log/rsync.log
/etc/rsync.exclude
|
|
N'oubliez pas de rendre le script bash exécutable par l'utilisateur :
-
en notation relative:
chmod +x /etc/cron.daily/remotebackup
-
ou mieux, en notation octale absolue :
chmod 700 /etc/cron.daily/remotebackup
|
|
Évitez les noms exotiques et les extensions pour les noms de fichiers placés en tâche automatisée.
Notamment, les distributions debian n'autorisent pas les points dans les noms de fichiers placés dans /etc/cron.(d|daily|weekly|monthly).
|
Explications
On ne copie pas un répertoire local vers un autre répertoire distant (man scp), mais on lance
une copie incrémentale synchronisée (man rsync) entre le répertoire source /home
de l'utilisateur user_a de la machine A et le répertoire de destination /home/user_b/backup.
A moins d'être utilisée comme un service, la commande rsync n'a pas besoin qu'on lui spécifie
le port SSH et reprend d'elle-même la configuration (et le protocole) de SSH. On aura vérifié dans
le script, préalablement à la synchronisation, que d'autres opérations du même type (d'autres processus
rsync) ne sont pas en cours d'execution : si tel est le cas, on attend patiemment qu'elles soient
terminées pour ne pas surcharger le CPU et surtout, saturer la bande passante. Si ce délai d'attente
TIMEOUT est dépassé, on ne lance pas la synchronisation.
IV-B-2. Automatiser le lancement du script
Passez le script en tâche de fond automatisée pour l'utilisateur user_a. Par exemple, on lance une sauvegarde
tous les jours à 23h50 par exemple. Pour les distributions de type debian, l'utilisation de la
table des tâches planifiées (crontab) est un peu particulière (l'utilisation est simplifiée) :
Machine A : table des tâches du user_a |
su user_a
crontab -e
SHELL =/bin/bash
PATH =/usr/local /sbin:/usr/local /bin:/sbin:/bin:/usr/sbin:/usr/bin
50 23 * * * user_a test -x /usr/sbin/anacron | | ( cd / & & run-parts --report /etc/cron.daily )
crontab -l
|
V. Résumé
shell |
adduser user_a
adduser user_b
aptitude install ssh openssh-client keychain john
aptitude install ssh openssh-server
vim /etc/ssh/ssh_config
vim /etc/ssh/sshd_config
john /etc/shadow
ssh-keygen -t dsa
ssh-copy-id -p222 -i ~/.ssh/id_dsa.pub user_b@ip_machine_B
eval $ (ssh-agent)
ssh-add ~/.ssh/id_dsa
/usr/bin/keychain ~/.ssh/id_dsa
source ~/.keychain/$ HOSTNAME -sh > /dev/null
|
J'espère que vous aurez trouvé ce tutoriel complet, clair et utile.
Merci également aux relecteurs.
VI. Documentation
VI-A. Algorithmes et clés de chiffrement
VI-B. Installer un serveur SSH
VI-C. Aspects sécuritaires
Les sources présentées sur cette page sont libres de droits
et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation
constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright ©
2011 Philippe Beaucart. Aucune reproduction, même partielle, ne peut être
faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc.
sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à
trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.