Configuration d’une connection SSH

Objectif

L’objectif de ce tutoriel est de mettre en place une connexion SSH depuis un poste client Windows vers un poste Linux (Serveur), le tout de manière automatisée (utilisation de clef SSH).

L’architecture des exemples sera la suivante:

Sur le serveur A (Linux) sera installé OpenSSH Server, sur le client B (Windows) on utilisera Putty et sur le client C (Linux) le client OpenSSH.

Installation du Serveur

Installation du serveur OpenSSH

OpenSSH est choisi dans ce tutoriel pour sa robustesse et sa simplicité de configuration (pour une utilisation courante).

L’installation sur un serveur LINUX ne pose pas de problèmes, sous Ubuntu, installez le paquet openssh-server

Configuration du serveur

La configuration se trouve dans le fichier /etc/ssh/sshd_config

La première chose à faire pour sécuriser un peu plus est de supprimer l’authentification avec l’utilisateur root.

PermitRootLogin no

La seconde, autoriser l’authentification par clef RSA

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      %h/.ssh/authorized_keys

Dans ce modèle, les clefs autorisées seront inscrites dans le fichier ~/.ssh/authorized_keys (c’est l’emplacement par défaut, mais libre à vous de le personnaliser)

Vous avez la possibilité de restreindre la liste des utilisateurs ayant le droit de se connecter au serveur via SSH avec le paramètre suivant:

AllowUsers foo bar

Dans cet exemple, seul les utilisateurs foo et bar pourront se connecter.

Assurez-vous également que le paramètre suivant est bien sur no

PermitEmptyPasswords no

Et enfin, pour permettre l’utilisation de sshfs ou sftp, ajouter la ligne suivante:

Subsystem sftp /usr/lib/openssh/sftp-server

La configuration de la partie serveur est terminée.

Afin de permettre le forward de votre agent (avec lequel vous vous authentifiez), il faut modifier une option dans le fichier de configuration client du serveur.
Cette modification se fait donc dans le fichier suivant: /etc/ssh/ssh_config

ForwardAgent yes

Installation du Client Windows

Installation de Putty et des autres composants

Le programme Putty est un terminal multiprotocole (Telnet, RSH, SSH,…) fonctionnant sous Windows.
Il peut être directement téléchargé depuis le lien suivant:

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

Sur cette page, télécharger les exécutables suivants: PuTTY, PuTTYgen et Pageant.

Placer les exécutables où bon vous semblera (personnellement, je les place toujours dans le répertoire WINDOWS ou tout autre répertoire du %PATH% afin de pouvoir les exécuter directement).

Génération d’une paire de clés SSH

La première étape sera de générer une clef SSH. Pour cela, exécuter puttygen.exe, puis cliquer sur Generate.

Les mouvements de la souris vont générer un nombre aléatoire nécessaire pour générer la paire de clefs. Une fois terminé, vous devriez avoir une vue similaire à celle-ci

Vous pouvez mettre le ommentaire comme bon vous semble, faites en sorte qu’il soit « parlant », cela pourrait être utile si vous gérez plusieurs clef SSH sur le serveur. (mettre le nom d’utilisateur par exemple)

Il est fortement recommandé de définir un mot de passe à votre clef, car sans mot de passe, quiconque aurait accès à votre paire de clef, pourrait s’authentifier sur votre serveur sans aucune restriction.

Exporter la paire de clés (Publique et Privée) en cliquant sur Save public key et Save private key.

Attention!
La clef privée ne doit JAMAIS être transmise.

La clé privée sera sauvegardée avec l’extension .ppk quant à la clé publique, l’extension est sans importance, mais le plus souvent, c’est l’extension .pub qui est utilisée.

Pour l’exemple, les clefs seront sauvegardées sous C:\ssh

  • Clef Publique
C:\ssh\ssh_key.pub
  • Clef Privée
C:\ssh\ssh_private.ppk

Laissez cette fenêtre ouverte, vous en aurez besoin par la suite.

Configuration de l’agent SSH (pageant.exe)

Il faut ensuite mettre en place l’agent SSH afin de pouvoir s’authentifier directement avec la paire de clef précédemment générée.
Afin de déclarer automatiquement la clef dans pageant, il faut lancer ce dernier en ligne de commande. Et pour faire en sorte qu’il se lance automatiquement à chaque ouverture de session Windows, on va le placer dans le dossier Démarrage de la barre de menu.

