- Configurer un serveur Web sous Linux – Guide complet
- Authentification SSH par clé
- Sécurisation du serveur SSH
- Sécurisation serveur – réseau et services
- Bash – paramétrage du shell
- Debian – Mise à jour du système et Dotdeb
- NTP – Synchroniser l’heure de son système avec un serveur de temps
- Installation d’Apache 2 et PHP5
- Installation de nginx – le serveur Web hautes performances
- PHP-FPM – Installation et configuration
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.
16 réponses pour "Authentification SSH par clé"
26 janvier 2011 @ 8:59 1
Pas mal Papy, c’est assez HARD quand même!
26 janvier 2011 @ 10:53 2
@Destructor – Oui, enfin cependant, c’est très didactique, et plutôt clair.
Vivement la suite.
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.
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é.
26 janvier 2011 @ 14:35 5
Merci Papy pour toutes ces précisions
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.
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
26 janvier 2011 @ 18:57 8
un grand merci !!!
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.
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.
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}
02 février 2011 @ 10:45 12
PS: Correction commentaire précédent:
chmod 600 /home/${USERNAME}/.ssh/authorized_keys
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é.
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 ;-)
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
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.