Authentification SSH sans mot de passe avec une clé SSH de type RSA ou DSA
Par Mickaël ALLAIN le mardi, mars 9 2010, 17:00 - Architecture systèmes et réseaux - Lien permanent
Nous naviguons à travers nos serveurs, ici, là bas, et au final, on se retrouve avec une ribambelle de mot de passe à retenir. La connexion par le biais du service SSH sur vos machines Unix/Linux (Debian 5 de préférence :D) sans mot de passe est devenu monnaie courante, voyons voir comment mettre en place ce type d'authentification.
But de ce billet
Vous en avez marre de vous authentifier à chaque fois sur votre serveur de production ou simplement sur votre ordinateur personnel ? Le service OpenSSH offre la possibilité de s'authentifier (et donc, se connecter) sans mot de passe, à l'aide des fameuses clés SSH de type RSA ou DSA.
Mise en situation
Afin de vous expliquer au mieux la démarche à suivre, voici un exemple concret.
Nous avons, un serveur (ou du moins, un ordinateur avec le service openssh-server allumé) que nous allons nommer "server". Sur ce serveur, nous avons un compte utilisateur, appelons le "user_server".
De l'autre côté, nous avons notre poste client, qui lui s'appelle "local". L'utilisateur sur le poste client s'appelle "user_local".
Configuration du service OpenSSH sur le serveur.
Votre serveur doit accepter l'authentification via des clés SSH.
Pour se faire, éditons la configuration du service OpenSSH. Un petit vi /etc/ssh/sshd_config. Nous vérifions que la ligne "AuthorizedKeysFile" est décommentée comme ci-dessous. Nous profitons de cette édition pour vérifier également que la permission de s'authentifier directement en "super utilisateur" est impossible via "AllowRootLogin" à "no" (Merci @rhaamo pour cet éclaircissement) Par défaut sous Debian, cette valeur est à "without-password"
user_server@server:~$ vi /etc/ssh/sshd_config AuthorizedKeysFile %h/.ssh/authorized_keys AllowRootLogin no
Rechargeons notre configuration OpenSSH.
sudo /etc/init.d/ssh reload
La configuration du service OpenSSH étant maintenant terminée, Passons à la suite.
Création d'une clé SSH sur notre poste client.
Cette partie du billet ne vous sera utile que si vous ne disposez pas déjà d'une clé SSH. Si c'est le cas, passez à la partie suivante Installation de ma clé SSH publique sur le serveur., sinon, continuez la lecture ;-)
Pour générer une clé SSH, il existe plusieurs chiffrement dont 2 particulièrement RSA et DSA. Après nombreux commentaires à ce sujet, et en allant un peu plus loin, difficile de choisir quel est la meilleure "sécurité", DSA tire la couverture vers elle à en croire cette page (Merci à @rhaamo pour m'avoir averti des autres possibilités)
Créons une clé DSA.
ssh-keygen -t dsa
Il vous sera demandé si vous voulez appliquer une "passphrase" sur votre clé SSH. Si vous choisissez de ne pas renseigner cette "passphrase", alors, si jamais vous perdez votre clé, n'importe qui pourra se connecter sur vos différents serveurs. Il est très dangereux de laisser une clé sans "passphrase"
La génération faite, vous allez avoir 2 fichiers dans votre /home/user_local/.ssh/
- id_dsa : Elle est la clé privée, ne jamais la divulguer.
- id_dsa.pub : C'est la partie publique de votre clé SSH, c'est celle-ci qui nous intéresse.
Afin d'éviter de ne devoir retaper sa passphrase, il existe "ssh-keygen", voir la partie "SSH-AGENT" de la page Configurer et utiliser SSH
Installation de ma clé SSH publique sur le serveur.
Méthode automatisée
Rien de plus simple (Merci chatmoa), il existe une commande (ssh-copy-id) sur le poste client pour "directement" ajouter notre clé publique dans le fichier "~/.ssh/authorized_keys" de l'utilisateur visé. Attention tout de même, cette commande n'est pas disponible sur toutes les distributions. Présente sur RedHat/Debian et Ubuntu, mais pas sur les *BSD.(@rhaamo)
user_local@local: ~$ ssh-copy-id user_server@server
Après avoir renseigné notre mot de passe pour la dernière fois, la clé publique est copiée sur le compte utilisateur "user_server" du serveur.
Méthode manuelle
Pour commencer, nous allons transférer notre clé SSH publique sur le serveur.
scp /home/user_local/.ssh/id_rsa.pub user_server@server:/home/user_server/
Cette commande a pour but de copier la clé /home/user_local/.ssh/id_rsa.pub dans le répertoire /home/user_server du serveur. On va vous demander le mot de passe concernant l'utilisateur "user_server".
Connectons nous maintenant sur le serveur afin de créer le fichier ".ssh/authorized_keys".
ssh user_server@server cat /home/user_server/id_rsa.pub >> /home/user_server/.ssh/authorized_keys
Faites bien attention aux droits du fichier "authorized_keys", en effet, si le fichier ne possède pas les bons droits (600), il se peut qu'il ne soit pas lu et donc, notre authentification par clé SSH ne fonctionnera pas. (Clin d'œil à Yop69 du Forum-Ubuntu)
Test de la configuration
Maintenant que tout est configuré, testons ensemble.
user_local@local:~ $ ssh user_server@server Linux 2.6.26-1-amd64 #1 SMP Sat Jan 10 17:57:00 UTC 2009 x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. user_server@server:~$
Petit TIP
Il se peut que le service OpenSSH ne soit pas sur le port par défaut (22), ce qui est d'ailleurs est une bonne chose, au vu des nombreux scanners de ports.
Votre service OpenSSH tourne sur le port 54000, vous n'avez plus à taper votre mot de passe (grâce aux clés SSH), mais vous devez spécifier le port à chaque connection SSH. Comme ci-dessous.
ssh user_server@server -p 54000
Pour configurer automatiquement toute connexion SSH à "server" sur le port 54000 en utilisant l'utilisateur user_server, ajoutez ceci dans ~/.ssh/config de votre poste client. (@than, merci pour ton commentaire)
Host server Hostname server.domaine.fr Port 54000 User user_sever
Et voilà, vous vous connecterez de la manière suivante maintenant.
ssh server
N'hésitez pas à me faire de vos remarques et de vos suggestions.
Bonne journée à tous.
Mickaël.
Commentaires
/usr/bin/ssh-copy-id user@machine
Cette commande très pratique permet de copier sa clef publique sur le serveur.
@chatmoa, merci, je ne connaissais pas cette petite merveille, je vais mettre à jour mon billet.
Hum… quelle bonne idée, des clés ssh sans passphrase, bravo la sécurité… Du grand n'importe quoi…
Pour ne pas retaper la passphrase à chaque fois que l'on utilise la clé il y a ssh-agent qui est fait pour.
Hmmmmm, et en quoi la methode 'a la main' est dépréciée ? C'est _exactement_ la même methode que fait le script....
Tiens, la puissance des clés RSA, tu connais le DSA aussi ?
Port pas défaut c'est mieux... qu'est ce qu'il ne faut pas lire... Le brute-forceur il s'en fout royalement, il te nmap la tronche et ton port 'different' aura servi a rien.
Petit tip, tu aurrais lu la doc tu aurrais trouvé la variable 'User' pour eviter de taper 'user_truc'.
Ah, et tu chercherais vraiment la 'sécuritée' tu utiliserais plutot des logiciels comme Fail2Ban plutot que des conneries de changements de ports.
Et tu modifie la config pour ... mettre par defaut une valeur deja par defaut (puis-je te décerner le trophé de l'edition la plus inutile de l'année ?).
Tu ne modifie pas le AllowRootLogin pour le mettre a no (c'est a yes par defaut sous debian, vive la 'sécuritée' hein ?).
Ah et aussi, tu ne désactive pas le login par password, donc le brute-forceur continuera de s'amuser a trouver ton mot de passe, qui, de toute facon, ne dépasse surement pas 5 chars et ne contient que des lettres :)
Pour éviter de taper encore quelques caractères:
en desous d'une ligne avec Host server et plus besoin du nom.
Si le serveur a un nom à rallonge genre server.domaine.fr, on peut mettre
En résumé si vous avez dans .ssh/config quelque chose comme
et il suffira de taper
en lieu et place de
Mon commentaire n'est pas passé ? L'auteur pratiquerait-il la censure ou ne veux pas avouer ses fautes ?
Très pratique comme méthode.
Malheureusement c'est incompatible avec la sécurité que j'ai mis en place sur mon serveur. En fait le seul login que mon OpenSSH autorise, c'est sur un compte extrêmement limité. Aucun droit de lecture/écriture, pas de dossier perso.
Et donc pas possible de copier la clé dans son home folder puisqu'il n'existe pas.
Bonsoir,
J'ai reçu plusieurs commentaires, et je vais essayer d'y répondre ;-)
Mais avant toute chose, je tenais à vous remercier de vos contributions par l'intermédiaire des "commentaires". En effet, vos différents commentaires me permettent ainsi de comprendre mieux l'enjeux qu'est le domaine de la sécurité. Vous avez sû m'avertir sur ses différents dangers.
@bapt, Effectivement, grosse erreur de ma part, je n'avais pas vu l'application sous cet angle, j'ai corrigé le billet en concéquence.
@rhaamo, vu le commentaire, procédons, pas à pas.
Mauvais terme employé dans mon billet, je remplace par "méthode manuelle" Je connais ce type de chiffrement, mais pris dans la précipitation de la rédaction du billet, je n'y ai pas fait mention. Voilà chose faite maintenant. Un billet sur Fail2Ban pourrai être en effet très intéressant pour compléter ce billet. Tu parles du authorized_keys ? par défaut, elle est commenté sur Debian 5 en tout cas. Par défaut, encore sous Debian 5, elle est à "without-password', mais j'ai pris compte de ta remarque afin d'en avertir les lecteurs. Cela dépends de chacun, si la machine a d'autre comptes qui eux ne sont pas protégé par une clé ssh, on va être dans l'impasse.Pour le brute-forceur, le billet ne s'y prête pas, mais, je plussoie une nouvelle fois, la création d'un billet concernant Fail2Ban. Je ne connaissais pas, il y a également @than qui m'a fait part de cette remarque.
@than,
j'y fais référence juste au dessus avec @rhaamo, je ne connaissais pas les autres petits arguments. Merci, c'est ajouté au billet.
@rhaamo,
Aucunement, comme je te l'ai fais savoir par voie de mail, je voulais corriger mon billet "rapidement" afin d'éviter d'avoir les mêmes remarques.Et ensuite, au cas par cas, vous le faire savoir. Aucune censure, et encore moins une quelconque fierté de corriger le billet sans publier vos commentaires.
Un blog est avant tout un moyen de partage de connaissance.
Au plaisir de vous lire à nouveau.
Mickaël.
J'ai survoler ton article car je connais un peu le sujet. Mais par contre j'adore lire les commentaires...
Il est vrai qu'il faut rappelé que cette méthode ajoute en rapidité mais fait perdre de la sécurité. Mais bon faut pas non plus exagérer et puis on peu le dire gentiment, quand on voix la réaction de rhaamo, c'est du grand n'importequoi. Oui il a raison mais cool les enfants, pas besoin d'être désagréable, on est tous la pour apprendre. L'intervention de than est bien plus constructive. Un peu d'humanité dans ce monde de machine ça fait pas de mal. Donc merci pour ton article et oui attention à la sécu ;)
Bonjour,
Merci pour ce billet, toujours utile.
Je voulais surtout réagir aux commentaires :
Ok, certains sont des gurus d'unix, de Gnu/Linux, de la sécurité. Par contre ils ne sont pas les rois de la bienséance, voire du minimum du savoir vivre. Je dirais même qu'ils sont bouffis d'arrogance qui n'a d'égale que leur prétention. La façon de parler de certains, en commentaire, à votre article est tout simplement lamentable.
Donnez de la force à vos connaissances, puisque vous êtes plus avancés, dites le sans cette arrogance malsaine qui ne donne absolument pas envie de vous lire ou de vous écouter.
Je félicite l'auteur du blog pour son calme.
À méditer pour certains: «Les remarques des fautes d'un ouvrage se feront avec modestie et civilité, et la correction en sera soufferte de la mesme sorte.»
Cordialement.
Bonjour,
Merci à Nico ainsi qu'à Tyler Durden pour vos commentaires.
Chaque individu a son propre idéal de la communication. Certains pour faire passer un message vont y ajouter un soupçon d'empathie d'autres moins voir pas du tout. Ajoutons à ceci, le syndrome de la génération Y (dont je fais partie); une impatience à toute épreuve.
J'ai en effet, pour nature d'être calme, et surtout de me demander "pourquoi tel ou tel réponse est rédigé de telle manière".
C'est alors, à notre tour (comme vous l'avez très bien fait) d'y répondre, et d'y ajouter cette fameuse "empathie" ;-)
Pour clôturer ce commentaire, je rajouterai une citation que j'aime beaucoup.
Tout ceci pour résumer, qu'un billet vu de long en large, ne sera jamais figé dans le temps au vu des expériences suivantes.Il y aura toujours matière à améliorer ou affiner.
Bien cordialement,
Mickaël.
Bonsoir,
Les gurus grognons devraient nous présenter - avec calme et détails - que faire dans le cas suivant :
J'ai ma clef sur mon disque dur, qui vient de cramer. J'achète un nouveau hd, zut j'ai pas de backup de ma clef...et bien sur j'ai interdit l'accès à mon serveur par mot de passe simple...je fais quoi ?
Cordialement.