• 8 hours
  • Medium

Free online content available in this course.

course.header.alt.is_video

course.header.alt.is_certifying

Got it!

Last updated on 1/3/24

Configurez SSH pour activer l’authentification multifacteur

L’authentification multifacteur (abrégée MFA pour Multi Factor Authentication et parfois appelée “authentification forte”, même si ce n’est pas exactement la même chose), est dite multifacteur quand deux facteurs d’authentification ou plus entrent en jeu parmi les suivants :

  1. ce que je sais (un mot de passe) ;

  2. ce que je possède (un téléphone ou un périphérique cryptographique) ;

  3. qui je suis (empreinte digitale, empreinte oculaire, etc).

Dès qu’on utilise 2 de ces facteurs, on parle de 2FA (2 Factors Authentication) ou plus généralement de MFA (Multi Factors Authentication) si on en utilise au moins 2.

Par défaut, le service SSH, qui permet de créer le tunnel sécurisé, a besoin d’un login et d’un mot de passe. Mais on peut remplacer ce mot de passe par d’autres méthodes d’authentifications :

  • L’authentification par clé de sécurité : c’est le meilleur compromis entre simplicité et sécurité ;

  • L’authentification par clé de sécurité et certificat : c’est ce qui est utilisé lorsque vous vous accédez à une site en https ;

  • L'authentification via GSSAPI à un service d’authentification externe comme Kerberos : c’est la méthode à privilégier si votre entreprise utilise déjà un service d'authentification dédié.

Il existe aussi d’autres méthodes d'authentification qui s’utilisent avec des modules externes  comme la reconnaissance vocale ou les codes de vérification temporaire envoyés par sms. C’est d’ailleurs cette dernière qui est utilisée lorsque vous vous connectez à votre application bancaire.

Gardez en tête qu’aucune méthode d’authentification n’est parfaite : elles comportent toutes forcément des failles. Cependant, on peut sensiblement réduire les risques de sécurité dès lors qu’on combine plusieurs méthodes d’authentification surtout si elles reposent sur plusieurs facteurs d’identification.

D’après un article de Guemmy Kim (en anglais), directeur de la sécurité des comptes chez Google en 2022, la mise en place de la 2FA (authentification avec 2 facteurs), a réduit de 50% le nombre de comptes compromis.

Dans la suite, je vous propose ici de mettre en place une authentification multi facteurs reposant sur une clé de sécurité et un mot de passe.

Modifiez le fichier de configuration du serveur SSH

Sur le poste serveur (celui dont on va prendre le contrôle), commençons par modifier le fichier de configuration de SSH pour activer l'authentification forte. Dans Windows, ce fichier se trouve dans C:\ProgramData\SSH\sshd_config, alors que dans une machine Linux, il est dans /etc/ssh/sshd_config.

Dans ce fichier renseignez les paramètres suivants :

PasswordAuthentication yes
PubkeyAuthentication yes
AuthenticationMethods publickey,password

Les 2 premiers paramètres servent à activer l’authentification par mot de passe et par clé de sécurité. Le dernier paramètre permet de combiner ces 2 méthodes d’authentification.

N’oubliez pas de redémarrer le service SSH après chaque modification de ce fichier.

Générez la clé de sécurité

La configuration du service SSH est terminée sur le serveur. Nous venons d’activer l'authentification par clé de sécurité, il faut maintenant générer une clé de sécurité. Cette étape doit se faire sur la machine qui exécutera le client VNC (celle depuis laquelle on va se connecter au serveur).

Rendez-vous sur le client et depuis un terminal lancez la commande :

ssh-keygen

Cette commande est reconnue aussi bien sous Linux, MacOS et même Windows à partir de la version 10. Sinon vous pouvez utiliser l'application PuTTYgen (en anglais).

Impression d'écran de la commande de génération d'une paire de clé de sécurité
Génération d’une paire de clé de sécurité

Une fois la commande exécutée, vous vous retrouvez non pas avec une, mais deux clés de sécurité :

  • une clé privée nommée “id_rsa”.

  • une clé publique nommée “id_rsa.pub”.

La clé privée doit rester sur le poste qui l’a générée alors que la clé publique est destinée à être partagée. Nous n’entrerons pas dans le détail ici mais si vous voulez comprendre l’intérêt d’avoir 2 clés, vous pouvez consulter ce chapitre de cours dédié au chiffrement asymétrique.

La dernière chose à faire est d'autoriser cette clé publique sur le serveur. Par défaut la clé publique se trouve dans le répertoire utilisateur puis dans : ~/.ssh/id_rsa.pub

Ouvrez le fichier id_rsa avec un éditeur de texte. Ce fichier contient une ligne commençant par “ssh-rsa”. Copiez cette ligne et collez-la sur votre serveur dans le fichier ~/.ssh/authorized_keys :Impression d'écran du contenu de ~/.ssh/authorized_keysContenu de ~/.ssh/authorized_keys

Si le fichier n’est pas vide, insérez simplement une nouvelle ligne pour copier votre clé. Si au contraire le fichier n’existe pas, créez-le.

Vous pouvez maintenant tester une connexion SSH simple depuis votre client vers votre serveur. Pour cela, vous pouvez utiliser un client SSH comme puTTY, MobaXterm ou simplement depuis un terminal avec la commande :

