Mise en place d'un serveur SSH
Configuration du client SSH
La configuration des clients ssh dépend bien sur de la configuration du serveur. Si vous avez opté pour une authentification par mot de passe ( section a) de l'étape précedante), la configuration du client se limite à la création d'une paire de clés.
Dans le cas ou vous souhaitez mettre en place une authentification par clé publique quelques manipulations supplémentaires seront necessaires.
| Note: | |
Le client ssh est fourni avec le paquetage OpenSSH, chaque client devra donc installer le meme paquetage que le serveur. |
Client pour authentification par mot de passe
Il nous faut tout simplement créer notre paire de clé grâce au programme ssh-keygen:
luser@localhost $ cd ~/.ssh
luser@localhost $ ssh-keygen -t dsa -b 1024 -f id_dsa
Generating public/private dsa key pair.
Enter passphrase (empty for no passphrase): (Pas de mot de passe)
Enter same passphrase again: (Pas de mot de passe)
Your identification has been saved in id_dsa.
Your public key has been saved in id_dsa.pub.
The key fingerprint is:
6a:98:70:33:b0:61:02:0c:eb:2d:d5:a6:c8:4c:24:23 tito@prism
Vous pouvez également génerer une paire de clé de type RSA2 :
luser@localhost $ ssh-keygen -t rsa -b 1024 -f id_rsa
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): (Pas de mot de passe)
Enter same passphrase again: (Pas de mot de passe)
Your identification has been saved in id_rsa.
Your public key has been saved in id_rsa.pub.
The key fingerprint is:
b5:b6:b7:1e:8d:b8:92:c7:ad:fc:8f:6e:c3:ff:37:0c tito@prism
Notez que nous somme dans les exemples ci-dessus dans le répertoire ~/.ssh, veillez à bien copier les différentes clés générées dedans si vous n'avez pas exécuté ssh-keygen depuis ce répertoire.
Voilà, il ne vous reste plus qu'à vous connecter au serveur comme suit grâce au programme ssh:
luser@localhost $ ssh tito@shao
The authenticity of host 'shao (192.168.0.112)' can't be established.
RSA key fingerprint is 33:93:84:34:59:8f:2a:d6:4a:fb:51:27:12:36:53:ac.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'shao,192.168.0.112' (RSA) to the list of known hosts.
tito@shao's password: votre mot de passe
Last login: Thu May 6 15:41:29 2004 from 192.168.0.42
Linux Shao 2.4.24 #1 Wed Feb 11 01:01:56 CET 2004 i686 GNU/Linux
luser@localhost $
| Note: | |
C'est seulement lors de la première connexion que l'on nous demande de répondre par yes ou par no de façon à ajouter la clé publique du serveur dans notre fichier ~/.ssh/known_hosts. Si le serveur venait à changer de clé, le programme ssh refusera de s'y connecter en vous signalent que la correspondance machine/clé n'est plus valable pour le serveur en question. Il vous suffit alors d'éditer à la main votre fichier ~/.ssh/known_hosts et de supprimer l'entrée concernant le serveur. Reiterer alors votre demande de connexion, vous devriez obtenir le même comportement que lors d'une nouvelle connexion. |
5.2 Authentification par clé publique
Pour ce type d'authentification la première étape est la même, nous devons générer une paire de clé de type rsa,dsa ou bien les deux.
luser@localhost $ ssh-keygen -t dsa -b 1024 -f id_dsa
luser@localhost $ ssh-keygen -t rsa -b 1024 -f id_rsa
Puis placez les bonnes permissions sur les clés :
luser@localhost $ chmod 600 id_dsa.pub id_dsa
luser@localhost $ chmod 600 id_rsa.pub id_dsa
L'avantage de cette methode est qu'elle permet une connexion sécurisée avec un serveur distant sans demande de mot de passe, ainsi il vous est possible d'écire des scripts (ou des programmes) profitant de cela pour se connecter automatiquement à un serveur afin d'effectuer divers opérations. Il s'agit d'un mode de connexion non interactif.
Une fois les clés générées, il vous faut les placer dans votre répertoire personel sur le serveur. Vous pouvez faire ce transfert soit grâce à un media comme le CD ROM ou la disquette ou bien utiliser le protocole FTP, ou encore demander à un administrateur de le faire pour vous. Une fois votre clé copiée sur le serveur au bon endroit créez le fichier authorized_keys comme suit :
luser@localhost $ cat id_dsa.pub >> authorized_keys
Puis donnez les permissions correctes à ce fichier :
luser@localhost $ chmod 400 authorized_keys
| Note: | |
Votre répertoire personel sur le serveur doit au plus avoir comme permission 755, sinon l'authentification par clé ne fonctionnera pas ! |
Et voilà ! Il ne vous reste plus qu'à vous connecter et si toute votre configuration s'est bien passée vous devriez vous connecter directement, sans demande de mot de passe.
| Note: | |
Si vous avez modifié le fichier de configurartion /etc/ssh/sshd, pensez à redémarer le serveur sshd : |
root@localhost # /etc/init.d/sshd restart
ou
root@localhost # killall sshd && sshd
ou
root@localhost # killall -HUP sshd
Un peu plus de sécurité sur notre clé privée
Imaginez le cas desastrueux où quelqu'un arrive à prendre possession de votre login et mot de passe. Cette personne pourra alors utiliser votre paire de clés pour se connecter au serveur distant et donc de causer des dommage sur votre machine ansi que sur vos données distantes. Pour limiter les dégats il est préferable d'utiliser un mot de passe supplémentaire pour l'utilisation de votre clé privé. Ceci est fait soit en spécifiant un mot de passe lors de la génération des clé, soit en utilisant ssh-keygen pour placer un mot de passe sur une clé existante :
root@localhost # ssh-keygen -p -f id_dsa
Ceci nous permet effectivement d'améliorer la sécurité de notre clé privée mais nous fait perdre un avantage considérable de l'authentificatin par clé : à présent à chaque tentative de connexion nous serons obligé de saisir le mot de passe de notre clé privée pour pouvoire l'utiliser et ainsi décrypter le traffic.
L'authentification est donc de nouveau interactive et empeche l'automatisation de taches distantes.
Pour pallier à cela nous devons utiliser les programmes ssh-agent/ssh-add dont voici le principe. Premièrement il faut se débrouiller pour que le processus ssh-agent soit le père de notre environnement de travail.
Si vous travaillez en mode texte lancez le programme ci-dessous dans votre session courrante :
luser@localhost $ ssh-agent /bin/bash
Si vous voulez utiliser le mode graphique lancez le comme suit :
luser@localhost $ ssh-agent startx
Ensuite il faut ajouter votre paire de clés au trousseau pris en charge par ssh-agent :
luser@localhost $ ssh-add
Enter passphrase for /home/tito/.ssh/id_dsa: Entrez votre mot de passe
Identity added: /home/tito/.ssh/id_dsa (/home/tito/.ssh/id_dsa)
Une fois que vous avez saisi le mot de passe correct demandé par ssh-add, vous pourrez utiliser votre clé privé sans mot de passe pour vous connecter au serveur.
Un petit exemple
Voici un petit exemple qui permet de lister le contenu de répertoires distants en tirant partie de l'authentification automatisée. Pour l'exemple on prendra un type d'authentification par clé publique avec utilisation d'un mot de passe sur la clé privée.
| Note: | |
Remplacez tito par votre nom de login et shao par le nom ou l'adresse IP de votre serveur. |
Premièrement créons un répertoire qui contiendra nos scripts et éditons notre fichier :
luser@localhost $ mkdir SSH_COMMANDS
luser@localhost $ cd SSH_COMMANDS/
luser@localhost $ vi ls_shao.sh
Placez y le script suivant :
#!/bin/bash
ssh shao "ls $1"
Donnez les droits d'execution
luser@localhost $ chmod +x ls_shao.sh
Ajoutez à votre PATH le chemin vers le répertoire SSH_COMMANDS :
luser@localhost $ vi .bashrc
export PATH=$PATH:/home/luser/SSH_COMMANDS
Lancez un nouveau shell ayant ssh-agent comme père :
luser@localhost $ ssh-agent bash
Ajoutez votre clé privée au trousseau
luser@localhost $ ssh-add
Enter passphrase for /home/tito/.ssh/id_dsa:
Identity added: /home/tito/.ssh/id_dsa (/home/tito/.ssh/id_dsa)
Testons notre programme sur notre répertoire personnel du serveur:
luser@localhost $ ls_shao.sh
DFBtk
Linux popo
NAMED
VPN
dfbguitk.tar.gz
icons.tar.bz2
korlaz
test
Juste pour vérifiez essayons de lister le contenu du répertoire DFBtk:
luser@localhost $ ls_shao.sh DFBtk
CVS
cleansource
working