OpenSSH supporte plusieurs types d'authentification dont les plus utilisés sont l'authentification par mot de passe et l'authentification par clef publique. Avec la première méthode, le serveur vous demande de saisir un mot de passe lors de la connexion. Comme vu précedemment, utiliser cette possibilité est déconseillé car elle peut laisser la porte ouverte à des attaques par force brute. Ce n'est pas non plus très pratique : il faudra taper un mot de passe à chaque connexion (même si l'on s'est déconnecté juste avant). Si en plus on doit gérer plusieurs serveurs, il faudra taper un mot de passe (potentiellement différent) à chaque connexion sur ces serveurs.
L'authentification par clef publique, en revanche, ne nécessite pas de taper un mot depasse sur le serveur. Il suffit de prouver au serveur que l'on possède une certaine clef (notre clef privée) correspondant à une clef déposée sur le serveur (notre clef publique).
Cette méthode possède plusieurs avantages. Tout d'abord, l'authentification est décorrelée du mot de passe du compte sur lequel nous voulons nous connecter. Par exemple, si je désire me connecter en tant que root, il suffira que je dépose ma clef publique à un endroit spécifique dans le répertoire maison de root. Si un autre utilisateur à aussi besoin de se connecter as root sur la machine, il suffira de déposer aussi sa clef privée. Tout cela se fait donc sans connaitre le mot de passe de root[7]. Ainsi, lorsque n personnes ont accès au compte root d'une machine, retirer l'accès à l'une d'elle consiste simplement à retirer sa clef. Si l'on avait utilisé l'authentification par mot de passe, il aurait fallu changer le mot de passe et distribuer ce nouveau mot de passe à n-1 personnes, avec tous les problèmes pratiques que cela peut poser.
Pour « débloquer » ma clef privée (et ainsi pouvoir valider mon identité en correspondance avec la clef publique), il faudra tout de même taper un mot de passe[8]. Mais OpenSSH est capable, grâce à ssh-agent, de mémoriser les clefs privées débloquées. Ainsi, une fois la clef débloquée, vous n'aurez généralement plus de mot de passe à taper tant que vous ne quittez pas votre session.
La création de la clef (plus exactement de la paire de clefs) se fait avec ssh-keygen.
alice@linus:~$ssh-keygen -t dsa❶ Generating public/private dsa key pair. Enter file in which to save the key (/home/alice/.ssh/id_dsa): Enter passphrase (empty for no passphrase):*****Enter same passphrase again:*****Your identification has been saved in /home/alice/.ssh/id_dsa. Your public key has been saved in /home/alice/.ssh/id_dsa.pub. The key fingerprint is: 42:24:74:1d:f3:f6:e8:74:24:99:06:4b:41:08:b6:8a alice@linus alice@linus:~$
| ❶ | Type de clef à créer. Il est recommandé d'utiliser des clefs DSA |
Les clefs publiques et privées générées
seront appellées respectivement id_dsa.pub et
id_dsa et seront créées dans le répertoire
$HOME/.ssh. A moins d'utiliser plusieurs clefs, il vaut
mieux éviter de changer le nom des clefs générées ou leur emplacement.
La clef $HOME/.ssh/id_dsa est donc la clef privée et
elle doit être particulièrement protégée. En cas de doute sur sa
confidentialité, il ne faut pas hésiter à regénérer ses clefs.
Un fois la paire de clefs générée, il faut déposer la clef publique sur le
serveur (ici 192.168.17.139). Cette clef sera ajoutée dans le authorized_keys
de l'utilisateur cible situé dans le répertoire .ssh. Par
exemple, si Alice veut se connecter sur la machine
ubuntu en tant qu'utilisateur
root, il faudra ajouter sa clef publique dans
le fichier ~root/.ssh/authorized_keys sur ubuntu.
Lorsque l'usager du serveur cible possède un mot de passe (ce qui n'est pas
le cas de root sous les Ubuntu), il est possible
d'effectuer cette opération en une seule commande avec
ssh-copy-id -i .ssh/id_dsa.pub utilisateur@server
Voici une session dans laquelle alice génère une paire de
clef afin de se connecter en tant que root sur la machine
serveur. On part du principe que
PasswordAuthentication n'a pas encore été
changé.
La syntaxte de ssh est simplissime :
ssh {user@host}
ou user est le nom d'utilisateur sous lequel l'on veut se connecter et host est la machine.
alice@linus:~$scp .ssh/id_dsa.pub oper@192.168.17.139:❶ The authenticity of host '192.168.17.139 (192.168.17.139)' can't be established. RSA key fingerprint is a2:e5:d2:3a:44:be:e6:2a:10:71:dc:2e:d7:80:c1:c7. Are you sure you want to continue connecting (yes/no)?yesWarning: Permanently added '192.168.17.139' (RSA) to the list of known hosts. oper@ubuntu's password:*****id_dsa.pub 100% 602 0.6KB/s 00:00 alice@linus:~$ssh oper@192.168.17.139❷ oper@192.168.17.139's password:*****Linux ubuntu 2.6.20-15-server #2 SMP Sun Apr 15 07:41:34 UTC 2007 i686 The programs included with the Ubuntu system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Wed Jun 6 09:03:53 2007 oper@ubuntu:~$sudo -i❸ Password: root@ubuntu:~#mkdir .sshroot@ubuntu:~#cat ~oper/id_dsa.pub >> .ssh/authorized_keysroot@ubuntu:~#chmod 700 .ssh/❹ root@ubuntu:~#chmod 600 .ssh/*root@ubuntu:~#logout❺ oper@ubuntu:~$logoutConnection to 192.168.17.139 closed. alice@michel:~$ssh root@192.168.17.139❻ Enter passphrase for key '/home/alice/.ssh/id_dsa':*****❼ Linux ubuntu 2.6.20-15-server #2 SMP Sun Apr 15 07:41:34 UTC 2007 i686 The programs included with the Ubuntu system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. root@ubuntu:~#
| ❶ | scp permet de copier (Secure CoPy) de fichiers à
travers un canal ssh sécurisé. Ici on copie
|
| ❼ | Alice se connecte en tant que oper sur le serveur. |
| ❸ | oper est dans le groupe admin, et il est donc autorisé à passer root grâce à sudo. |
| ❹ |
ssh est très regardant concernant les permissions des fichiers. Il n'autorisera
les connexions que si les fichiers d'autorisation et les clefs sont
correctement protégées des regards indiscrets. Alice aurait pu aboutir au même
résultat en faisant un |
| ❺ | Une fois le fichier mis en place et les permissions corrigées, Alice peut se délogguer du compte root (elle revient du sudo), puis du serveur (elle revient du ssh). |
| ❻ | Le moment de vérité... Alice essaie de se connecter en tant que root sur le serveur. |
| ❼ | Maintenant Alice utilise le mot de passe qu'elle a utilisé lors de la création de sa clef privée. |
Pour faire mémoriser une clef débloquée à ssh-agent, il suffit d'invoquer ssh-add et de taper le mot de passe de déblocage de la clef.
alice@linus:~$ssh-addEnter passphrase for /home/alice/.ssh/id_dsa:*****Identity added: /home/alice/.ssh/id_dsa (/home/alice/.ssh/id_dsa) Identity added: /home/alice/.ssh/identity (alice@linus) alice@linux:~$ssh root@192.168.17.139Last login: Wed Jun 6 17:54:41 2007 from 192.168.253.70 [root@ubuntu root]#
On peut parfois avoir besoin de regénérer les clefs du serveur. Dans le cas de machines clonées par exemple, si rien n'est fait les clefs seront identiques sur les clones. Il est préférable de générer une nouvelle clef de serveur afin que chaque serveur ait son propre jeu de clefs.
Poure regenérer les clafs serveurs, on peut invoquer le script de
post-installation Ubuntu avec
dpkg-reconfigure openssh-server :
alice@michel:~$ssh root@192.168.17.139... root@ubuntu:~#rm /etc/ssh/*key*root@ubuntu:~# dpkg-reconfigure openssh-server Creating SSH2 RSA key; this may take some time ... Creating SSH2 DSA key; this may take some time ... * Restarting OpenBSD Secure Shell server... [ OK ] root@ubuntu:~#
Une autre possibilité consiste à les générer à la main :
alice@michel:~$ssh root@192.168.17.139... root@ubuntu:~#ssh-keygen -f "/etc/ssh/ssh_host_rsa_key" -N '' -t rsaGenerating public/private rsa key pair. /etc/ssh/ssh_host_rsa_key already exists. Overwrite (y/n)?yYour identification has been saved in /etc/ssh/ssh_host_rsa_key. Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub. The key fingerprint is: eb:46:c3:9c:6f:90:06:b6:c9:f6:3a:9b:11:28:87:41 root@ubuntu root@ubuntu:~#ssh-keygen -f "/etc/ssh/ssh_host_dsa_key" -N '' -t dsaGenerating public/private dsa key pair. /etc/ssh/ssh_host_dsa_key already exists. Overwrite (y/n)?yYour identification has been saved in /etc/ssh/ssh_host_dsa_key. Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub. The key fingerprint is: 78:46:c7:97:7d:2f:a7:ad:21:77:9c:01:20:06:29:61 root@ubuntu root@ubuntu:~#
Dans les deux cas, Alice devra aussi effectuer une modification dans sa
configuration. En effet, ssh étant plutôt strict, il refusera de vous laisser
vous connecter à un serveur dont la clef à changé. Ces clefs serveurs sont
parfois stockés globalement (/etc/ssh/ssh_known_hosts)
mais le plus souvent resident dans ~/.ssh/known_hosts.
Ce fichier est en général rempli par ssh avec la clef d'un serveur lors
de la première connexion (sauf si le paramètre
StrictHostKeyChecking est à yes
dans /etc/ssh/ssh_config.
Il faudra alors supprimer manuellement l'ancienne clef serveur de
~/.ssh/known_hosts.
Comme le message d'erreur comporte le numéro de ligne (NN ici) contenant l'ancienne
clef, l'astuce
vi +NNd +x /home/alice/.ssh/known_hosts
permet de supprimer
la mauvaise clef en une seule commande.
Il suffit ensuite de relancer la connexion et d'accepter la nouvelle clef.
alice@linus:~$ssh root@192.168.17.139@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 eb:46:c3:9c:6f:90:06:b6:c9:f6:3a:9b:11:28:87:41. Please contact your system administrator. Add correct host key in /home/alice/.ssh/known_hosts to get rid of this message. Offending key in /home/alice/.ssh/known_hosts:43 RSA host key for 192.168.17.139 has changed and you have requested strict checking. Host key verification failed. alice@linus:~$vi +43d +x /home/alice/.ssh/known_hostsalice@linus:~$ssh root@192.168.17.139The authenticity of host '192.168.17.139 (192.168.17.139)' can't be established. RSA key fingerprint is eb:46:c3:9c:6f:90:06:b6:c9:f6:3a:9b:11:28:87:41. Are you sure you want to continue connecting (yes/no)?yesWarning: Permanently added '192.168.17.139' (RSA) to the list of known hosts. Enter passphrase for key '/home/alice/.ssh/id_dsa':*****Last login: Wed Jun 6 22:41:50 2007 from 192.168.0.228 Linux ubuntu 2.6.20-15-server #2 SMP Sun Apr 15 07:41:34 UTC 2007 i686 The programs included with the Ubuntu system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. root@ubuntu:~#
On pourrait critiquer de l'utilité d'une telle fonctionnalité. En effet, pour quelle raison voudrait-on changer de mot de passe ? Soit le mot de passe est compromis (ou est susceptible de l'être). Dans ce cas, la clef privée l'est aussi. Soit on désire utiliser un mot de passe plus robuste. C'est donc que l'ancien ne l'était pas et que la clef n'est pas conséquent plus digne de confiance.
La aussi, chacun d'entre nous devra peser le « pour » et le « pour » et décider
d'utiliser ou non cette fonctionalité. C'est l'option -p de la commande
ssh-keygen qui permet de modifier le mot de passe de la clef.