Cet article fait partie de la série Installer un serveur Web - Guide Complet - Article 2 sur 10

Les mots de passe, c’est vraiment trop has-been. Une des premières choses à faire lors de la configuration d’un nouveau serveur est donc de désactiver l’authentification classique par mot de passe pour permettre uniquement une authentification par clé.

Mais avant de se lancer dans la configuration, il faudra deux choses :

  • Créer un utilisateur autre que root pour la connexion au serveur,
  • Générer une paire de clés publique et privée.

Création d’un utilisateur non privilégié

Pour créer l’utilisateur, c’est très simple, il suffit de vous connecter à votre serveur et de taper la commande suivante pour l’utilisateur $USERNAME (avec USERNAME=mon_utilisateur) :

useradd -m -s /bin/bash $USERNAME

Le « -m » indique de créer le répertoire de l’utilisateur (home) qui par défaut se trouve dans /home sur Debian et sur un bon nombre de distributions Linux. Le « -s » permet de préciser le shell de l’utilisateur, ici on utilise bash.

On prépare ensuite les répertoires qui recevront notre clé publique :

cd /home/${USERNAME}
mkdir -p /home/${USERNAME}/.ssh
chown ${USERNAME}:${USERNAME} /home/${USERNAME}/.ssh
chmod 700 /home/${USERNAME}/.ssh

On positionne les droits pour que le répertoire ne soit accessible que pour notre utilisateur. C’est indispensable pour la sécurité du serveur. Il suffit en effet d’avoir accès à ce répertoire pour y rajouter une clé et pour ensuite pouvoir se connecter.
SSH refusera de toutes façons de se connecter si les droits sont trop peu restrictifs.

Génération d’une paire clé privée/clé publique

Si vous êtes sous Linux ou sous Mac OS, vous pourrez générer facilement vos clés en tapant la commande suivante (pour une clé DSA) :

ssh-keygen -t dsa -b 1024
Generating public/private dsa key pair.
Enter file in which to save the key (/Users/papygeek/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/papygeek/.ssh/id_dsa.
Your public key has been saved in /Users/papygeek/.ssh/id_dsa.pub.

Le « -t » précise le type de la clé, vous pouvez choisir rsa ou dsa en général. Pour « -b » il s’agit de la longueur de la clé, 1024 ou 2048 font l’affaire.
La passphrase est la phrase qui sert de mot de passe. Evitez de la laisser vide sinon n’importe qui récupérant votre clé privée pourra se connecter à votre serveur.
La clé privée est alors générée dans ~/.ssh/id_dsa (ou ~/.ssh/id_rsa pour le rsa). Cette clé privée est votre secret, elle devra donc être conservée avec le plus grand soin et surtout n’être dévoilée à personne (c’est le principe d’un secret normalement ;) ).

Votre clé publique est générée dans ~/.ssh/id_dsa.pub. Elle peut être communiquée librement. C’est elle qui permettra au serveur de vous reconnaître. Elle pourrait aussi être utilisée pour par exemple chiffrer des données (comme des mails) que seul vous serez en mesure de déchiffrer (avec votre clé privée).

Si vous avez bien suivi, il reste maintenant à transférer votre clé publique sur le serveur dans le fichier .ssh/authorized_keys du répertoire .ssh que l’on a créé tout à l’heure.

Pour cela, deux solutions : soit vous avez déjà transféré le fichier .pub à la main en SCP, SFTP, FTP ou ce que vous voulez, soit vous avez un Linux/Mac avec la commande ssh-copy-id qui fera le travail à votre place :

ssh-copy-id -i ~/.ssh/id_dsa.pub user@host.com

Ou pour RSA :

ssh-copy-id -i ~/.ssh/id_rsa.pub user@host.com

Si vous avez transféré votre clé à la main, il faudra copier son contenu dans le fichier /home/$USERNAME/.ssh/authorized_keys.

Pensez également à vérifier les droits sur le fichier authorized_keys :

chmod 600 /home/${USERNAME}/.ssh/authorized_keys
chown ${USERNAME}:${USERNAME} /home/${USERNAME}/.ssh/authorized_keys

Vous devriez à ce point pouvoir vous connecter à votre serveur en utilisant votre clé et votre passphrase :

ssh $USERNAME@host.com

Sous Windows, le plus simple est d’utiliser la suite d’outils fourni avec PuTTY. Le Windows Installer a tout ce qu’il faut.

Pour la génération des clés, c’est l’outil PuTTYgen qui est utilisé. Pour cela, je vous conseille de vous référer par exemple à ce guide.
En gros, il suffit de choisir un type de clé (par exemple SSH-2_RSA) et sa longueur (1024), de cliquer sur Generate, de secouer sa souris pour générer de l’aléa, et d’exporter ses clés publiques et privées avec Save Public Key et Save Private Key.

Dans le cadre en haut de la fenêtre, vous verrez votre clé publique OpenSSH que vous devrez simplement copier-coller dans le fichier /home/$USERNAME/.ssh/authorized_keys sur le serveur.

