open-ssh-logo

Guide Debian 7 (partie 2/8) : sécuriser l’accès SSH

Temps de lecture : 4 minutes

Cet article fait partie d’une série de billets portant sur la mise en place d’un serveur sous Debian Wheezy (voir le sommaire).

Introduction

De la même façon que vous ne laissez pas la porte ouverte en sortant de chez vous, la porte d’entrée de votre serveur, c’est-à-dire l’accès SSH, requiert un minimum de sécurisation.

Modifier le mot de passe root

En général, après la commande d’un serveur dédié ou virtuel, votre prestataire vous transmettra les informations de connexion par mail, en y joignant le mot de passe du compte root. Il est important de changer celui-ci immédiatement dès votre première connexion.

Pour cela, lancez la commande suivante en root :

Je ne vous ferai pas l’affront de vous expliquer pourquoi un mot de passe suffisamment complexe pour ne pas être trouvé pas une attaque de type bruteforce ou dictionnaire est très largement souhaitable 🙂

Ajout d’un nouvel utilisateur

Pour la suite, et pour des raisons de sécurité évidentes, nous n’utiliserons pas le compte root pour les connexions à distance. C’est pourquoi nous allons créer un groupe contenant des utilisateurs qui seront autorisés à se connecter via SSH.

On créé ensuite un nouvel utilisateur puis on l’ajoute au groupe qui sera autorisé à se connecter via SSH.

Configuration de ssh

On commence par changer le port par défaut :

Note : Vous pouvez utiliser n’importe quel port, pour peu que celui-ci ne soit pas réservé par un autre service. Avoir un port non standard vous permettra d’éviter une partie des attaques automatisées que l’on rencontre chez certains prestataires . Et comme j’entends déjà les experts hurler, je précise que oui, l’obscurantisme n’est en aucun cas un gage de sécurité. Toutefois, je peux vous assurer qu’un simple changement de port sur une dedibox permet de souffler un peu au niveau des tentatives de bruteforce SSH (les IP des machines sont connues et les scripts kiddies s’en donnent à coeur joie). Pour conclure, n’oubliez jamais qu’un attaquant qui se focalisera sur votre serveur n’aura aucun mal à déterminer sur quel port tourne le daemon SSH.

Le compte root n’est pas autorisé à se connecter directement depuis SSH :

Seul les utilisateurs appartenant au groupe sshusers sont autorisés à se connecter (il faut ajouter cette ligne) :

on vérifie que la version 2 du protocole est utilisée :

On redémarre le daemon SSH :

À ce stade, ne surtout pas fermer l’ancienne connexion, au risque de ne plus pouvoir se reconnecter par la suite. Ce que je vous conseille, c’est d’ouvrir un nouvel onglet dans votre terminal et de tester la connexion avec le port et l’utilisateur adéquat.

Authentification par un système de clé publique/clé privée

L’authentification par clé publique/privée se révèle pratique dans le cas où vous souhaitez ne pas avoir à taper le mot de passe à chaque connexion.

Cette technique permet de renforcer la sécurité, car elle demande à l’utilisateur d’être en possession de deux informations pour se connecter au serveur (une clé privée et le mot de passe de cette clé).

Je ne détaillerai pas ici le fonctionnement du protocole, sachez juste que nous allons avoir besoin de deux choses :

  • une clé privée, que l’on gardera précieusement sur notre ordinateur, dans le dossier .ssh de notre répertoire personnel
  • une clé publique, que l’on enverra dans le dossier .ssh de l’utilisateur sur le serveur

Pour générer tout ça, rien de plus simple, il suffit de lancer la commande suivante sur votre ordinateur .

Répondre aux questions :

La phrase de passe (ou passphrase) sert en fait à décrypter votre clé privée. Il est possible de ne pas en mettre, mais dans ce cas, une personne qui mettrait la main sur votre clé privée serait tout à fait apte à se connecter au serveur. Bref, il serait idiot de se priver d’une protection supplémentaire, donc choisissez un mot de passe avec soin.

Il faut maintenant copier la clé publique dans le répertoire .ssh de votre utilisateur (celui avec lequel vous vous connectez sur le serveur) :

Pour cela, lancer la commande suivante depuis votre ordinateur :

Note : il se peut que le répertoire .ssh n’existe pas dans le home de votre utilisateur sur le serveur. Il suffit de se connecter sur celui-ci et de le créer :

Si tout s’est bien passé, vous devriez être en mesure de vous connecter au serveur en utilisant le système de clé. À la première connexion, le mot de passe servant à décrypter la clé privée vous sera demandé. Sur OSX, le système vous proposera de l’enregistrer dans le trousseau d’accès. Sous un système Linux, il est possible qu’il en fasse de même (sinon, utilisez ssh-agent pour ne pas avoir à retaper ce mot de passe).

Si vous le souhaitez, vous pouvez aussi utiliser uniquement le système de clés pour vous connecter au serveur en passant le paramètre PasswordAuthentication sur no dans le fichier /etc/ssh/sshd_config. De ce fait, seule une personne possédant la clé privée et son mot de passe sera apte à se connecter. Cependant, si jamais vous perdez cette clé, vous serez incapable de vous connecter par la suite. Faites donc attention si vous optez pour cette solution

Rendez-vous demain pour la troisième partie de ce guide qui portera sur l’envoi de mail depuis votre serveur 🙂

Tags :

