15/11/2024

ServicesSSH

Configurer SSH pour gérer l’OTP avec Google Authenticator

I. Présentation de l'OTP/Google Authenticator

La sécurité des accès à privilèges doit faire l'objet de toute l'attention des administrateurs systèmes et des RSSI. Aujourd'hui, les faiblesses du couple login/password en terme de sécurité ne sont plus à prouver et il est commun de voir apparaître des solutions d'authentification multi-facteurs. Pour rappel, une authentification peut se baser sur plusieurs facteurs :

  • Ce que je sais : un mot de passe
  • Ce que je sais faire : une signature
  • Ce que je possède : un smartphone, un Token USB
  • Ce que je suis : empreintes digitales

L'utilisation de plusieurs de ces facteurs pour un même accès est alors appelé authentification forte. La solution la plus accessible pour la mise en place de l'authentification forte sur un accès est l'OTP (One Time Password). Le principe de l'utilisation de l'OTP est donc d'être en possession d'un appareil/objet qui va générer régulièrement un mot de passe. Ce mot de passe ne sera utilisable qu'une fois et valable pour un délai très court. Un pirate qui entrera en possession de mon login et de mon mot de passe devra alors également se saisir de mon générateur d'OTP. Communément, les générateurs d'OTP sont des petites clés (type clés USB) ou des applications sur smartphone.

Dans un tel contexte, l'authentification se base donc sur :

  • Ce que je sais : mon mot de passe
  • Ce que je possède : mon générateur d'OTP

Dans ce tutoriel, nous allons étudier la configuration permettant de mettre en place une authentification forte sur l'accès SSH. Les accès SSH sont les plus convoités des pirates car ils permettent de prendre possession d'un serveur très rapidement, également, ils sont majoritairement utilisés par les administrateurs.

La solution utilisée sera dans notre cas Google Authenticator, une application gratuite que l'on peut trouver sur Android et iOS. La configuration nécessite l'installation d'une librairie permettant de prendre en charge ce nouveau mode d'authentification, la modification de la configuration SSH, puis l'enrôlement de l'application Google Authenticator pour que l'application de votre smartphone génère des OTP propre à votre compte.

Ce tutoriel  est basé sur les éléments suivants :

  • un serveur Debian 8.3
  • un service OpenSSH 6.7
  • l'application Google Authenticator v4.44

II. Configuration côté serveur

Nous allons naturellement commencer par procéder à l'installation côté serveur.

A. Installation de la librairie

La première étape est donc de télécharger et compiler la librairie "pam_google_authenticator" pour PAM.

PAM ou "Pluggable Authentication Modules" est le mécanisme qui va gérer l'authentification sous Linux. Il possède l'avantage d'être hautement configurable et modulable, ce qui nous permet de modifier le scénario d’authentification afin de faire entrer en jeu le système OTP 🙂

Celle-ci sera notamment utilisée par le système d'authentification de notre serveur lors du traitement de la demande/réponse de l'OTP, on commence par installer les paquets suivants :

apt-get install build-essential make libpam0g-dev libpam0g

La librairie libpam0g est ici importante, elle permet à l'administrateur du système de choisir la façon dont les applications (dont OpenSSH Server) va authentifier ses utilisateurs. Ensuite, nous téléchargeons la librairie en elle-même :

cd /tmp
wget https://google-authenticator.googlecode.com/files/libpam-google-authenticator-1.0-source.tar.bz2 -O googleauth.tar.bz2
tar -xf googleauth.tar.bz2 && rm googleauth.tar.bz2
cd libpam-google-authenticator-1.0/

Nous allons ensuite la compiler avec les commandes habituelles :

make
make install

Cette dernière commande nous retourne l'affichage suivant :

cp pam_google_authenticator.so /lib/x86_64-linux-gnu/security
cp google-authenticator /usr/local/bin

Nous avons maintenant à notre disposition la librairie PAM nommée pam_google_authenticator, celle-ci sera utilisée par PAM et le serveur SSH lors de l'authentification des utilisateurs . Également, nous avons une commande nommée "google-authenticator", cette commande sera utilisée par les utilisateurs afin d'enrôler leur application Google Authenticator, nous verrons cela dans le prochain chapitre 🙂

B. Modification de la configuration SSH

A présent, nous avons la possibilité d'intégrer l'utilisation de l'OTP dans le mécanisme d'authentification SSH, rien de plus simple dans notre cas, il suffit de modifier un paramètre dans le fichier de configuration d'OpenSSH server : /etc/ssh/sshd_config

Nous allons y trouver le paramètre suivant :

ChallengeResponseAuthentication no

et passer le "no" à "yes" :

ChallengeResponseAuthentication yes

Pour information, ce paramètre permet d'accepter l'authentification via un échange challenge-response. Il nous faut ensuite modifier le scénario d'authentification de l'application SSH pour y intégrer la phase OTP au niveau PAM. Pour cela, nous nous rendons dans le fichier /etc/pam.d/ssh pour y ajouter la ligne suivante à la ligne 44 :

