Fedora-Fr - Communauté francophone Fedora - Linux

Portail de Fedora-Fr : la communauté francophone autour de la distribution Linux Fedora

Chercher

dans Documentation

Chercher

Accueil
Forums
Documentation
Planet
Association
Boutique

SSH : Authentification par clé

De Wiki Fedora-Fr
Par : ChristophePolyte
Avec l'aimable contribution de : Johan Cwiklinski

Aide
Pour lire ce wiki convenablement, merci de lire la page suivante concernant les conventions de nommage.

SSH (Secure SHell) permet de se connecter de façon sécurisée à un système Unix, Linux et Windows (très peu utilisé mais disponible via
l'API cygwin).

Il faut distinguer :

SSH : le protocole de communication ;

ssh : le programme client permettant de se connecter au serveur ;
 sshd : le serveur (ssh daemon) écoutant sur le port 22 par défaut.

Il existe des clients SSH pour toutes les architectures :

Linux : ssh, putty... ;

Windows : putty, ssh (via cygwin) ;
Mac : macssh, ssh.

Sommaire
1 Présentation
2 L'authentification par clé
3 Création de la paire de clé
4 Paramétrage de SSHd
5 Configuration avancée
5.1 Conseils de sécurité
5.2 Configuration par utilisateur
6 ssh-agent
7 Correction des problèmes
7.1 Première connexion
7.2 Changement de clé d'hôte sur le serveur
7.3 Les clés ne fonctionnent pas
7.4 Caractères bizarres dans putty
8 Conclusion
9 Pour aller plus loin

1 Présentation
Du point de vue de l'utilisateur une connexion ssh s'établit comme une session telnet (demande de connexion, demande de login,
demande de mot de passe), le principe est en réalité beaucoup plus complexe.

SSH permet de garantir :

 La confidentialité : le chiffrement des paquets permet de garantir celle-ci. Les anciens services tels que telnet, rlogin... envoyaient
les données en clair ;
L'intégrité : SSH permet de garantir que les paquets circulant d'un hôte vers un autre ne sont pas altérés ;
L'authentification : chaque connexion SSH vérifie l'identité du serveur (par sa clé d'hôte ~/.ssh/known_hosts) puis celle du client (par
mot de passe ou clé publique ~/.ssh/authorized_keys) ;
L'autorisation : il est possible avec SSH de limiter les actions autorisées à l'utilisateur (~/ssh/.authorization) ;
Tunneling : SSH permet de sécuriser un service dont les informations circulent habituellement en clair (POP, IMAP, VNC...). D'autres
aspects du tunneling sont la sécurisation du protocole X11 (X11forwarding) , et l'utilisation de clés privées situées sur un hôte
distant (Agent forwarding).

SSH est donc sécurisé mais ne protège pas de tout. L'authentification par mot de passe reste relativement vulnérable (mot de passe trop
facile à découvrir... toute la difficulté d'un bon mot de passe : facile à retenir, difficile à découvrir par les autres).

2 L'authentification par clé

Face à la faiblesse de l'authentification par mot de passe, l'authentification par clé se révèle être très efficace.

La clé permet de garantir à un système qu'un utilisateur est bien celui qu'il prétend être... en deux mots : « Je jure et je prouve que c'est
bien moi ».

L'authentification par clé fonctionne grâce à 3 composants :

Une clé publique : elle sera exportée sur chaque hôte sur lequel on souhaite pouvoir se connecter ;
Une clé privée : elle permet de prouver son identité aux serveurs ;
Une passphrase : Permet de sécuriser la clé privée (notons la subtilité, passphrase et pas password... donc « phrase de passe » et non
pas « mot de passe »).

La sécurité est vraiment accrue car la passphrase seule ne sert à rien sans la clé privée, et vice-versa.

3 Création de la paire de clé

La création de la paire de clé se fait avec ssh-keygen.

Il existe 2 types de clés : RSA et DSA. Chacune pouvant être de longueur différente : 1024, 2048, 4096 bits (les clés inférieures à 2048 bits
sont à proscrire... surtout les RSA). Pour créer une clé RSA de 2048 bits : ssh-keygen -t rsa -b 2048 -C username@domain.tld. Sans
paramètres, les options par défaut sont type RSA en 2048 bits.
Le commentaire permet de distinguer les clés, utile quand on a plusieurs clé (notamment une personnelle et une pour le boulot). Ici la
distinction se fait sur l'adresse e-mail. Si le commentaire est omis, il sera de la forme user@host.

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/drpixel/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/drpixel/.ssh/id_rsa.
Your public key has been saved in /home/drpixel/.ssh/id_rsa.pub.
The key fingerprint is:
cb:61:48:6b:b4:53:00:9b:d1:2a:cf:44:88:79:c2:19 username@domain.tld

Deux fichiers ont été créés (dans le dossier ~/.ssh/) :

id_rsa (ou id_dsa dans le cas d'une clé DSA) : contient la clé privée et ne doit pas être dévoilé ou mis à disposition ;
id_rsa.pub (ou id_dsa.pub dans le cas d'une clé DSA) : contient la clé publique, c'est elle qui sera mise sur les serveurs dont l'accès est
voulu.

4 Paramétrage de SSHd
Le fichier de configuration est /etc/ssh/sshd_config.
L'authentification par clé est active par défaut. En fait, dans le fichier de configuration original, toutes les valeurs commentées (précédées
d'un #) sont placées à leur valeur par défaut. En effet, la ligne

#PubkeyAuthentication yes

Signifie que la valeur par défaut de la clé PubkeyAuthentication est Yes ; l'authentification par clé est autorisée. Si vous souhaitez modifier
la valeur d'une clé, il suffit de la décommenter. La suite de ce tutoriel vous donnera quelques exemples.

Cela ne suffit bien entendu pas car aucune clé publique n'a été envoyée sur le serveur.

L'authentification par mot de passe va être utilisée

Première méthode de copie d'une clé :

[drpixel@sidewinder ~]$ cat ~/.ssh/id_rsa.pub | ssh user@ip_machine "cat - >> ~/.ssh/authorized_keys"

user@ip_machine's password:
Cette commande va lire le fichier $HOME/.ssh/id_rsa.pub (clé publique), se connecter sur le serveur ayant l'adresse ip « ip_machine » avec
le nom d'utilisateur « user » et ajouter au fichier des clés autorisées ($HOME/.ssh/authorized_keys) le contenu de la clé lue.

Deuxième méthode de copie d'une clé :

Il s'agit du même principe que la première méthode sauf que tout est décomposé (utile pour bien comprendre) :

[drpixel@sidewinder ~]$ scp ~/.ssh/id_rsa.pub user@ip_machine:/tmp

user@ip_machine's password:
id_rsa.pub 100% 609 0.6KB/s 00:00
[drpixel@sidewinder ~]$ ssh user@ip_machine
[user@nom_machine ~]$ cat /tmp/id_rsa.pub >> /root/.ssh/authorized_keys
[user@nom_machine ~]$ rm /tmp/id_rsa.pub

Troisième méthode :

Il s'agit de la méthode la plus automatisée et la plus simple. Il s'agit aussi de la méthode officiellement recommandée.

[drpixel@sidewinder ~]$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@ip_machine

root@durandal's password:
Now try logging into the machine, with "ssh 'user@ip_machine'", and check in:

.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

ssh-copy-id va copier la clé publique sur l'hôte distant. Par mesure de sécurité, le script ajoute l'extension .pub au fichier d'identité si elle
a été omise.

Notez que si vous possédez plusieurs clés, cette commande risque d'en copier plusieurs. Pensez à vérifier le fichier ~/.ssh/authorized_keys
sur ip_machine pour éventuellement supprimer les clés que vous ne souhaitez pas publier sur ce serveur.

La situation-cible sera alors:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
ChallengeResponseAuthentication yes
 Note
Il est possible de définir la machine distante dans /etc/hosts (ou dans .ssh/config) pour qu'elle soit identifiée par son nom. De
plus, si l'utilisateur auquel on souhaite se connecter est le même sur la machine distante, on remplacera « user@ip_machine »
par « nom_machine ». Nous pourrons donc nous connecter plus simplement avec la commande suivante :

[drpixel@sidewinder ~]$ ssh nom_machine

Piège a éviter :

Il faut s'assurer dans le cas ou un fichier authorized_keys est présent, qu'il se termine bien par une nouvelle ligne. Sinon le rajout se fera à
la volée et 2 clés (la dernière et celle rajoutée) seront inutilisables.

5 Configuration avancée
5.1 Conseils de sécurité

Désactivation de l'authentification par mot de passe

Une fois que les clés sont générées, mises en place et que leur fonctionnement testé, il est souhaitable de désactiver l'authentification par
mot de passe (ATTENTION, bien vérifier de pouvoir accéder physiquement au serveur... au cas où...). Cela se passe donc dans le fichier de
configuration (/etc/ssh/sshd_config). Pour la suite, le nom de la machine distante correspond à « amraam » .

PasswordAuthentication yes

devient

PasswordAuthentication no

On relance le service sshd :

[root@amraam ~]# systemctl restart sshd.service

Il n'est plus possible désormais de se connecter avec le couple login/mot de passe.

 Désactivation de l'accès direct en super utilisateur. Il est possible de désactiver l'accès direct vers le compte root vers votre (et
même vos ;-)) ordinateurs.

En effet, il n'est jamais très conseillé d'abuser des droits super utilisateur, il est donc possible de désactiver la possibilité au root de se
connecter. L'accès au serveur distant pourra être fait sur un autre compte utilisateur, quitte à faire un petit « su - » ensuite.
Pour ce faire, trouvez la ligne :

#PermitRootLogin yes

Attribuez-lui la valeur « no » et décommentez la ligne :

PermitRootLogin no

Au prochain démarrage de votre démon sshd, il ne sera plus possible de se connecter directement à votre serveur sur le compte root via
SSH.

Liste des utilisateurs autorisés à se connecter

Il est possible de mettre en place la liste des utilisateurs qui seront seuls autorisés à se connecter avec la directive AllowUsers dans le
fichier de configuration du démon SSH :

AllowUsers drpixel builder@127.0.0.1

La page de manuel de sshd_config (man sshd_config) pourra vous apporter des compléments d'informations, ainsi que des directives qui
ne sont pas abordées dans le présent article.

5.2 Configuration par utilisateur

La configuration par utilisateur se fait par le fichier ~/.ssh/config. Voyons l'exemple suivant :

Host serveur
HostName 10.42.0.1
User client
Port 22
IdentityFile ~/.ssh/.id_rsa
Host *.gitorious.org
IdentityFile ~/.ssh/.id_rsa_gitorious

Avec le fichier ci-dessus, la commande ssh serveur sera équivalente à ssh -p 22 -i ~/.ssh/.id_rsa client@10.42.0.1, ce qui est bien plus
pratique. Préciser la clé d'identification permet donc d'en définir plusieurs, on remarque également que dans cet exemple, quelque soit
l'utilisateur auquel on veut se connecter sur gitorious.org, le fichier d'identité est précisé.

6 ssh-agent
Le serveur SSH est maintenant plus sécurisé, mais taper des passphrases à longueur de journée peut se révéler être très pénible surtout
si on a choisi une « vraie » passphrase.

L'agent SSH permet de taper la passphrase une seule fois et de la conserver en mémoire pendant tout son fonctionnement. Les
communications SSH fonctionneront donc de façon transparente.

Mode texte

Il faut lancer l'agent avec un shell (le plus simple étant de le lancer avec la variable $SHELL qui contient le shell courant).
Ensuite le programme ssh-add permet de charger les clé présentes dans ~/.ssh/. La passphrase est demandée, toutes les connexions
nécessitant les clés chargées par l'agent seront transparentes.

[drpixel@sidewinder ~]$ ssh-agent $SHELL

[drpixel@sidewinder ~]$ ssh-add
Enter passphrase for /home/drpixel/.ssh/id_rsa:
Identity added: /home/drpixel/.ssh/id_rsa (/home/drpixel/.ssh/id_rsa)
[drpixel@sidewinder ~]$ ssh user@ip_machine
Last login: Mon Jul 3 17:21:20 2006 from ip_dernier_client

Mode graphique

Prérequis : Le paquet openssh-askpass doit être installé. Cela peut être vérifié en tapant rpm -q openssh-askpass.

[drpixel@sidewinder ~]$ rpm -q openssh-askpass

openssh-askpass-7.5p1-3

Son lancement ouvrira une fenêtre demandera les passphrases de chaque clé trouvée dans ~/.ssh/
 Windows (avec putty)

L'utilisation de putty ne change pas grand chose au principe des clés. Putty a également son agent.

Pour des raisons de simplicité, il est préférable de générer des clés sous Linux et de les transférer sous Windows plutôt que d'utiliser le
générateur de clé de Putty.

Putty utilise en effet un format « propriétaire » pour ses clés. La conversion est possible mais reste quelques fois houleuse dans le sens
Windows -> Linux. Après avoir généré la clé sous Linux, on peut la récupérer via SSH (avec winscp par exemple) ou par n'importe quel
autre moyen.

Il faut ensuite convertir la clé au format putty. Pour cela, lancez « Putty Secure Key Generator » (puttygen.exe), puis choisissez
Conversions, Import key.
Dans l'explorateur de fichier, sélectionnez la clé privée, la passphrase sera demandée. Changez ensuite la partie commentaire pour
remettre la valeur choisie lors de la génération de la clé.
Pour terminer cliquez sur « Save Private Key ».
On aura donc une clé au format .ppk (Putty Private Key).
Une fois la clé au format putty générée, il faut la donner à l'agent.
Le lancement de putty agent (pageant.exe) est muet sauf si on précise la clé à a charger dans le raccourci. Dans ce cas, il demandera la
passphrase (d'ailleurs il est judicieux de rajouter les clés dans le raccourci vers putty agent présent dans Menu Démarrer, Démarrage. Les
chemins d'accès ayant des espaces tels que Documents and Settings (qui contiennent des espaces) sont à mettre entre " "). Si elles n'ont pas
été spécifiées sur la ligne de commande, les clés se rajoutent en faisant un clic droit sur l'icône de putty agent dans la zone de notification
de la barre des tâches, et en sélectionnant le menu add key.
Dans l'explorateur de fichier, il faut sélectionner la clé privée au format ppk, la passphrase est demandée. Une fois renseignée, la clé est
opérationnelle sans avoir besoin de saisir la passphrase à chaque connexion.
Le login est toujours demandé. Pour s'affranchir de cette demande, il suffit dans les propriétés de putty, lui spécifier le login à utiliser.
Si les clés ont été générées sur le serveur qui sera utilisé pour les connexions, il suffit alors de rajouter la clé publique dans le fichier
~/.ssh/authorized_keys par un :

[user@amraam ~]$ cd .ssh

[user@amraam .ssh]$ cat id_rsa.pub >> authorized_keys

Si les clés ne seront pas utilisées en tant que client SSH, elles peuvent être supprimées (id_rsa et id_rsa.pub) du serveur.

7 Correction des problèmes

Afin d'obtenir des information de débogage supplémentaires, ajoutez l'argument -vvv à votre commande ssh.
7.1 Première connexion

Lors de la première connexion SSH vers un hôte, ce message peut apparaitre :

The authenticity of host 'amraam (192.168.24.3)' can't be established.

RSA key fingerprint is c6:ee:c6:e4:9a:b6:7e:46:4c:17:b4:d0:7b:80:af:2c.
Are you sure you want to continue connecting (yes/no)?

Il faut répondre oui lors de cette première connexion.

Warning: Permanently added 'amraam' (RSA) to the list of known hosts.

La clé d'hôte sur le serveur est maintenant conservée (fichier ~/.ssh/known_hosts) .

7.2 Changement de clé d'hôte sur le serveur

En cas de changement de clé le message suivant apparaitra :

[drpixel@sidewinder ~]# ssh user@ip_machine

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
c6:ee:c6:e4:9a:b6:7e:46:4c:17:b4:d0:7b:80:af:2c.
Please contact your system administrator.
Add correct host key in /home/drpixel/.ssh/known_hosts to get rid of this message.
Offending key in /home/drpixel/.ssh/known_hosts:12
RSA host key for amraam has changed and you have requested strict checking.
Host key verification failed.

Un changement de clé peut avoir plusieurs cause :

La clé de l'hôte a été changée volontairement par un administrateur

Le serveur a subi une réinstallation sans sauvegarde de ses clés
Ce n'est plus le même serveur (et il faut donc se renseigner si c'est normal... Car cela peut être le serveur d'un pirate...)

Pour corriger le problème (en cas de changement non suspect uniquement !!!), il suffit :
 soit de supprimer la clé du serveur dans ~/.ssh/known_hosts (ici dans la 12ème place)
soit de la modifier dans ~/.ssh/known_hosts afin de mettre la nouvelle clé de l'hôte si elle est connue

7.3 Les clés ne fonctionnent pas

Vérifiez que le répertoire .ssh ait les permissions 700 (rwx pour l'utilisateur, rien pour le groupe ni les autres) et que son contenu soit en
600 (rw pour l'utilisateur, rien pour le groupe ni les autres). Il faut aussi vérifier que chaque clé tient sur une ligne dans authorized_keys
(même si elle apparait sur plusieurs ligne a l'écran, dans le fichier elle ne correspond qu'à une ligne).

7.4 Caractères bizarres dans putty

Les versions actuelles de Fedora sont en UTF-8, et putty par défaut en ISO-8859-1. Il faut donc changer le charset dans les propriétés de la
connexion (Window/Translation):
8 Conclusion
En n'autorisant que la connexion par clé publique, le service ssh se retrouve fortement sécurisé.
C'est une opération qui n'est pas très complexe, mais qui nécessite néanmoins de bien comprendre le fonctionnement afin de le mettre
en place dans de bonnes conditions.

9 Pour aller plus loin

Site officiel d'OpenSSH (http://www.openssh.org/fr/index.html) ;
Un exemple de tunnel pour sécuriser VNC ;
man sshd, man ssh, man ssh-keygen ;
Documentation de PuTTY (http://the.earth.li/~sgtatham/putty/0.58/htmldoc/) ;
Les clés d'hôtes sont dans : /etc/sshd/ssh_host*.

Récupérée de « https://doc.fedora-fr.org/w/index.php?title=SSH_:_Authentification_par_clé&oldid=25058 »

Catégories : Réseaux et Serveurs Sécurité SSH

Dernière modification de cette page le 2 janvier 2023, à 15:26.

Le contenu est disponible sous licence Creative Commons Attribution 2.5 sauf mention contraire.

Fedora-Fr
À propos de Fedora-Fr
Historique
Statistiques

Télécharger
Obtenir Fedora
Toutes les méthodes de téléchargement

Support
Aide sur IRC
Forums
Documentation

Sous-projets
 Plateforme de blog

 
Flux RSS des actualités de Fedora-Fr
Twitter de Fedora-Fr
Fan page Facebook

Fedora-Fr est hébergé gracieusement par les VPS Ikoula.

Le Projet Fedora est maintenu et dirigé par la communauté et sponsorisé par Red Hat.

Ce site est également maintenu par la communauté. Red Hat n'est pas responsable de son contenu.