Du bon usage de ssh
Un article de Loria Wiki.
| Version du 20 oct 2006 à 13:29 Scolin (Discuter | contribs) Configurer ssh pour un usage sécurisé mais néanmoins confortable ← Différence précédente |
Version actuelle Jcb (Discuter | contribs) C'est limite, mes clefs privées sont lisibles sur ma machine - s/crypter/chiffrer/ , « crypter » n'existe pas en français |
||
| Ligne 70: | Ligne 70: | ||
| ==C'est limite, mes clefs privées sont lisibles sur ma machine== | ==C'est limite, mes clefs privées sont lisibles sur ma machine== | ||
| - | Pas tout à fait. C'est la raison pour laquelle une ''passphrase'' (un mot de passe, en quelque sorte) a été demandée. Elle sert à '''crypter''' la clef privée qui est générée. Ainsi, quelqu'un qui s'introduit sur ma machine et vole ma clef privée ne pourra pas s'en servir pour se faire passer pour moi en se connectant sur d'autres machines (''mdistante'' dans l'exemple). | + | Pas tout à fait. C'est la raison pour laquelle une ''passphrase'' (un mot de passe, en quelque sorte) a été demandée. Elle sert à '''chiffrer''' la clef privée qui est générée. Ainsi, quelqu'un qui s'introduit sur ma machine et vole ma clef privée ne pourra pas s'en servir pour se faire passer pour moi en se connectant sur d'autres machines (''mdistante'' dans l'exemple). |
| - | C'est pourquoi il est '''vivement conseillé''' d'utiliser une ''passphrase''. Quel intérêt alors, il faut encore taper quelque chose à la connexion : non, il est possible de se libérer de cette contrainte, comme nous l'allons voir. | + | C'est pourquoi il est '''vivement conseillé''' d'utiliser une ''passphrase''. Quel intérêt alors, il faut encore taper quelque chose à la connexion : non, il est possible de se libérer de cette contrainte, comme nous allons voir. |
| ==Maintenant c'est ma phrase de cryptage qu'il demande !== | ==Maintenant c'est ma phrase de cryptage qu'il demande !== | ||
Version actuelle
ssh est en quelque sorte le successeur sécurisé de rsh. Il permet des connexions cryptées qui évitent que quelqu'un qui "écoute" le réseau ne puisse voler des informations sensibles. Il se veut également :
- Plus généraliste : il permet de servir de relai pour n'importe quel protocole qui se base sur la communication entre ports IP, le rendant sécurisé par la même occasion
- Facile d'utilisation : il relaye les requêtes du serveur graphique X, ce qui permet d'utiliser son outil graphique préféré à distance, et il n'oblige à taper aucun mot de passe pourvu qu'il soit correctement configuré.
C'est ce dernier point que nous allons développer dans cette page.
'Note :' les noms de machines et les informations numériques (IPs, clefs) ont été changés, vous devrez adapter à votre configuration.
Comment utilisé-je ssh ?
Il faut créer une paire de clefs qui serviront à vous authentifier.
johndoe@mlocale:~$ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/johndoe/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/johndoe/.ssh/id_rsa. Your public key has been saved in /home/johndoe/.ssh/id_rsa.pub. The key fingerprint is: xx:xx:xx:xx:xx:xx:xx:xx:xx johndoe@mlocale johndoe@mlocale:~$
ssh-keygen sert à générer plusieurs types de clefs, nommées : identity (protocole 1), id_rsa, id_dsa (protocole 2). Préférez le protocole 2 (par défaut avec toute version récente de ssh, comme dans l'exemple), le protocole 1 ne remplit plus tous les critères d'un bon système de cryptage.
johndoe@mlocale:~$ ls -la |grep "\.ssh" drwx------ 2 johndoe johndoe 4096 2006-10-20 14:40 .ssh johndoe@mlocale:~$ ls -l .ssh/ total 8 -rw------- 1 johndoe johndoe 1751 2006-10-20 14:40 id_rsa -rw-r--r-- 1 johndoe johndoe 396 2006-10-20 14:40 id_rsa.pub
Il sauvegarde par défaut la paire de clefs dans un répertoire .ssh inaccessible aux autres. La paire de clefs consiste en une clef privée id_rsa qui restera sur cet ordinateur, et une clef publique id_rsa.pub qui servira à l'authentification sur d'autres machines disposant d'un serveur ssh.
D'accord, j'ai mes clefs ssh, mais le serveur me demande toujours mon mot de passe ?
En effet, sur le serveur, il n'y a rien qui permette de faire le lien entre vous et votre clef ssh. Alors par défaut, le système se rabat sur l'authentification par votre mot de passe, un peu plus sécurisée puisqu'elle se fait via ssh tout de même. Il faut que vous copiez votre clef publique dans un fichier spécial sur la machine distante à laquelle vous vous connectez.
johndoe@mlocale:~$ scp .ssh/id_rsa.pub samuel@mdistante:~/tmp The authenticity of host 'mdistante (xxx.xxx.xxx.xxx)' can't be established. RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'mdistante,xxx.xxx.xxx.xxx' (RSA) to the list of known hosts. samuel@mdistante's password: id_rsa.pub 100% 396 0.4KB/s 00:00 johndoe@mlocale:~$
Ici la copie a pu se faire, mais évidemment si l'authentification par mot de passe ne fonctionne pas, il faudra faire la copie plus "directement" (via une disquette, clef usb, un email à l'administrateur de la machine).
johndoe@mlocale:~$ ssh samuel@mdistante samuel@mdistante's password: mdistante samuel % ls -l tmp total 16 -rw-r--r-- 1 samuel dedale 396 Oct 20 14:50 id_rsa.pub mdistante samuel % cat tmp/id_rsa.pub >>~/.ssh/authorized_keys
Nous venons de copier le contenu de id_rsa.pub dans .ssh/authorized_keys sur la machine distante (créez le répertoire .ssh s'il n'existe pas). Donc la prochaine fois que je me connecterai, la machine distante me demandera ma clef privée, fera le lien avec la clef publique qu'elle connaît, et sera assurée que c'est bien moi. Je n'aurai plus besoin de taper mon mot de passe, tout passera par ssh.
mdistante samuel % exit logout Connection to mdistante closed. johndoe@mlocale:~$ ssh samuel@mdistante Enter passphrase for key '/home/johndoe/.ssh/id_rsa': mdistante samuel %
Nous remarquons déjà une différence, la machine distante nous demande la passphrase (voir au début du texte). Elle a donc bien fait le lien avec notre clef privée. Expliquons maintenant le besoin de cette passphrase.
C'est limite, mes clefs privées sont lisibles sur ma machine
Pas tout à fait. C'est la raison pour laquelle une passphrase (un mot de passe, en quelque sorte) a été demandée. Elle sert à chiffrer la clef privée qui est générée. Ainsi, quelqu'un qui s'introduit sur ma machine et vole ma clef privée ne pourra pas s'en servir pour se faire passer pour moi en se connectant sur d'autres machines (mdistante dans l'exemple).
C'est pourquoi il est vivement conseillé d'utiliser une passphrase. Quel intérêt alors, il faut encore taper quelque chose à la connexion : non, il est possible de se libérer de cette contrainte, comme nous allons voir.
Maintenant c'est ma phrase de cryptage qu'il demande !
Il existe un outil qui permet de charger en mémoire vive une version décryptée de la clef privée, et qui sera utilisée par la suite pour chaque connexion.
johndoe@mlocale:~$ ssh-add Enter passphrase for /home/johndoe/.ssh/id_rsa: Identity added: /home/johndoe/.ssh/id_rsa (/home/johndoe/.ssh/id_rsa) johndoe@mlocale:~$
L'outil dépend de ssh-agent, qui est le logiciel qui conservera la clef décryptée en mémoire vive, et ssh-add, qui permet de communiquer à ssh-agent la clef décryptée. ssh-agent est démarré en même temps que l'interface graphique sur toute distribution Linux récente, à condition évidemment que ssh soit installé sur la machine. Désormais vous n'aurez plus à taper votre mot de passe à la connexion.
johndoe@mlocale:~$ ssh samuel@mdistante mdistante samuel %
Vous voyez, plus de demande de passphrase.
Voyons tout de même les contraintes d'utilisation de cet outil :
- Il faut relancer ssh-add à chaque fois que l'interface graphique (le serveur X) est relancé
- Comme il est possible de se connecter directement, assurez-vous qu'aucune personne mal intentionnée ne peut utiliser votre machine en votre absence. Cela signifie activer un économiseur d'écran protégé par un bon mot de passe, par exemple.
Oui mais non, mon login local n'est pas le même que le login distant
Comme le montre l'exemple, sur mlocale je suis johndoe, et sur mdistante je suis samuel. Ça m'oblige à préciser mon login à la connection, par ssh samuel@mdistante. Il est possible de s'affranchir de cela, en précisant des informations supplémentaires dans mon fichier de configuration pour ssh.
johndoe@mlocale:~$ cd .ssh/ johndoe@mlocale:~/.ssh$ jed config johndoe@mlocale:~/.ssh$ cat config Host mdistante User samuel johndoe@mlocale:~/.ssh$ cd johndoe@mlocale:~$ ssh mdistante mdistante samuel % exit logout Connection to mdistante closed. johndoe@mlocale:~$
J'ai donc ajouté que pour l'hôte mdistante, il faut utiliser le login samuel dans mon ~/ssh/config. Maintenant pour la connection je n'ai plus qu'à taper le nom de la machine à laquelle je veux me connecter.
Désormais l'utilisation d'outils distants en ligne de commande qui passent par ssh (tels subversion par exemple) devrait être beaucoup plus agréable.