Créer un fichier batch nommé pageant.bat contenant la ligne de commande de pageant ainsi que la/les clef(s) privéesque vous souhaitez déclarer.

@echo off
C:\WINDOWS\pageant.exe c:\ssh\ssh_private.ppk

Pour déclarer plusieurs clefs, il suffit de les mettre à la suite :

C:\WINDOWS\pageant.exe c:\ssh\ssh_private1.ppk c:\ssh\ssh_private2.ppk

Placer le fichier batch dans le répertoire C:\Documents and Settings\<votreuser>\Menu Démarrer\Programmes\démarrageDe ce fait, il sera exécuté à chaque ouverture de session.

Configuration du Serveur pour accepter la paire de clefs

Afin de pouvoir s’authentifier avec cette paire de clefs, celle-ci doit être connue du serveur.

Sur le serveur A, dans votre home, éditez le fichier .ssh/authorized_keys

$ vim ~/.ssh/authorized_keys

Insérez le contenu de la clé publique (à éditer avec votre éditeur favori) ou en recopiant directement le code qui est s’est affiché dans la fenêtre de pageant après la génération. Dans cet exemple, voici le contenu à insérer:

ssh-rsa AAAB3NzaC1yc2EAAAABJQAAAIBvPh+ZsRUbVR4Aj8kOcJ4uiCjaZmPCsF0CcdidSnPU+K6eZGwWcA0i5++kzuP9wZGIMtKUq5mLWf256lpVGsIGhIeItuO0slhqVBhOazXZ4TTOnpMm57MpXoUWUtwpNsbS4OqFtbbAyHSLxRoC48Eu1t8D0n+QDwxGe6BmaRp5w== user@ClientB

Sauvegarder le fichier et assuez-vous que les droits sont corrects.

Droits sur le répertoire et fichier .ssh et authorized_keys
  • Vous devez être propriétaire du répertoire .ssh et de son contenu.
  • Seul votre utilisateur doit avoir accès au fichier authorized_keys

Voici la commande à exécuter pour mettre en place les droits

$ chown <user>:<usergroupe> ~/.ssh
$ chmod 700 ~/.ssh
$ chown <user>:<usergroupe> ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/authorized_keys

Configuration de la connexion vers votre serveur dans PuTTY

La dernière étape consiste à paramétrer PuTTY pour accéder à votre serveur.

Sous la catégorie Session, renseignez le nom DNS (ou l’adresse IP) et sélectionner SSH comme type de connexion.
Renseigner le nom de la session dans laquelle les paramètres seront sauvegardés.

Sous la catégorie Window Behaviour pensez à mettre un titre à la fenêtre pour plus de clarité, pour cela renseigner le champ Window title

Sous la catégorie Connection Data, renseigner le nom d’utilisateur associé à la paire de clef dans le champ Auto-login username.

Sous la catégorie SSH Auth, renseigner enfin le chemin absolu vers la clef privée dans le champ Private key file for authentification et vérifier que l’option Attempt authentication using Pageant est cochée. Si vous cochez Allow agent forwarding, votre authentification via votre agent (pageant) sera transmise aux autres serveurs si vous effectuez une connexion SSH depuis le serveur A (vers un serveur B, par exemple, lequel étant configuré pour accepter la paire de clef du client B).

Revenir sous la catégorie Session puis cliquer sur le bouton Save pour sauvegarder votre connexion vers le serveur A.

Lancer une Connexion vers le serveur A

Il ne reste qu’à tester la connexion depuis le client B vers le Serveur A.
Pour cela, lancez le fichier bat afin de charger votre clef dans l’agent SSH, (si besoin renseignez votre mot de passe) puis faites un clic droit sur l’icône pageant dans le systray et dans « Saved Sessions » vous devriez retrouver votre session PuTTY sauvegardée sous le nom Serveur A.

Vous pourrez ainsi vérifier que l’authentification est faite via la clef et ne vous demandera aucun mot de passe.

Si cela ne fonctionne pas, il doit y avoir un problème. Dans ce cas, vous pouvez vérifier sur le serveur A le fichier de log de l’authentification

# tail -f /var/log/auth.log

Installation du Client Linux

L’objectif de la mise en place du client Linux est de se simplifier la vie. Combien de fois entrez vous votre mot de passe pour vous connecter sur tel ou tel serveur, pour faire du scp…
Avec cette méthode, tout ceci ne sera bientôt plus que du passé!