Réagissez à l'article

  • Arimaze

    Bonjour,

    Super j’ai lu et utilisé tous les tutos , merci pour tout ce travail !!

    J’aurais une question concernant l’authent clé privée.

    Est ce normal qu’à chaque connexion je dois rentrer la passphrase ? je n’ai pas trop bien compris

    Cordialement,

    • https://twitter.com/robin_parisi Robin

      Salut Arimaze,

      Oui c’est normal. Sur OSX, le trousseau d’accès se charge de garder en mémoire la passphrase et sur Linux, il faut utiliser ssh-agent. Concernant Windows, j’imagine qu’il existe une solution pour sauvegarder la passphrase avec PuTTY.

      • Flo

        Salut,
        effectivement, il existe une solution avec PuTTY,
        vous pouvez utiliser Pageant (disponible dans la “suite” PuTTY) qui vous permettra d’ajouter/supprimer/editer vos clefs

        • https://twitter.com/robin_parisi Robin

          Merci pour les précisions 🙂

  • didier

    Bonjour, j’ai suivi et exécuté la première partie pour mon serveur. Cela fonctionne, pas de problème. Je ne peux plus me connecter en root .
    Question: comment faîtes-vous pour revenir en arrière, c’est à dire en root seulement car en me connectant avec mon nouvel user, je ne peux plus modifier certains fichiers de configuration en SSH. Et là , c’est le bordel dans le serveur …..
    Cordialement

    • https://twitter.com/robin_parisi Robin

      Bonjour Didier,

      c’est normal, il faut repasser en root pour avoir la permission d’éditer les fichiers de configuration avec la commande “su – “

      • didier

        Bonjour robin, pour repasser en root je fais

        useradd -m root
        passwd root
        usermod -a -G sshusers root
        ?

      • didier

        mais dans mon fichier sshd_config j’ai

        PermitRootLogin no

        • https://twitter.com/robin_parisi Robin

          La directive “PermitRootLogin no” empêche juste le compte root de se connecter directement en SSH mais ne le désactive pas une fois sur le serveur. C’est pour cela qu’il faut d’abord se connecter avec un utilisateur normal puis passer en SSH avec la commande “su -“.

          • http://www.anthonymolinadiaz.net Anthony Molina-Diaz

            Bonjour,

            Dans ce cas, je ne saisis pas bien la raison pour laquelle il faille empêcher l’utilisateur root de se connecter via SSH … puisqu’un pirate qui parviendra à se connecter à un compte du groupe “sshusers” pourra exécuter des commandes en root grâce au “su -“. Je me trompe ?

          • https://twitter.com/robin_parisi Robin

            Pour cela il faudrait que le pirate dispose du mot de passe du compte root. Le groupe sshusers n’est rien de plus que le groupe des utilisateurs autorisé à se connecter via ssh.

  • Hugo B.

    Je te remercie, c’est tout simplement génial ! J’ai dû aller chercher quelques explications (pas grand chose je te rassure) à quelques questions concernant cette manip 😉

    Par contre très important: Indique dès le début que cette manip est à effectuer de bout en bout plutôt que le préciser en milieu de manip’ 😉

    • Hugo B.

      petite question bête: si je crée un autre user je peux utiliser le même port ?

      • https://twitter.com/robin_parisi Robin

        Salut Hugo,

        Oui le port est indépendant de l’utilisateur.

        Bien noté pour l’avertissement sur la connexion SSH à conserver que je déplacerai en début d’article.

        • Hugo B.

          Hello Robin,

          Certainement la dernière question, on verra bien:

          Lorsque je passe la commande “sudo”, normal il me demande le mot de passe du nouvel utilisateur:

          [sudo] password for [user]:
          Sorry, try again.

          [sudo] password for [user]:
          [user] is not in the sudoers file. This incident will be reported.
          [sudo] password for [user]:-sh: 2: [user]: not found

          Et là suis perdu parce que je ne comprend pas, i need help please.

          • https://twitter.com/robin_parisi Robin

            C’est normal, par défaut, Debian n’utilise pas sudo.

            Pour te connecter avec le nouvel utilisateur il faut faire :

            su – utilisateur

            Et pour passer en root :

            su –

          • Hugo B.

            Tks pour les infos !
            Je change de sujet parce qu’un débutant ça pose tjs plein de questions non ordonnées 😉
            Tu ne saurais si je peux installer sublime text 3 même si je n’ai que le terminal (pas d’interface) d’installer sous debian 7 ?

          • Hugo B.

            Pour te prouver que ce n’est pas ordonné: Depuis que le root n’est “plus autorisé à se connecter en direct” bèh ma connexion SFTP me fait un doigt… Même en modifiant le login par le nouveau user. As-tu une astuce pour ça ou un lien stp ?

  • Olivier Klem

    Bonjour, je rencontre un problème au moment de copier la clé publique dans le répertoire .ssh de mon serveur distant.
    Lorsque je tape la commande suivante : ssh @ -p “echo $(cat ~/.ssh/id_rsa.pub) >> .ssh/authorized_keys”

    J’obtiens le message suivant :
    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 a host key has just been changed.

    The fingerprint for the RSA key sent by the remote host is

    d2:7c:2b:d9:c8:39:9d:49:9a:ba:cb:a4:d9:87:f7:9d.

    Please contact your system administrator.

    Add correct host key in /home/xxxxx/.ssh/known_hosts to get rid of this message.

    Offending RSA key in /home/xxxxx/.ssh/known_hosts:1

    RSA host key for xx.xx.xxx.xxx has changed and you have requested strict checking.

    Host key verification failed.

    J’ai tenté de faire un ssh-keygen -R mais ça ne change rien.

    Merci de votre aide.

    • https://twitter.com/robin_parisi Robin

      Salut Olivier,

      Tu peux ouvrir ton fichier known_hosts et supprimer la première ligne.

      • Olivier Klem

        Salut Robin, merci pour ta réponse,

        J’ai supprimé la ligne dans mon fichier known_hosts mais j’ai toujours la même erreur…
        🙁

        • Cagazouille

          Essaye ssh-keygen -R