On estime que chaque jour, un million de yottaoctets est créé à travers le monde. Parmi toutes ces données figurent... les vôtres. Aussi insignifiantes soient-elles à l'échelle du web, elle ne sont pour autant pas à l'abris des tentatives de vol ou — comme le dirait Mark Zuckerberg — de détournement. Pour vous prémunir de l'utilisation de votre dernier selfie à la plage sur les forums du dark web, de nombreuses plateformes (webmail, réseaux sociaux, clouds en tout genre) vous proposent de mettre en place un OTP sur votre compte.

Quel que soit le nom donné à ce système (validation en deux étapes, authentification à deux facteurs, double identification, etc.) le principe est le même : pour connecter votre compte, vous devez saisir votre mot de passe (ce que vous savez) et un code à usage unique — ou à usage très limité dans le temps — généré dynamiquement par un appareil de confiance préalablement configuré (ce que vous possédez) :

Ainsi, un individu malveillant — humain ou non — qui aurait dérobé votre mot de passe ne posséderait que la moitié de l'équation et ne pourrait pas se connecter à votre compte. Notez qu'aucun mécanisme de sécurité n'étant infaillible, l'OTP ne protègera pas vos données dans le cas d'une attaque de type man in the middle établie.

L'OTP permet d'augmenter significativement le niveau de sécurité de vos accès, et je vous incite à l'activer partout où celà est possible... y compris pour la connexion SSH à vos machines UNIX. Vous trouverez ici les quelques étapes nécessaires à la mise en place de l'authentification TOTP sur un système tourant sous Debian 9. Notez que le comportement attendu est le suivant :

1. L'utilisateur autorisé initie la session SSH
2. Le système lui demande de saisir son mot de passe
3. Si le mot de passe est correct, le système lui demande un code OTP

Note : Dans les lignes suivantes, prêtez attention à l'utilisateur qui execute la commande : root lorsqu'il est nécessaire d'avoir des droits d'accès élevés, sshuser pour l'utilisateur dont on souhaite sécuriser l'accès SSH (pour rappel, il est fortement déconseillé d'autoriser root à se connecter en SSH).

Installer le module d'authentification Google Authenticator

Nous allons installer le module PAM Google Authenticator (pour plus d'informations sur le fonctionnement de PAM, je vous recommande l'excellent article du blog Artisan Numérique). Il est disponible dans les repos officiel de la plupart des grandes distributions Linux.

root@host: $ apt-get install libpam-google-authenticator

Configurer Google Authenticator

NB : Cette opération doit être répétée pour chaque utilisateur dont on souhaite sécuriser l'accès SSH. Lancez la commande google-authenticator et validez en tappant Y puis Enter ↲ :

root@host: $ google-authenticator

Do you want authentication tokens to be time-based (y/n) y

Le système va alors générer la clé secrète qui vous permettra de configurer votre application OTP préférée. Un QR Code sera même disponible pour une configuration facile :

Stockez dans un endroit sûr les 5 codes de secours, sous peine d'être enfermé dehors si votre générateur d'OTP devait vous faire défaut.

Répondez ensuite aux trois questions posées in english, sir. Il suffit de répondre par Y ou N et de valider avec Enter ↲ . Quelques explications pour les moins anglophones (et ceux qui ne connaissent pas bien les mécanismes du TOTP) :

Code à usage unique

Votre appareil de confiance (en général, votre smartphone) va générer un mot de passe à partir de la clé secrète et de l'heure courante. Par défaut, le code est recalculé toutes les 30 secondes. Un code est donc valable durant toute cette durée, et peut être utilisé autant de fois que nécessaire. Pour augmenter la sécurité et limiter les dégâts en cas d'attaque de type MITM, vous pouvez faire en sorte que chaque code ne soit utilisable qu'une seule fois dans sa durée de vie de 30 secondes en répondant 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

Allongement de la durée de validité

Afin de compenser un éventuel décalage d'horloges entre le serveur SSH protégé par TOTP et votre appareil de confiance, chaque code est en réalité valable au delà de sa durée de vie (à méditer) : il peut être utilisé pendant la vie de son prédécesseur et pendant celle de son sucesseur, soit un total de 90 secondes :

A tout instant, 3 codes sont donc valables simultanément. Si vous le souhaitez, vous pouvez élargir encore la durée de validité de chaque code à 8 minutes et 30 secondes soit la durée de vie des 8 codes qui le précèdent et des 8 codes qui lui succèdent. Je déconseille ce réglage qui augmente inutilement les risques (les 90 secondes ont toujours été suffisantes pour mes nombreux usages, y compris sur des machines non synchronisées avec un serveur de temps) :

By default, tokens are good for 30 seconds. 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 +-1min (window size of 3) to about +-4min (window size of
17 acceptable tokens).
Do you want to do so? (y/n) n

Protection contre les attaques de type brute-force

Les codes TOTP sont généralement composés de 6 chiffres, soit 1 million de possibilités. Dans l'absolu, une machine capable d'initier un million de connexions par tranche de 30 secondes peut donc forcer la sécurité (avec la précondition forte de posséder le mot de passe qui consitue la première étape d'authentification). Pour palier celà, vous pouvez activer une protection anti brute-force qui limite le nombre de tentatives à 3 codes par tranche de 30 secondes. Avec la machine décrite ci-avant, la probabilité de trouver le bon code passe ainsi de 100% à 0.003‰. Si votre serveur n'est pas protégé contre les attaques de ce type, je vous conseille de l'activer en répondant Y. Pour ma part, le serveur SSH étant déjà protégé par Fail2Ban, je ne l'active pas :

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) n

Configurer Linux

Les instructions suivantes ont été validées sous Debian 9 et 10

Reste désormais à configurer votre le système pour qu'il utilise l'authentification OTP sur SSH. Pour ceci, éditez le fichier /etc/pam.d/sshd avec les droits de super-utilisateur et ajoutez les lignes suivantes à la fin :

# OTP authentication
auth required pam_google_authenticator.so nullok

Il est également nécessaire d'éditer le fichier /etc/ssh/sshd_config pour décommenter la ligne suivante :

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication yes

Et ajouter à la toute fin du même fichier la ligne suivante :

AuthenticationMethods publickey,publickey password keyboard-interactive

Ceci aura pour conséquence de rendre obligatoire la saisie d'un code OTP après la saisie réussie du mot de passe SSH.

Enfin, redémarrez le service SSH :

root@host: $ service ssh restart

Votre accès SSH est désormais protégé par validation en deux étapes. Pensez à protéger tous vos utilisateurs SSH.