auth required pam_google_authenticator.so

Voici à quoi ressemblera la structure finale du fichier dans la zone modifiée :

[...]
# Print the status of the user's mailbox upon successful login.
session    optional     pam_mail.so standard noenv # [1]

# Set up user limits from /etc/security/limits.conf.
session    required     pam_limits.so

# Read environment variables from /etc/environment and
# /etc/security/pam_env.conf.
auth       required     pam_google_authenticator.so
session    required     pam_env.so # [1]
# In Debian 4.0 (etch), locale-related environment variables were moved to
# /etc/default/locale, so read that as well.
session    required     pam_env.so user_readenv=1 envfile=/etc/default/locale
[...]

Pour finir, et prendre en compte nos dernières modifications, il faut redémarrer le service SSH :

service ssh restart

L'intégration de l'OTP est maintenant terminée pour ce qui concerne les modifications côte serveur.

III. Configuration côté client

Nous allons maintenant passer à la "configuration" côté client. Il faut en effet que le client soit synchronisé au niveau de son application Google-authenticator sur smartphone. La première étape est donc télécharger sur votre smartphone l'application Google Authenticator :

ssh-google-authenticator-01 ssh-google-authenticator-02

Voici l'interface de Google Authenticator, les utilisateurs peuvent y gérer leurs comptes :

ssh-google-authenticator-04
Interface de l'application Google Authenticator

La seconde étape consiste à générer une clé de sécurité qui va nous permettre de raccorder notre application à notre compte. Nous allons donc nous connecter en SSH avec l'utilisateur qui doit utiliser l'authentification forte, et exécuter la commande suivante :

google-authenticator

Différente option son alors paramétrables :

  • A la question  "Do you want authentication tokens to be time-based (y/n) ", saisir "y", cela permet donc de générer des tokens basé sur l'heure et la date actuelle.
  • A la question  "Do you want me to update your "/home/adminadmin/.google_authenticator" file (y/n)", saisir "y", le fichier ~./google_authenticator permet de stocker les informations concernant l'enrôlement de l'application smartphone. Il est stocké dans le dossier /home de l'utilisateur actuel. C'est pour cette raison qu'il est important d'effectuer cette commande avec l'utilisateur actuel sur le serveur cible.
  • A la question  "Do you want to disallow multiple uses of the same authenticationtoken?", saisir "y", cela permet d'éviter les possibilités de rejeu d'un token déjà utilisé.
  • A la prochaine question, répondre "n", cela fixe le délai de validité d'un token à 30 secondes, ce qui est généralement suffisant. ce paramètre sera modifiable ultérieurement si besoin, comme les autres d'ailleurs
  • A la dernière question, répondre "y", cette dernière question permet de limiter le nombre de token tenté afin d'éviter le brute force.

Voici la trame complète :

adminadmin@debian:~$ google-authenticator

Do you want authentication tokens to be time-based (y/n) y
https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/adminadmin@debian%3Fsecret%3DG7WH6ZQJATNDMX4C
Your new secret key is: G7WH6ZQJATNDMX4C
Your verification code is 551013
Your emergency scratch codes are:
  60955400
  59847646
  47168104
  48025356
  44020894

Do you want me to update your "/home/adminadmin/.google_authenticator" file (y/n) y

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y

By default, tokens are good for 30 seconds and in order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with poor
time synchronization, you can increase the window from its default
size of 1:30min to about 4min. Do you want to do so (y/n) n

If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y

Vous aurez remarqué qu'une clé de sécurité a été générée à la seconde étape (question), dans cette trame exposée en exemple, il s'agit de "G7WH6ZQJATNDMX4C".

Cette clé est à fournir dans l'application Google Authenticator  après avoir été dans "Saisir la clé fournie", nous pourrons alors donner un nom à notre nouvelle clé et la saisir dans le champ "Saisissez votre clé" :

ssh-google-authenticator-06
Ajout d'un compte dans Google Authenticator

Une fois cette opération effectuée, vous pourrez voir l'OTP généré de façon régulière. Nous pourrons alors effectuer notre première connexion SSH en utilisant notre OTP :

ssh utilisateur@IPserveur

Voici l'affichage que l'on pourra avoir :

mickael [~] 20:51 > ssh [email protected]
Password:
Verification code:

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
You have mail.
Last login: Wed Jan 27 20:29:25 2016 from localhost
adminadmin@debian:~$

Nous voyons donc bien que le mot de passe est demandé, puis s'il est validé, le "Verification Code", qui est donc l'OTP généré dans l'application Google Authenticator.

ssh-google-authenticator-05
OTP généré dans Google Authenticator