ssh utilisateur@host

Pensez évidemment à remplacer “utilisateur” par un utilisateur existant sur votre serveur et “host” par l’adresse IP de votre serveur.

Si tout fonctionne, voilà le résultat avec le client ssh MobaXterm : j’ai bien une authentification par clé dans un premier temps puis la demande d’un mot de passe dans un second temps.

Impression d'écran de la commande.
Double authentification

Si tout fonctionne, voilà le résultat avec le client ssh MobaXterm : j’ai bien une authentification par clé dans un premier temps puis la demande d’un mot de passe dans un second temps.

À la première authentification, il se peut que vous ayez un message d’avertissement vous demandant de valider l’authenticité de la machine sur laquelle vous essayez de vous connecter. Répondez simplement “yes”.

À ce stade, SSH est configuré pour fonctionner avec la double authentification. Il ne reste plus qu’à paramétrer le client pour qu’il crée un tunnel SSH automatiquement avant la connexion VNC.

Ok mais ça, le client Java TightVNC peut le faire automatiquement si on coche la case “use ssh tunneling”. On n’a donc plus rien à faire, non ?

En théorie oui sauf que comme le client Java TightVNC n’est plus tout jeune, ses développeurs n’avaient pas prévu à l’époque, des modes d’authentification autres qu’un mot de passe pour créer le tunnel SSH.

Ça fait donc une 2ème raison, en plus du chiffrement SHA-1 peu sécurisé (qu’on avait plus tôt dans ce chapitre) de ne plus utiliser ce client VNC.

Authentifiez-vous en MFA avec TightVNC

Lorsque vous avez installé TightVNC, plus tôt dans ce cours, un autre client s’est installé : TightVNC Viewer. C’est cet outil que nous allons utiliser.

Malheureusement quand vous le lancez, il n’y aucune option pour créer un tunnel SSH :

$ip = Read-Host -prompt 'IP du serveur VNC: ' ;$port = Read-Host -prompt 'Port VNC: ';$login = Read-Host -prompt 'Login: ';Start-Process ssh "-L ${port}:localhost:5901 ${login}@${ip} echo 'Connexion VNC en cours…';sleep 10"; Start-Sleep -Seconds 10;Start-Process 'C:\Program Files\TightVNC\tvnviewer.exe' localhost::$port

Il va donc falloir ruser en lançant TightVNC Viewer en mode ligne de commande. Voici la commande à utiliser sur Windows dans PowerShell :

read -p "IP du serveur VNC : " ip;read -p "Port VNC : " port;read -p "Login : " login;ssh -fNL ${port}:localhost:5901 ${login}@${ip}; xtightvncviewer localhost:${port}; pkill -f “ssh -fNL ${port}:localhost:5901 ${login}@${ip}”

Si le client est sous Linux il faut installer xtightvncviewer et adapter la commande de cette manière :

read -p "IP du serveur VNC : " ip;read -p "Port VNC : " port;read -p "Login : " login;ssh -fNL ${port}:localhost:5901 ${login}@${ip}; xtightvncviewer localhost:${port}; pkill -f “ssh -fNL ${port}:localhost:5901 ${login}@${ip}”

Laissez-moi vous détailler rapidement ce que font ces commandes. Le principe est le même pour les 2 commandes  :

  1. Vous entrez l’adresse IP de la machine distante, son port VNC et le login de connexion ;

  2. La commande SSH pour créer le tunnel est exécutée ;

  3. Le client VNC est lancé pour se connecter à la machine distante ;

  4. Le processus se termine (soit avec la commande “pkill” sous linux, soit au bout de 10 secondes d’inactivité sous Windows ou si vous fermez la fenêtre)

Libre à vous maintenant d’adapter ces 2 commandes pour les améliorer ou répondre à vos besoins.

En résumé

  • L'authentification multifacteur (MFA) renforce la sécurité en utilisant une combinaison de deux éléments ou plus parmi : ce que l’utilisateur sait, ce qu’il possède ou ce qui le constitue physiquement (biométrie). 

  • SSH peut être configuré pour supporter des méthodes d'authentification avancées, comme les clés de sécurité ou l'authentification via des services externes.

  • Activer la 2FA (authentification à deux facteurs) sur SSH a prouvé réduire significativement les risques de compromission des comptes.

  • Pour mettre en place MFA sur SSH, il faut modifier le fichier sshd_config et activer les méthodes d’authentification désirées.

  • Pour utiliser un tunnel SSH avec TightVNC Viewer, il faut exécuter des commandes spécifiques en ligne de commande sous Windows et Linux. 

  • Utilisez TightVNC Viewer avec des commandes spéciales pour une connexion sécurisée en MFA, remplaçant ainsi le client Java TightVNC plus limité.

Bravo, vous venez de conditionner votre accès distant par une authentification multi facteurs et donc d’augmenter sensiblement votre résistance aux intrusions externes par usurpation d'identité. Dans la suite, je vous propose d’inverser la connexion VNC, en initiant la prise de contrôle depuis le serveur cette fois.

Example of certificate of achievement
Example of certificate of achievement