top of page
cloud-vds.png
  • 2 Base de données

  • 2 VPS AMD

  • 4 instances ARM

  • Stockage 100 Go

  • 50k appels API

theme-light-dark-white.png

Renforcement de la sécurité du service openSSH avec les clés de chiffrement SSH

Dernière mise à jour : 13 mai 2022

L’authentification par mot de passe est considérée comme un mécanisme faible. Elle peut être soumise à différents types d’attaque comme celles par dictionnaire, par force brute ou encore par Man In The Middle comme nous l’avons vu précédemment.


Il est vivement recommandé de configurer une authentification plus robuste lorsque l'on configure le service SSH, par clés de chiffrement ou encore par double facteur (2FA).


Etape 1 : Configuration de l'authentification à clés sur le service SSH


Pour commencer il est nécessaire d'autoriser les clés SSH dans le fichier de configuration :

sudo nano /etc/ssh/sshd_config

Il faudra rechercher et ajouter la valeur yes à " PubkeyAuthentication " :

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Pour que les changements prennent effet il est nécessaire redémarrer SSH :

service ssh restart

Etape 2 : Génération des clés SSH sur le client


Sur la machine cliente nous allons devoir générer une clé publique, et une clé privée afin de pouvoir s’authentifier sur le serveur SSH :

ssh-keygen -b 256 -t ecdsa

La commande ssh-keygen a généré deux clés :

  • Une clé privée sous $home/.ssh/id_ecdsa à laquelle vous seul devez avoir accès

  • Une clé publique sous $home/.ssh/id_ecdsa.pub, qui peut être partagée


Nous allons maintenant autoriser explicitement la machine cliente à accéder au serveur par SSH. Il faut ajouter la clé publique (id_ecdsa.pub) dans le fichier authorized_keys du répertoire .ssh de l’utilisateur qui sera choisie pour se connecter (ex : /home/$user/.ssh).

La méthode la plus simple est d’utiliser la commande ssh-copy-id mais elle n'est pas disponible par défaut sur Windows. Nous utiliserons donc les commandes suivants sur Windows, ce qui copiera la clé dans le fichier authorized_keys de votre utilisateur linux (~/.ssh/authorized_keys), même si celui-ci n’existe pas au préalable. Il est cependant capital que le dossier .ssh soit déjà créé. Vous pouvez le créer avec mkdir si nécessaire.

Copie de la clé publique du client Windows vers le Linux :

type %userprofile%\.ssh\id_ecdsa.pub | ssh user@192.168.8.128 "cat >> .ssh/authorized_keys"

Pour allez plus loin il est possible de désactiver l’authentification par mot de passe pour conserver uniquement celle par clés.

Attention ! Si l’authentification par mot de passe est désactiver, il faut s'assure que l’authentification par clé est opérationnelle sous peine de ne plus du tout pouvoir accéder à la machine distante !

Dans le fichier de configuration /etc/ssh/sshd_config, il faut décommenter la directive PasswordAuthentication puis appliquer le paramètre no.

sudo nano /etc/ssh/sshd_config 
PasswordAuthentication no

Une fois le fichier sauvegarder il faudra encore redémarrer le service pour rendre le changement actif.

service ssh restart

Les préconisations suivantes sont tirées des recommandations publiées par l’ANSSI :

  1. Vérifier que les clés privées de chiffrement présentes dans le répertoire /etc/ssh/ appartiennent à l’utilisateur root en lecture-écriture seulement

  2. S’assurer que c’est bien la version 2 du protocole SSH qui est utilisée

  3. Le serveur SSH doit écouter sur un autre port que le 22/TCP

  4. Vérifier que les droits sur les fichiers sont appliqués de manière stricte par SSH

  5. L’accès SSH par l’utilisateur root doit être interdite

  6. Mettre en œuvre une séparation des privilèges à l’aide d’un bac à sable (sandbox)

  7. Interdire l'accès à distance par des comptes ne disposant pas de mot de passe

  8. Autoriser 3 tentatives de connexion successives en cas d’erreur dans le mot de passe

  9. Le service doit afficher les informations de dernière connexion à l’utilisateur quand il se connecte

  10. N’autoriser que les utilisateurs destinés à se connecter sur le serveur.