Cette procédure vous permettra donc d'améliorer la sécurité de votre accès SSH, en empêchant notamment les brutes force. En effet, même si l'attaquant trouve le mot de passe de votre compte utilisateur, il devra en plus être en possession de l'OTP, qui a une durée de vie de 30 secondes seulement.

Si vous appréciez la technologie Google Authenticator / OTP, je vous propose cet autre tutoriel : Google Authenticator : Augmenter la sécurité de son compte Google

author avatar
Mickael Dorigny Co-founder
Co-fondateur d'IT-Connect.fr. Auditeur/Pentester chez Orange Cyberdéfense.
Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Envoyer par mail

7 commentaires sur “Configurer SSH pour gérer l’OTP avec Google Authenticator

  • Bonjour Mikael et merci pour ce très bon tuto.

    Bien que j’utilise presque tous les jours l’OTP de google pour diverses appli Windows et boites mails, je me pose 2 questions de débutant sur Linux:

    – Le principe de l’authentification OTP est de se baser sur l’horloge de la machine me semble-t-il. Sais tu comment ça marche sur un ordi dépourvu de pile, comme par exemple le Raspberry Pi, et qui serait amené à redémarrer après une coupure de courant?

    – Bien que le cas de figure que je vais décrire ne soit pas très sécurisé, peut ont, utiliser la même clé de sécurité afin qu’un seul token de l’appli du téléphone fonctionne pour l’authentification sur 2 serveurs différents (ouverture de session SSH quasi simultanée)?

    Merci.

    Répondre
    • Hello Lothar,

      Pour ta première question, effectivement l’OTP peut se baser (entre autres), sur l’horloge. Je ne saurais répondre précisément à ta question, mais à partir du moment où ton système sait maintenir une horloge, cela devrait passer. A tester !

      Pour ta seconde question, ce contexte peut marcher, à partir du moment où le contenu de ton fichier .google_authenticator est le même (notamment la clé de synchronisation) pour les deux serveurs, alors cela devrait fonctionner et le même OTP doit pouvoir être utilisé pour deux serveurs différents.

      De mon coté j’ai testé un cas similaire. Deux utilisateurs avec la même clé de départ (deux fichiers .google_authenticator identiques), mais sur un même serveur, et le même OTP fonctionnait pour les deux utilisateurs.

      En espérant avoir répondu à ta question ! 🙂

      Répondre
      • Merci Mickael pour tes réponses.
        Je vais tester ce week end sur le Raspberry. Je sais qu’il garde l’heure en cas de coupure électrique mais je pense que c’est via une synchro sur serveur NTP.
        Pour le fichier .google_authenticator sur 2 serveurs ton explication me convient très bien. Je testerai aussi ce week end. 🙂
        Merci.

        Répondre
      • Je viens de faire mes essais et tout fonctionne bien.
        – Sur les PC qui n’ont pas de pile mais accès à internet, le NTP marche très bien pour l’authentification Google. Dans mon cas, le NTP était implémenté de base sous Raspbian.
        – On peut tout à fait avoir la même clé de sécurité sur plusieurs serveurs en éditant le fichier « /home/nom_de_l’utilisateur/.google_authenticator ». Ce qui permet de n’avoir qu’une seule entrée sur le téléphone. De plus, on peut installer cette clé sur plusieurs téléphones/tablettes/etc pour avoir un secours en cas de perte du téléphone par exemple.

        Pour Mickael,
        j’ai trouvé 2 petites coquilles dans ton tuto.
        – Au début, quand tu décompresses googleauth.tar.bz2, « && » s’est glissé sur ta ligne de commande à la place de « && ».
        – Tu indiques qu’il faut éditer le fichier /etc/pam.d/ssh pour rajouter « auth required pam_google_authenticator.so » à la ligne 44 mais en fait c’est le fichier /etc/pam.d/sshd

        Encore une fois merci pour ce tuto très intéressant.

        Répondre
  • Bonjour et merci,
    Je me permets quand même une petite remarque de barbu : pourquoi utiliser google authenticator alors que des solutions libres existent ? Car si le serveur a l’air open source, je ne crois pas qu’il en soit de même pour l’appli android (ça m’étonnerait même fort), et il me semble dommage de compromettre bêtement ce qui se veut un dispositif de sécurité en « laissant ses clés » à google…
    Je suis peut-être un peu parano, mais on parle bien ici de sécurité, donc…
    J’utilise personnellement oathtool comme serveur et un client libre sur mon FxOS (GAuth), la configuration est guère plus compliquée.
    Sur android, il existe un certain nombre de clients libres qui gèrent ces protocoles, on peut les trouver facilement avec F-Droid.

    Répondre
  • PS: n’oubliez pas de synchroniser l’horloge de l’application avec celle du serveur de Google avant.

    Répondre
  • Bonjour,
    Le dépôt n’existe plus, j’ai utilisé le paquet : libpam-google-authenticator avec Debian stretch.
    RAS.

    Répondre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.