Comment se connecter en SSH sans mot de passe

15 Commentaires

Le protocole SSH permet de se connecter sur une machine distante de manière sécurisé grâce à la cryptographie asymétrique. SSH est largement utilisé par les administrateurs systèmes, car il est simple à mettre en place et très puissant.
Néanmoins, par défaut on doit utiliser un mot de passe pour s’authentifier sur un ordinateur distant avec SSH. Ce n’est pas très contraignant si vous avez un seul serveur, mais si vous avez plusieurs machines avec le besoin de faire des scripts pour automatiser certaines tâches, ça devient compliqué pour 2 raisons. La première, c’est que ce n’est pas évident de « scripter » une connexion SSH avec un mot de passe. La deuxième, c’est que ça n’est pas du tout sécurisé puisque le mot de passe est en dur dans le code.
Dans ce tutoriel, nous allons voir comment mettre en place un système de clé publique/clé privée pour se connecter sans mot de passe de manière sécurisé.

Génération des clés

La première étape consiste à générer les clés SSH (une publique, l’autre privée). Connectez-vous sur votre station de travail avec le même utilisateur que vous utilisez habituellement. Lancer un shell et tapez la commande :

ssh-keygen -t rsa

On vous demandera plusieurs choses.

  • Enter file in which to save the key : on vous demande de choisir le nom de la clé privée. Si c’est la première fois que vous faites ça, vous pouvez laisser le choix par défaut. Dans le cas contraire, vous aurez probablement un message vous indiquant que le fichier id_rsa existe déjà.
  • Enter passphrase (empty for no passphrase) : ce choix dépend de la sécurité de votre station de travail. La passphrase permet de chiffrer la clé privée pour éviter de vous la faire voler. Si votre station de travail est sûr, appuyez 2 fois sur entrer pour ne pas mettre de passphrase. Dans le cas contraire, ajouter votre mot de passe, sachant qu’il faudra faire une étape supplémentaire après.

Si tout se passe bien, vous devez avoir une « randomart image » (une sorte de petit dessin symbolisant votre clé) qui apparaît. À partir de ce moment, vous devriez avoir 2 nouveaux fichiers :

  • ~/.ssh/id_rsa : la clé privée (qui doit absolument rester secrète)
  • ~/.ssh/id_rsa.pub : la clé publique que vous allez envoyer sur le serveur

Envoi de la clé publique sur le serveur

Pour que l’identification fonctionne, il faut envoyer la clé publique sur le serveur et garder la clé privée sur la station de travail.

Explication du système de clé SSH

Explication du système de clé SSH

Pour envoyer un fichier sur le serveur, le plus simple reste d’utiliser scp. Voici un exemple :

scp ~/.ssh/id_rsa.pub root@ipServeur:/root/.ssh/

En premier argument, le fichier à envoyer (id_rsa.pub), ensuite le nom d’utilisateur et l’ip du serveur (à la manière de SSH) suivi de l’endroit ou placer le fichier. Si vous avez changé le port par défaut de SSH (22), vous pouvez le préciser avec l’option « -P » de scp.

Normalement, on doit renommer la clé publique (id_rsa.pub) en authorized_keys2 sur le serveur. Cependant, si ce fichier existe déjà, vous risquez de le supprimer. Voici une astuce pour ajouter le contenu de votre clé publique à la fin du fichier authoried_keys2 pour éviter ce problème :

ssh root@votreServeur -p votrePortSSH
cd /root/.ssh
cat id_rsa.pub >> authorized_keys2

Voilà, normalement ça fonctionne ! Vous pouvez le tester en vous connectant par SSH sur votre serveur, aucun mot de passe ne vous sera demandé. Cependant, si vous avez ajouté une passphrase, il y a une étape supplémentaire pour éviter de l’écrire à chaque fois.

Passphrase

Tout ceux qui ont ajouté une passphrase (qui permet de chiffrer le fichier id_rsa), doivent toujours taper un mot de passe pour se connecter. Heureusement, il existe un logiciel qui fait ça pour nous.

ssh-agent $BASH
ssh-agent add
(Tapez votre passphrase)

Dorénavant, SSH ne vous demandera plus votre passphrase, ssh-agent s’en occupera pour vous.

Bonus

Pour faire une liste des clés gérées par ssh-agent :

ssh-add -l

Pour supprimer toutes les clés de ssh-agent :

ssh-add -D

Pour supprimer une clé spécifique sur ssh-agent :

ssh-add -d cle

Si vous avez changé le port par défaut de SSH sur votre serveur, vous devez le spécifier à chaque fois avec l’option -p du client SSH. Ce n’est pas spécialement pratique, mais vous pouvez modifier le fichier ~/.ssh/config pour changer le port par défaut :

Host serveur1
Hostname nomDeDomaineDeVotreServeur.fr
Port 2222
User utilisateurServeur

Avec ce fichier, vous préciser le nom d’utilisateur qui se connecte sur votre serveur, le nom de domaine de votre serveur et le port SSH utilisé. Ainsi, vous n’aurez plus qu’à taper :

ssh serveur1

Si vous avez d’autres astuces sur SSH, n’hésitez pas à les partager en postant un commentaire en dessous ;)

Publié le 8 avril 2012 par Madrzejewski Alexis dans Serveur Dédié

Vous avez aimé ce billet ?

Inscrivez-vous au Flux RSS du blog, suivez-moi sur Twitter ou partager simplement cet article avec vos amis sur Twitter ou Facebook

Inscrivez-vous à la newsletter

