Vous êtes ici: News

Utiliser de l’authentification forte pour son serveur SSH

Cet article a été repris à la demande de son auteur. Nous l’avons trouvé intéressant et avons donc souhaité le partager avec vous.

Retrouver l’article original sur le site de son auteur : essembeh


Le but de ce billet et de présenter l’authentification en deux étapes telle qu’elle est implémentée par Google.

Cette authentification forte est facilement utilisable avec les services de Google mais aussi intégrable à vos services, comme par exemple votre serveur SSH.

Présentation de l’authentification forte

Pour une présentation exhaustive, Je vous laisse lire la bonne présentation de Wikipedia

D’une manière simple, c’est une authentification en deux étapes. Pour authentifier, elle se base sur quelque chose que l’on sait et quelque chose que l’on a.

  • La chose que l’on sait, c’est le mot de passe. Mais cette donnée est facilement captable ne serait-ce par un enregistreur de frappe
  • La chose que l’on a, ce doit être quelque chose que l’on est seul à avoir c’est à dire non copiable ou au moins difficilement. Par exemple, une carte à puce ou un code basé sur le temps.

L’exemple jusqu’ici le plus connu d’authentification forte basée sur le temps est SecurID, solution propriétaire proposée par la société RSA. Google à mis en place il y a quelque temps une authentification en deux étapes pour ses services.
Remarque: Je vous encourage d’ailleurs à activer cette option si vous consultez vos mails d’un ordinateur dont vous ne pouvez garantir la sécurité, au travail, chez des amis …

Et comme souvent, Google joue le jeu de l’open source et les ce système est intégrable sous GNU/Linux grâce à un module PAM donc utilisable pour votre serveur SSH ou tout autre service basé sur l’authentification PAM.
Remarque: Attention toutefois à l’amalgame, ce module est indépendant des services Google, autrement dit il n’y a pas de rapport entre votre compte Gmail et votre compte SSH ! Google utilise cette méthode de mot de passe et code basé sur le temps, et a implémenté la partie cliente (l’application pour téléphone) et un module pour vous permettre d’utiliser le même algorithme sur votre serveur.

Le site du projet

En pratique

En pratique, j’ai l’application Google Authenticator sur mon téléphone (l’application est gratuite pour Android, iPhone et Blackberry).

Lorsque je veux accéder au service, je rentre mon identifiant et mon mot de passe.

Si le mot de passe est correcte, je dois rentrer le code de vérification qui est affiché sur mon téléphone.

Il change toutes les 30 secondes et dépend directement de mon compte, je suis le seul à avoir cette série de nombres.

Autrement dit à chaque compte Google ou à chaque utilisateur SSH, des numéro différents.

L’application sur téléphone permet d’avoir plusieurs comptes, personnellement j’ai celui pour mon Gmail et celui pour mon SSH.

Le code généré dépend d’une clé secrète (c’est elle qui est différente pour chaque utilisateur) et du temps. Seul le serveur et le téléphone connaissent la clé secrète, pas l’ordinateur qui accède au service ! Donc même si l’ordinateur enregistre les frappes il aura le code de vérification mais celui ci n’est valide qu’une seule fois et seulement 30 secondes.
Remarque: Attention comme la génération dépend du temps, il faut impérativement que le téléphone et le serveur soient à la même heure !

Activation pour les services Google

Pour se faire il faut se rendre dans les paramètres du compte et activer l’option.

Voici la page de présentation et d’aide à l’installation.
Le gros gros avantage que je vois à cette activation, c’est qu’ensuite on peut générer des mots de passe uniques pour les applications ne supportant pas cette méthode en deux étapes et donc on peut aussi révoquer ces mots de passe.

Par exemple Thunderbird ne permet pas cette authentification en deux étapes et puis ce serait contre productif de rentrer le code toutes les 3 minutes lorsqu’il relève le courrier.

Je peux donc créer un mot de passe unique pour Thunderbird qui ne demandera pas de code et si je n’utilise plus l’application (ou que le mot de passe est compromis), je peux le révoquer.

Utilisation avec OpenSSH

Il faut installer le paquet suivant

apt-get install libpam-google-authenticator

Remarque: Sous Debian, il est disponible dans les dépots « testing ».

