Lorsque l’on se connecte en SSH sur une machine Linux (ou Unix) pour effectuer des commandes à distance depuis un script ou pour effectuer des tâches administratives, il peut être très intéressant d’éviter d’utiliser une authentification par mot de passes, souvent simplistes. D’autant plus dans le cas de script, ou même lorsque l’on utilise des mot de passes élaborés, il est souvent nécessaire de mettre le mot de passe dans le script, donc en clair, ce qui évidement rend inutile le fait d’utiliser des mot de passes élaborés.
L’utilisation de Kerberos ou de certificats peut palier l’utilisation de mot de passes et donc rendre l’authentification bien plus sécurisée. Une autre alternative et l’utilisation de clefs RSA pour l’authentification SSH. L’authentification RSA pour les connexions SSH se basent sur un échange de clefs et la signature de jetons d’authentification au moment de la connexion.
Authentification RSA
Le principe de l’authentification RSA se base sur la signature de jetons d’authentification lors de la connexion. Le client dispose d’une paire de clefs d’authentification : une clef privée qu’il est le seul à détenir et une clef publique que les serveurs utiliseront pour vérifier l’identité du client. Au moment de l’authentification, le client signe un jeton avec sa clef privée et le donne au serveur sur lequel il a besoin de s’authentifier. Le serveur doit avoir accès à la clef publique du client pour décrypter le jeton d’authentification. Comme lors de l’utilisation d’un algorithme de cryptage, seule la clef publique correspondant à la clef privée permet de décrypter le message : c’est le principe de signature numérique. Le serveur, avec la clef publique, peut donc vérifier la signature du jeton d’authentification, en ayant l’assurance que seul le client a pu générer la signature (le client est le seul à détenir la clef privée).
![]( "Authentification par clefs RSA")
Génération d’une paire de clefs sur Linux
Sur la machine cliente on peut générer une paire de clefs RSA avec la commande suivante :
badrogh@demeter:~$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/badrogh/.ssh/id_rsa): Created directory '/home/badrogh/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/badrogh/.ssh/id_rsa. Your public key has been saved in /home/badrogh/.ssh/id_rsa.pub. The key fingerprint is: 44:1b:94:be:04:4a:34:ca:ad:af:16:43:a2:28:b4:8c badrogh@demeter The key's randomart image is: +--[ RSA 2048]----+ | .o .+. | | . o.....o | | o... oo | |..... .o | |*oo .S. | |Eoo. . | |. o. | | .. | | .. | +-----------------+ badrogh@demeter:~$
Par défaut la clef privée est sauvegardée dans le fichier id_rsa dans un répertoire caché nommé .ssh de la homedir de l’utilisateur. La clef publique correspondante est sauvegardée dans le fichier id_rsa.pub dans le même répertoire. Lorsque l’on génère la clef privée, il est possible de protéger l’accès à cette clef par une phrase (appelée passphrase). Cela renforce la sécurité mais oblige à saisir cette phrase à chaque fois que l’on utilise la clef privée, ce qui perd tout intérêt quand l’authentification se fait dans un script.
Ajout de la clef publique sur le serveur
Pour permettre l’authentification par clef RSA sur le serveur, il est nécessaire d’ajouter la clef publique de l’utilisateur dans le fichier de clefs autorisées sur le serveur. Pour cela il faut connaitre le mot de passe de l’utilisateur sur le serveur et utiliser la commande suivante :
badrogh@demeter:~$ ssh-copy-id -i /home/badrogh/.ssh/id_rsa.pub badrogh@athena Red Hat Enterprise Linux Server release 5.5 (Tikanga) Kernel 2.6.18-194.el5 on an x86_64 Password: Now try logging into the machine, with "ssh 'badrogh@athena'", and check in: .ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting. badrogh@demeter:~$
Le service SSH doit également être configuré pour accepter l’authentification par clefs RSA. Le fichier de configuration du serveur SSH doit contenir les paramètres suivants :
RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys
Si vous avez besoin d’ajouter ces lignes de configuration ou de les dé-commenter, n’oubliez pas de redémarrer le service sshd !
A partir de là on peut s’authentifier sans mot de passe depuis les machines qui utilise la clef privée de l’utilisateur pour se connecter en SSH :
badrogh@demeter:~$ ssh athena Red Hat Enterprise Linux Server release 5.5 (Tikanga) Kernel 2.6.18-194.el5 on an x86_64 Last login: Mon Jan 2 11:41:33 2012 from demeter.olympe.demo [badrogh@athena ~]$
Utilisation de clefs RSA avec PuTTy
Maintenant que nous avons généré une paire de clefs pour notre utilisateur et configuré le serveur, on peut utiliser cette méthode d’authentification même depuis une machine Windows avec le client SSH libre PuTTy.
Pour commencer il nous faut copier la clef privée générée pour notre utilisateur sur la machine Windows depuis laquelle on veux se connecter :
Ensuite nous allons convertir cette clef dans un format utilisable par PuTTy avec l’outil puttygen.exe, disponible dans le répertoire d’installation. Notons que cet outil aurait pu être également utilisé pour générer une paire de clefs RSA, dans ce cas nous aurions dû sauvegarder la clef publique générée et ajouter cette clef dans le fichier autorized_keys du serveur. Ici nous allons convertir notre clef existante :
On peut nommer la clef ainsi convertie et la sauvegarder au format ppk utilisé par PuTTy :
Une fois la clef sauvegardée (bouton Save private key), on a maintenant une clef utilisable pour nos sessions SSH :
Configuration de la connexion SSH dans PuTTy
Commençons par ouvrir PuTTy puis précisons le nom de login à utiliser pour la connexion SSH dans l’onglet Connection > Data :
Puis ajoutons la clef privée à utiliser pour la connexion SSH dans l’onglet Connection > SSH > Auth (bouton Browse de la section Authentication parameters) :
Il nous reste à spécifier le nom du serveur où l’on veux se connecter (et où on a préalablement ajouter la clef publique dans le fichier de clefs autorisées), on peut même se sauvegarder la connexion pour la prochaine fois :
A partir de là on peut se connecter en SSH avec PuTTy sans mot de passe :
Et voilà 