Inscrivez-vous à la newsletter en précisant votre prénom et votre adresse email pour recevoir les dernières mises à jour du blog et des tutoriels exclusif par email (En savoir plus)

15 commentaires

Ajouter un commentaire

  1. jonas39

    Salut un petit coût de pouce d’une personne qui a pas mal suivie tes tuto sur les serveurs dédiés.
    Pour éviter les connections avec root sans un mot de passe et utiliser juste une cle de cryptage dans sshd_config :
    PermitRootLogin without-password
    Et il ne faut pas oublier de le rajouter dans la liste de AllowUsers.

    Répondre
  2. Salut Alexis,
    Juste un petit complement aussi pour ceux qui aurait le problème.
    Si à la fin du tuto le serveur vous demande toujours un mot de passe c’est que vous avez surement oublié de spécifier la clef privée à utiliser (si différente de id_rsa).

    Il faut utiliser ssh -i ~/.ssh/ma-clef-priv login@serveur.
    Vous pouvez aussi compléter le fichier ~/.ssh/config donné par alexis en ajoutant l’option IdentityFile ~/.ssh/ma-clef-priv

    Voila en espérant que ce commentaire puisse servir.

    Répondre
  3. Merci pour ce commentaire!!! je bloquais justement mais sans comprendre où venait le soucis

    Répondre
  4. aburayane

    Bonjour,

    Merci pour le tuto, je pense qu’il faut redemarrer le service SSH apres reconfiguration des parametres du sshd_config, petit eclaircissement:

    cat id_rsa.pub >> authorized_keys2

    la clef serait ajoute au fichier authorized_keys2, je pense qu’il faut decommenter la ligne sur le fichier sshd_config cote serveur:

    # Authentication:
    PermitRootLogin no
    AllowUsers toto tata

    RSAAuthentication yes
    PubkeyAuthentication yes
    AuthorizedKeysFile %h/.ssh/authorized_keys2

    Merci

    Répondre
  5. noham

    bonjour Alexis je tiens à te féliciter pour tes magnifiques videos
    je voulais avoir un avis concernant l’hebergement dédié je souhaiterai heberger plusieurs sites internet pour des sites e-commerces (prestashop) et des sites communautaires et evenementiels) que me conseilles tu comme hebergement dédié sur OVH je te remercie d’avance

    Répondre
    • Bonjour Noham,

      Difficile de répondre sans plus d’infos :).
      En réalité, ce n’est pas le nombre de sites qui est important, mais le nombre de visiteur que tu accueilleras simultanément.
      Tu peux faire 30 sites, mais si sur ces 30 sites tu as 1000 visites par jour, ce n’est pas énorme.

      Pour te donner un ordre d’idée, sur un Kimsufi 2G, j’héberge 4-5 sites qui cumulent moins de 2000 visiteurs uniques par jour.

      Répondre
      • noham

        en fait sur le site e-commerce je prévois 30 000 visites par jour
        et sur les sites événementiels il yen a 10 chaque site in prévoit 50 000 visites par jour au moins penses tu que sur un Kimsufi 2G suffira ou je dois prendre la gamme supérieur?

      • Je n’ai pas assez d’expérience dans ce domaine pour te répondre précisement :). Je n’ai connu que l’offre Kimsufi 2G, je ne peux donc pas comparer.

        Cependant, je pense que c’est un peu léger pour autant de visiteurs quand même. Mais comme je te l’ai dit, ce n’est pas réellement le nombre total de visiteur qui compte, mais le nombre de client simultanées.

        La base de données et apache risque de coincer si tu beaucoup de personne qui font des requêtes au même moment.

        Après, si tu veux tenter avec Kimsufi 2G, tu as intérêt à bien optimiser avec un bon cache (Varnish par exemple) et un serveur web plus léger comme Nginx.

  6. newbie

    Excellent site, excellentes vidéos, excellent « prof », un grand merci!

    Répondre
  7. newbieric

    Bonjour et merci pour ce tuto !!!

    D’après ce thread, authorized_keys2 serait deprecated…
    http://forum.kimsufi.com/showthread.php?t=9142
    Le tuto serait-il à mettre à jour ?

    Sinon, j’avais trouvé ce lien via google.. Je me demandais pourquoi mon Kimsufi tout fraichement acheté avait un fichier authorized_keys2 non vide… OVH met-il par ce biais une façon de pouvoir intervenir sur le serveur eb cas de besoin ?

    Merci !

    Répondre
    • Salut newbieric,

      Merci pour l’info du « deprecated », je n’étais pas au courant. En fait, j’avais ce fichier qui existait déjà (car créé par OVH pour leur besoin je suppose) donc j’ai pas trop réfléchi et j’ai ajouté mes clés à la fin de celui-ci :)

      Répondre
  8. Lola

    Merci pour cette astuce.
    Elle peut en effet être pratique dans certains cas.

    Je vais tester ça ;-)

    Répondre
  9. motta

    Bonjour, et merci pour ces tutos !
    Question probablement bête : au moment du ssh-agent $BASH ; ssh-agent add, le termina me répond : add No such file or directory.

    Qu’ai-je loupé ?
    Sans vouloir t’apprendre comment faire :D , tu devrais distinguer les actions côté serveur de celles côté client.

    Merci encore, bonne continuation.

    Répondre

Ajouter un commentaire


Ici les commentaires sont en DoFollow, profitez-en mais en abusez pas !
Veuillez ne pas poster de code (php, html ou autre) car il sera bloqué par le site.
Les commentaires ne sont pas immédiatement validés.
Merci de faire une recherche sur Google avant de poser une question.