Connexion SSH
Outil keychain
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 |grep222tcp000.0.0.0:2220.0.0.0:*               LISTEN     
tcp600:::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 remove1>/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.3chmod 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 : 
		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 :RSA : Rivest-Shamir-AdlemanDSA : Digital Signature Algorithm 
		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.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.
		 | 
				|  | 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 inwhich to save the key (/home/user_a/.ssh/id_dsa): 
Created directory'/home/user_a/.ssh'.
Enter passphrase (emptyforno passphrase): doit être robuste
Enter same passphrase again: 
Your identification has been savedin/home/user_a/.ssh/id_dsa.
Your public key has been savedin/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 -p222user_b@ip_machineB"cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys"ssh -p222user_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 222user_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
Port222Protocol2SendEnv 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 -P222-F /home/user_a/.ssh/ssh_config /home/user_a/.ssh/id_dsa.pub user_b@ip_machineB:~/.ssh
ssh -p222-F /home/user_a/.ssh/ssh_config user_b@ip_machineB"cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys"ssh -p222-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 pid29993
 | 
| 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_PROFILecho"/usr/bin/keychain ~/.ssh/id_dsa">>$MON_PROFILecho"source ~/.keychain/$HOSTNAME-sh >/dev/null">>$MON_PROFILexit
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)&&exit1
 | 
|  | 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=222SSH_PORT_C=222ssh -A -p$SSH_PORT_Buser_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>>$LOGREMOTE_SSH="-e ssh"OPTIONS="-avrz --stats --force --delete-excluded"functionpls_wait(){localcount=$1localtotal=$2localprogress=$(((100*$count/$total)))localchar="\x08\x08"[[$progress-lt10]]&&char="\x08"echo -ne"$char$progress%$char"}STARTED=$(date"+%s")TIMEOUT=300SLEEP_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:;doother_rsync_running=$(ps -ef|grep rsync|grep -v grep)
    [[ -z$other_rsync_running]]&&echo -e"\nno other rsync running: Ok"&&breakCURRENT=$(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&&\
	exit1pls_wait$RUNNING_SINCE$TIMEOUTsleep$SLEEP_FREQdoneKEYCHAIN_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)&&exit1echo"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$LOGwait
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/bashPATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin5023* * * 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 hornetbzz. 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.