Afin de synchroniser l’heure de son serveur il peut être utile d’installer le démon ntpd

apt-get install ntp

Ensuite il faut editer le fichier PAM spécifique à SSH

vi /etc/pam.d/sshd

Il faut ajouter la ligne suivante :

# PAM configuration for the Secure Shell service 

# Read environment variables from /etc/environment and
# /etc/security/pam_env.conf.
auth       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.
auth       required     pam_env.so envfile=/etc/default/locale 

# Standard Un*x authentication.
@include common-auth
auth required pam_google_authenticator.so

# Disallow non-root logins when /etc/nologin exists.
account    required     pam_nologin.so 

[…]

Ensuite il faut activer le mode Challenge de SSH, ce qui permet à SSH de vous reposer une question après vous avoir demandé votre mot de passe. Pour cela :

vi /etc/ssh/sshd_config

Et changez le « no » en « yes » à la ligne suivante permettant le « Challenge »:

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

On redémarre SSH

/etc/init.d/ssh restart

La dernière étape consiste à initialiser les comptes utilisateurs et de paramétrer son téléphone. Dans un terminal, chaque utilisateur doit lancer la commande suivante

google-authenticator

Informations à remplire pour l'authentification forte

Dans l’ordre nous avons

  • Le QR code pour paramétrer son téléphone, il suffit de le scanner avec l’application Google Authenticator et le tépéhone est paramétré ! merci le QRCode :)
  • La clé secrète, ici JLT23I2GDEI6B26R
  • Des code d’urgence. Si vous voulez vous connecter mais que vous n’avez pas votre téléphone, ces codes sont utilisables mais une seule fois chacun ! Il est conseillé de les écrire pour les avoir accessibles en cas de besoin.
  • La première question demande si on doit écrire le fichier de configuration, réponde oui.
  • Ensuite si on permet ou non l’utilisation du même code plusieurs fois. Autrement dit comme un code est valable 30 secondes, si je veux me connecter deux fois en 30 secondes, je dois répondre oui.
  • Ensuite on vous propose d’étendre la durée de vie des codes.
  • Enfin une sécurité visant à interdire le brute-force.

Chaque utilisateur qui souhaite se connecter en SSH doit faire ceci, sinon il ne pourra pas s’identifier !

Vous pouvez par la suite éditer le fichier ~/.google_authenticator
Astuce: Vous pouvez ajouter des codes de secours en éditant le fichier et ajoutant un code à 6 chiffres par ligne. Cela peut être utile de mettre un numéro que l’on connaît par cœur en cas d’urgence ;)
Remarque: Lors de l’utilisation d’une clé publique pour l’authentification, SSH ne se sert pas de PAM, il n’y aura donc pas de code de vérification à entrer.

Conclusion

Voila vous pouvez maintenant vous connecter en SSH de manière plus sécurisée !

De plus comme c’est open source, des projets basés sur cette implémentation émergent et il existe par exemple un module d’authentification Apache et sûrement d’autres applications =)


Si vous aussi vous souhaitez nous proposer un de vos articles, vous pouvez utiliser le formulaire de contact.
Retrouvez l’ensemble des articles relayés par le Planet-Libre à l’adresse suivante: http://blog.planet-libre.org/category/articles-relayes/

2 Commentaires

  1. L.I.A.R. :

    Pour info, il existe une solution très simple de « one-time passwords » sous open-BSD :
    http://www.openbsd.org/faq/faq8.html#SKey

    Ça ressemble un peu dans le principe, sauf que je trouve ça plus simple puisqu’il n’y a pas de système à installer ailleurs (quid de ceux qui n’ont pas de smartphone par exemple ?)

    • seb :

      OTP est très pratique, je l’utilisais avant GoogleAuth.

      Cela nécessite par contre d’avoir la liste du (ou des) prochains passwords valides avec soit (par exemple sur son smartphone^^).
      On peut les régénérer avec un otpclient mais cela nécessite de retaper sa clé privée contrairement à un algo basé sur le temps.

      Cette méthode basée sur le temps est à l’usage plus simple à mon avis.
      Surtout que comme j’ai activé cette authentification sur Gmail aussi, j’ai « factorisé » la sécurité avec cette application :)

Poster un commentaire





Designed by Thomas Bourcey