Génération de la paire de clefs RSA

En tout premier lieu, il faut générer une paire de clef sur le Client C. Pour ce faire, tapez la commande suivante :

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/<user>/.ssh/id_rsa):

Appuyez sur ENTER (à moins que vous ne vouliez spécifier un autre emplacement), c’est en effet l’emplacement recommandé car par défaut, le répertoire .ssh est suffisamment protégé (Cette clef est la clef privée).

Enter passphrase (empty for no passphrase):

Je vous conseille vivement d’entrer un mot de passe (une passphrase). Mais rassurez vous, vous n’aurez pas à la taper à chaque fois que vous vous connectez (sinon il n’y aurait que peu d’intérêt à utiliser un système de clefs !)

Enter same passphrase again:
Your identification has been saved in /home/<user>/id_rsa.
Your public key has been saved in /home/<user>/id_rsa.pub.
The key fingerprint is:
f3:2e:12:4b:37:67:21:6e:ea:3e:7e:2f:94:a7:74:41 <user>@ClientC
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|          E      |
|         .       |
|        . o      |
|       .So o     |
|      o Oo=      |
|     . O B.      |
|      = =.       |
|     +++ +o      |
+-----------------+

Voilà ! Vous venez de générer votre paire de clef publique / clef privée.

Autoriser la clef sur le Serveur A

Il faut à présent autoriser cette clef à se connecter sur le serveur A. Pour ce faire, recopiez le contenu de la clef publique/home/<user>/id_rsa.pub sur le Client C (ne vous trompez pas avec la clef privée !!) dans le fichier ~/.ssh/authorized_keys sur le serveur A:

$ scp /home/<user>/id_rsa.pub serveurA:~/.ssh/tmp_id_rsa.pub
$ ssh serveurA
$ cat ~/.ssh/tmp_id_rsa.pub >> ~/.ssh/authorized_keys
$ rm ~/.ssh/tmp_id_rsa.pub

A présent que le contenu de la clef publique est copié dans le fichier authorized_keys, vous pouvez vous connecter au serveur A en utilisant directement la clef.
Mais me direz vous, en quoi cela est-il plus pratique, puisque je suis quand même obligé de taper ma passphrase à chaque connexion ? Nous allons donc utiliser un « ssh-agent » !

Mise en place de l’agent SSH sur le Client Linux

Petite définition de l’agent SSH

Pour commencer, voici une petite explication de ce qu’est l’agent SSH, et pour cela rien ne vaut mieux que le « Funny Manual » (RTFM comme diraient les anciens) de ssh-agent

ssh-agent is a program to hold private keys used for public key authentication (RSA, DSA).  The idea is that ssh-agent is started in the beginning of an X-session or a login session, and all other windows or programs are started as clients to the ssh-agent program.  Through use of environment variables the agent can be located and automatically used for authentication when logging in to other machines using ssh(1).

Pas clair ? En gros, cet agent SSH est chargé de gérer vos clefs privées à votre place en diffusant vos « credentials » (informations d’authentification) à chaque fois qu’elles sont nécessaires. Donc si on fait tourner un agent SSH sur le Client C, il n’y aura plus besoin d’entrer à chaque fois la passphrase, une fois suffira, puisqu’ensuite, ce sera l’agent qui se chargera de transmettre l’information.
Et encore plus intéressant, cet agent SSH peut transmettre vos « credientials » d’une machine à l’autre, c’est à dire, que si vous vous connectez depuis le Client C au Serveur A, puis du serveur A vers le Serveur D (avec le même utilisateur bien sûr), vos credentials du Client C seront transmis au Serveur D via le Serveur A (d’où l’intérêt d’avoir configuré le Forward Agent sur le Serveur A). Cela évite à avoir à copier vos clefs privés sur tous les serveurs. Cependant, il faudra au préalable que tous vos serveurs acceptent vote clef publique (refaire sur chaque serveur cette étape).

Mise en place de l’agent SSH

Le but est donc de démarrer un agent SSH à chaque fois que vous démarrez une nouvelle session sur le client C.

Mais plutôt que d’inscrire la commande ssh-agent directement dans le ~/.bash_login ( ce qui aurait les conséquences suivantes: obligé de générer un ssh-agent, donc de rentrer la passphrase à chaque nouvelle ouverture d’un shell et bloquer le gestionnaire de fenêtres, étant en attente de la passphrase), il est préférable d’utiliser le petit script suivant que l’on va copier dans le fichier ~/.profile :

