Configurer le service SSH avec uniquement l’authentification par paire de clés privée/publique (Linux)

Publié par Geoffrey Sauvageot-Berland le

Dans ce billet, nous allons aborder la configuration de l’authentification par clés SSH (publique/privée). Elles représentent un moyen sûr de se connecter à votre serveur et sont recommandées en matière de politique de sécurité.

Environnement

  • Machine cliente : Kalilinux 2020.1 – IP : 192.168.145.129/24
  • Serveur Linux : Ubuntu 20.04 – IP 192.168.145.160/24

Etape 0 – Création de la paire de clés RSA

Par défaut, sur les OS Linux récent, vous pouvez exécuter la commande ci-dessous pour générer votre couple de clés publique/privée avec une taille de 4096 bits.

ssh-keygen -t rsa -b 4096

Une fois que votre clé est générée, vous devriez visualiser un résultat similaire à la photo ci-dessus. Vos clés sont stockées ici :

/home/Votre_user/.ssh/id_rsa
# ou l'utilisateur pour root ->
/root/.ssh/id_rsa

Vous disposez désormais d’une clé publique et privée que vous pouvez utiliser pour vous authentifier. L’étape suivante consiste à placer la clé publique sur votre serveur afin que vous puissiez utiliser l’authentification basée sur la clé SSH pour vous connecter.

Attention, ne jamais communiquer votre clé privée, mais seulement votre clé publique (comme son nom l’indique…) !

Etape 1 Envois de la clé publique sur le serveur Ubuntu

Nous allons utiliser l’utilitaire appelé ssh-copy-id. En raison de sa simplicité, cette méthode est fortement recommandée si elle est disponible. (Sous entendu : si vous ne disposez d’une distribution Linux trop ancienne 🙂 ). L’utilisateur « user », devrait disposer de privilèges administrateur (via sudo)

ssh-copy-id [email protected]

Vous verrez peut-être le message suivant :

Cela signifie que votre ordinateur local ne reconnaît pas l’hôte distant. Cela se produira la première fois que vous vous connecterez à un nouvel hôte. Tapez « yes ». Vous serrez alors invité à rentrer le mot de passe de l’utilisateur « user » du serveur distant.

Une fois l’authentification, réussi vous visualisez le message de confirmation suivant :

Maintenant, essayez de vous connecter à votre serveur et vous verrez que vous n’allez pas avoir besoin de renseigner un mot de passe.

Etape 2 – Désactivation de l’authentification par mot de passe « classique » sur votre serveur

Votre mécanisme d’authentification par mot de passe est toujours actif, ce qui signifie que votre serveur est toujours exposé aux attaques par force brute. Pour remédier à ce problème de sécurité, nous allons désactiver cette option.

Cette étape permettra de verrouiller les connexions par mot de passe, et d’autoriser uniquement les connexions SSH par couple de clé publique/privée. Il est donc essentiel de s’assurer que vous pourrez toujours obtenir un accès administratif / physique au cas où.

# Sur votre serveur distant : 
sudo nano /etc/ssh/sshd_config

Dans le fichier, recherchez une directive appelée PasswordAuthentication. Elle est commentée par défaut. Décommentez la ligne et réglez la valeur sur « no ». Cela désactivera votre capacité à vous connecter via SSH en utilisant des mots de passe de compte :

Sauvegardez le fichier, puis redémarrez votre service ssh.

sudo systemctl restart ssh

Par mesure de précaution, ouvrez une nouvelle fenêtre de terminal, depuis votre machine cliente et vérifiez que le service SSH fonctionne correctement avant de fermer cette session :

ssh [email protected]

Une fois que vous avez vérifié que tout fonctionne normalement, vous pouvez fermer en toute sécurité toutes les sessions de serveur en cours.

Le service SSH sur votre serveur Ubuntu ne répond désormais plus qu’aux clés SSH. L’authentification par mot de passe a été désactivée. Pour prouver mes dires, tentez de vous connecter à votre serveur depuis une autre machine.

Le message parle de lui-même 🙂

++

Brlndtech


En savoir plus sur Le Guide Du SecOps

Subscribe to get the latest posts sent to your email.


Geoffrey Sauvageot-Berland

Ingénieur diplômé par l’état en Informatique et Cybersécurité. Généraliste, à l'origine administrateur systèmes et réseaux, j’occupe actuellement un poste d’auditeur en sécurité offensive. J’apprécie également la programmation/automatisation. Fondateur du blog : "Le Guide du SecOps", anciennement "Le Guide du SysOps"

En savoir plus sur Le Guide Du SecOps

Abonnez-vous pour poursuivre la lecture et avoir accès à l’ensemble des archives.

Continue reading