Comments


Renforcement de la sécurité du service openSSH avec les clés de chiffrement SSH

L’authentification par mot de passe est considérée comme un mécanisme faible. Elle peut être soumise à différents types d’attaque comme celles par dictionnaire, par force brute ou encore par Man In The Middle comme nous l’avons vu précédemment.


Il est vivement recommandé de configurer une authentification plus robuste lorsque l'on configure le service SSH, par clés de chiffrement ou encore par double facteur (2FA).


Etape 1 : Configuration de l'authentification à clés sur le service SSH


Pour commencer il est nécessaire d'autoriser les clés SSH dans le fichier de configuration :

sudo nano /etc/ssh/sshd_config

Il faudra rechercher et ajouter la valeur yes à " PubkeyAuthentication " :

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Pour que les changements prennent effet il est nécessaire redémarrer SSH :

service ssh restart

Etape 2 : Génération des clés SSH sur le client


Sur la machine cliente nous allons devoir générer une clé publique, et une clé privée afin de pouvoir s’authentifier sur le serveur SSH :

ssh-keygen -b 256 -t ecdsa

La commande ssh-keygen a généré deux clés :

  • Une clé privée sous $home/.ssh/id_ecdsa à laquelle vous seul devez avoir accès

  • Une clé publique sous $home/.ssh/id_ecdsa.pub, qui peut être partagée


Nous allons maintenant autoriser explicitement la machine cliente à accéder au serveur par SSH. Il faut ajouter la clé publique (id_ecdsa.pub) dans le fichier authorized_keys du répertoire .ssh de l’utilisateur qui sera choisie pour se connecter (ex : /home/$user/.ssh).

La méthode la plus simple est d’utiliser la commande ssh-copy-id mais elle n'est pas disponible par défaut sur Windows. Nous utiliserons donc les commandes suivants sur Windows, ce qui copiera la clé dans le fichier authorized_keys de votre utilisateur linux (~/.ssh/authorized_keys), même si celui-ci n’existe pas au préalable. Il est cependant capital que le dossier .ssh soit déjà créé. Vous pouvez le créer avec mkdir si nécessaire.

Copie de la clé publique du client Windows vers le Linux :

type %userprofile%\.ssh\id_ecdsa.pub | ssh user@192.168.8.128 "cat >> .ssh/authorized_keys"

Pour allez plus loin il est possible de désactiver l’authentification par mot de passe pour conserver uniquement celle par clés.

Attention ! Si l’authentification par mot de passe est désactiver, il faut s'assure que l’authentification par clé est opérationnelle sous peine de ne plus du tout pouvoir accéder à la machine distante !

Dans le fichier de configuration /etc/ssh/sshd_config, il faut décommenter la directive PasswordAuthentication puis appliquer le paramètre no.

sudo nano /etc/ssh/sshd_config 
PasswordAuthentication no

Une fois le fichier sauvegarder il faudra encore redémarrer le service pour rendre le changement actif.

service ssh restart

Les préconisations suivantes sont tirées des recommandations publiées par l’ANSSI :

  1. Vérifier que les clés privées de chiffrement présentes dans le répertoire /etc/ssh/ appartiennent à l’utilisateur root en lecture-écriture seulement

  2. S’assurer que c’est bien la version 2 du protocole SSH qui est utilisée

  3. Le serveur SSH doit écouter sur un autre port que le 22/TCP

  4. Vérifier que les droits sur les fichiers sont appliqués de manière stricte par SSH

  5. L’accès SSH par l’utilisateur root doit être interdite

  6. Mettre en œuvre une séparation des privilèges à l’aide d’un bac à sable (sandbox)

  7. Interdire l'accès à distance par des comptes ne disposant pas de mot de passe

  8. Autoriser 3 tentatives de connexion successives en cas d’erreur dans le mot de passe

  9. Le service doit afficher les informations de dernière connexion à l’utilisateur quand il se connecte

  10. N’autoriser que les utilisateurs destinés à se connecter sur le serveur.

CONTENU

CONTENU

Etape 1 : Configuration de l'authentification à clés sur le service SSH

Etape 2 : Génération des clés SSH sur le client

bottom of page