Pour vérifier votre connexion, lancez l’outil Pageant qui vous permettra de charger votre clé privée en mémoire en entrant la passphrase, puis ouvrez la connexion vers votre serveur avec PuTTY qui utilisera alors automatiquement la clé de Pageant. Vous pouvez aussi paramétrer la clé dans les options de la connexion sous PuTTY si vous ne voulez pas utilisez Pageant.

Remarque : les clés générées par PuTTY ou OpenSSH ne sont pas interchangeables, chaque programme ayant sa propre implémentation d’SSH2. Si vous voulez les utiliser d’un système à l’autre, il faudra donc les convertir en passant par exemple par le menu Conversions de PuTTY Key Generator.

Voilà! Vous pouvez maintenant maintenant vous connecter à votre serveur sans trop risquer de vous faire voler votre mot de passe. On verra dans la suite comment désactiver complètement l’authentification SSH par mot de passe, ce qui permet d’éviter les attaques de type brute force sur votre mot de passe de connexion.

Navigation<< Configurer un serveur Web sous Linux – Guide completSécurisation du serveur SSH >>

 


 

16 réponses pour "Authentification SSH par clé"

  1. Destructor  Surfe sur Internet Explorer Internet Explorer 8.0 avec Windows Windows 7
    26 janvier 2011 @ 8:59
    1

    Pas mal Papy, c’est assez HARD quand même!

  2. Coin  Surfe sur Mozilla Firefox Mozilla Firefox 3.6.13 avec Ubuntu Linux Ubuntu Linux
    26 janvier 2011 @ 10:53
    2

    @Destructor – Oui, enfin cependant, c’est très didactique, et plutôt clair.
    Vivement la suite.

  3. Sig'  Surfe sur Opera Opera 9.80 avec Linux Linux
    26 janvier 2011 @ 12:03
    3

    Un tuto fort intéressant mais j’aurais deux petites questions :

    – tu installes Debian avec son interface graphique ou en ligne de commande?
    – Quand on installe Debian il nous propose d’installer automatiquement ces services web, pourquoi ne pas prendre ces options au lieu de le faire pas soit même.

    Question subsidiaire : n’y a t’-il pas une méthode graphique pour faire la même chose que dans ton tuto?

    Je sais, ce sont peut etre des questions un peu bête mais je n’y connais rien en serveur web.

  4. Papy  Surfe sur Mozilla Firefox Mozilla Firefox 4.0b9 avec Mac OS X Mac OS X 10
    26 janvier 2011 @ 13:25
    4

    @Sig’ – je n’utilise jamais d’interface graphique sur un serveur Web, histoire de ne pas l’alourdir et parce que je n’en ai pas réellement le besoin. (Je n’utilise aucun outil ayant besoin d’un serveur X).

    Pour l’installation automatique des services Web, j’aime autant éviter comme ça je sais exactement ce que j’installe (ou n’installe pas), l’idéal étant de n’installer que les services dont on a réellement besoin. Ensuite, il y a beaucoup d’outils pour faire ces installs pré-packagées : outil intégré à la distribution, distributions pré-packagées fournies par les différents hébergeurs (OVH, Online,…), etc., du coup finalement l’installation « à la main » est peut-être ce qui est le plus facilement généralisable, sachant que c’est tout de même ultra-simple avec les gestionnaires de paquets intégrés aux distributions genre apt ou yum.

    Pour la méthode graphique, il y a énormément d’outils disponibles et j’avoue ne m’y être jamais vraiment intéressé. Là encore je trouve que cela « masque » un peu ce que l’on fait (même si ça masque aussi la complexité ;) ) et les fonctions dispos sont au bon vouloir de ces panels. Si ça t’intéresse quelques noms : Plesk, VHCS, DTC… Là aussi les hébergeurs fournissent souvent des distributions avec un panel installé.

  5. Sig'  Surfe sur Opera Opera 9.80 avec Linux Linux
    26 janvier 2011 @ 14:35
    5

    Merci Papy pour toutes ces précisions :)

  6. Aikadil  Surfe sur Google Chrome Google Chrome 6.0.472.53 avec Ubuntu Linux Ubuntu Linux
    26 janvier 2011 @ 14:53
    6

    Oui en règle général l’installation de l’OS n’est pas nécessaire. Quand on loue un serveur privé il y a généralement le choix du système d’expoitation, soit prêt à l’emploi soit vide.

    typiquement une debian vide sans services installer sauf SSH par mot de passe, il faut installer et configurer tout le reste.

    Le cas ou il faut installer sois même le système d’expoitation c’est dans le cas du hosting, ou on ne loue pas un serveur mais un espace dans une baie ou l’on installe sa ou ces propore machines. on ne loue donc plus que l’espace dans la aie, sa consommation élèctrique et son accès symetrique à l’internet.

  7. ze0ne  Surfe sur Google Chrome Google Chrome 8.0.552.237 avec Windows Windows XP
    26 janvier 2011 @ 17:06
    7

    J’utilise cette technique depuis un moment et je dois avouer, que si à l’époque j’étais tombé sur un article aussi complet, j’aurai surement gagner un temps précieux :)

  8. fredo  Surfe sur Mozilla Firefox Mozilla Firefox 3.6.13 avec Windows Windows 7
    26 janvier 2011 @ 18:57
    8

    un grand merci !!!

  9. Astral God  Surfe sur Mozilla Firefox Mozilla Firefox 3.6.13 avec Windows Windows 7
    01 février 2011 @ 0:17
    9

    Bonsoir. Juste une petite précision, pourquoi l’un ou l’autre ?

    « dans le fichier .ssh/authorized_keys2 (ou .ssh/authorized_keys) »

    Merci pour vos réponses.

  10. Papy  Surfe sur Mozilla Firefox Mozilla Firefox 4.0b10 avec Mac OS X Mac OS X 10
    01 février 2011 @ 13:11
    10

    @Astral God – Bonne remarque, en fait on est même plus censé utiliser authorized_keys2, maintenant tout est dans authorized_keys. Merci pour la question, j’ai modifié l’article.

  11. Astral God  Surfe sur Mozilla Firefox Mozilla Firefox 3.6.13 avec Windows Windows 7
    02 février 2011 @ 10:44
    11

    De même, c’est peut être « pointilleux », mais ajouter un

    chmod 600 /home/${USERNAME}/.ssh

    ne fait pas de mal, la clef n’ayant besoin que d’être lue et écrite par ${USERNAME}

    ;)

  12. Astral God  Surfe sur Mozilla Firefox Mozilla Firefox 3.6.13 avec Windows Windows 7
    02 février 2011 @ 10:45
    12

    PS: Correction commentaire précédent:

    chmod 600 /home/${USERNAME}/.ssh/authorized_keys

  13. Papy  Surfe sur Mozilla Firefox Mozilla Firefox 4.0b11 avec Mac OS X Mac OS X 10
    13 février 2011 @ 19:34
    13

    @Astral God – j’avais bien ça dans mes scripts, mais pas dans l’article, merci j’ai corrigé.

  14. Bertrand  Surfe sur Google Chrome Google Chrome 13.0.782.107 avec Mac OS X Mac OS X 10.7.0
    01 août 2011 @ 18:59
    14

    Petite précision pour ceux qui sont sous OSX. La commande sss-copy-id n’est pas forcément présente (Leopard notamment). Voilà un billet qui explique comment la mettre : http://www.mikaelrandy.fr/2010/07/16/utiliser-la-commande-ssh-copy-id-depuis-mac-osx-2/. Allez je poursuis ma configuration ;-)

  15. Tex  Surfe sur Google Chrome Google Chrome 7.0.529.0 avec Windows Windows XP
    17 août 2011 @ 3:48
    15

    Je de-terre un peu l’article, car j’ai une question sur l’utilité de la méthode. Je poste ici en espérant avoir une réponse plus claire. Peut-être je n’ai pas bien compris la théorie, mais je me lance quand-même.

    Quel est le réel avantage des clés vs mot de passe ? En quoi le mdp est has-been ? Au mois celui là, il n’ya que moi qui le connait ! Ok, pour le brute-force, je comprends, ne pas avoir a rentrer son mdp a chaque fois, ça aussi je comprends, mais niveau sécurité ?

    Si j’installe les clés sur mon poste (au boulot par exemple, ex. Win XP + Putty etc.) pour avoir accès a mon serveur (ex OVH), qui empêche que toute personne pouvant se connecter à mon poste, (admin réseau y compris) aura directement accès au serveur ssh pré-configuré avec les clés ?

    Ok, le compte n’est pas root, mais il sera tt de même connecté a la machine en ssh.

    Éclairez moi si j’ai loupé une case .

    Merci d’avance.

    dsl pour le mail

  16. Papy  Surfe sur Internet Explorer Internet Explorer 8.0 avec Windows Windows XP
    17 août 2011 @ 10:41
    16

    @Tex – tu as besoin de ta clé privée pour te connecter à ton serveur. La protection de l’accès à ton serveur dépendra donc de la protection de cette clé.

    Niveau sécurité, il y a deux choses différentes : côté serveur, il va être très difficile (ou impossible à l’heure actuelle) de faire du brute-force sur ton mot de passe.

    Côté client, effectivement le certificat est sur ton poste, mais heureusement tu as la possibilité de protéger ta clé avec une passphrase, donc même si quelqu’un a accès à ton poste et à ta clé, il ne pourra pas se connecter sans ta passphrase.

    L’idéal étant évidemment que personne ne puisse accéder à ta clé.

    Tu as pu rater l’histoire de passphrase pour plusieurs raisons : déjà elle n’est pas obligatoire (on peut laisser le champ vide, voir plus haut sur les captures), et ensuite on peut aussi enregistrer sa passphrase avec des outils du genre PuTTy Agent ou ssh-agent sur le poste pour ne pas avoir à la taper à chaque fois.

Un jour, PapyGeek s'est décrotté le nez, depuis, la Lune existe. +