#ssh-agent starter/spawner
if [ -f ~/.agent.env ]; then
        . ~/.agent.env > /dev/null
        if ! kill -0 $SSH_AGENT_PID > /dev/null 2>&1; then
                echo "Stale agent file found. Spawning new agent..."
                eval `ssh-agent | tee ~/.agent.env`
                ssh-add
        fi
else
        echo "Starting a new agent..."
        eval `ssh-agent | tee ~/.agent.env`
        ssh-add
fi

Petite explication de ce que fait exactement ce script:
Il va maintenir le fichier ~/.agent.env qui va pointer directement sur l’agent en cours d’exécution. Si celui-ci est « trop vieux » ou n’existe plus, il va automatiquement en regénérer un autre et ajouter les clefs automatiquement.

Concrètement, comment cela se passe-t-il ?

Si vous vous connectez pour la première fois sur le client C, la passphrase vous sera demandé (soit via l’interface graphique sous forme de popup, soit par la ligne de commande). Une fois que cette passphrase est rentrée, elle ne vous sera plus demandé jusqu’à ce que vous quittiez votre session.

Exemple de génération de l’agent en ligne de commande:

Stale agent file found. Spawning new agent...
Agent pid 3611
Enter passphrase for /home/<user>/.ssh/id_rsa:
Identity added: /home/<user>/.ssh/id_rsa (/home/<user>/.ssh/id_rsa)

A partir de maintenant, votre passphrase est connu de l’agent SSH et vous pourrez vous connecter automatiquement à vos serveurs sans entrer un seul mot de passe (hormis bien sûr au démarrage de votre session).

Voilà un vrai gain de temps et grâce à ce script, vous n’aurez plus à vous occuper de votre agent ssh.

Une dernière astuce pour la route ?

Un petit hack pour vous faciliter encore plus la vie !

Précédemment, on a vu comment considérablement accélerer les connexions aux différentes machines. Mais il faut toujours taper l’éternelle commande

$ ssh serveurA

pour pouvoir se connecter.

Voici un moyen simple et efficace de faire encore plus rapide:

Si vous n’avez pas de répertoire ~/bin dans votre home, créez-le (c’est très pratique!)

$ mkdir ~/bin

et assurez-vous de l’inclure dans votre PATH en ajoutant ceci à votre fichier ~/.profile

#include ~/bin in the PATH
if [ -d ~/bin ] ; then
    PATH=~/bin:"${PATH}"
fi

Ainsi, vous pourrez à l’avenir stocker dans ce répertoire des commandes propres à votre utilisateur.

Dans ce répertoire, créez un script ssh-to

$ vim ~/bin/ssh-to

Et copiez ce code suivant:

#!/bin/sh
ssh `basename $0` $*

Rendez le exécutable

$ chmod 755 ~/bin/ssh-to

Ensuite, il ne vous reste plus qu’à faire des liens symboliques vers ce fichier en prenant le nom de vos serveurs. Par exemple, pour le serveur A:

cd ~/bin
ln -s ssh-to serveurA

Maintenant, pour vous connecter au serveur A, il vous suffit simplement de taper le nom du serveur. Et comme ce raccourci est dans le PATH, il sera automatiquement reconnu comme commande du système !

Comment marche ce script ?

`basename $0` correspond à la commande que vous appelez (dans l’exemple serveurA), le script va donc lancer la commande ssh serveurA
Quant au second argument $* il correspond aux autres commandes que vous souhaitez exécuter sur la machine distante. Par exemple, pour connaitre le temps d’exécution de votre serveur A, il ne vous reste qu’à taper la commande suivante :

$ serveurA uptime
00:27:24 up 66 days, 18:16,  1 user,  load average: 0.08, 0.02, 0.00

Le script va ouvrir la connexion SSH sur Serveur A et passer la commande uptime. Une fois le résultat affiché, vous revenez au shell de la machine Client C.

J’espère que ce dernier hack vous plaira, personnellement je l’utilise tous les jours pour me simplifier la tâche d’admin système !

Sources

Concernant la configuration et la mise en place du client SSH sous Linux, j’ai trouvé beaucoup d’informations dans l’excellent livre LINUX SERVER HACKS (que je recommande vivement pour tout administrateur système)

Le reste provient des pages de manuel ainsi que de la documentation de PuTTY : http://the.earth.li/~sgtatham/putty/0.60/htmldoc/

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *