SSH: authentification à deux facteurs

30

J'ai actuellement un serveur Ubuntu 12.04 exécutant OpenSSH avec Samba et quelques autres services. À l'heure actuelle, j'ai configuré l'authentification par clé publique et je me demande s'il est possible de configurer l'authentification à deux facteurs? J'ai consulté Google Authenticator que j'utilise actuellement avec mon compte Gmail.

J'ai trouvé un module PAM qui semble compatible, mais il semble que vous soyez obligé d'utiliser un mot de passe et le code généré.

Je me demande s'il existe un moyen d'utiliser l'application Google Authenticator (ou quelque chose de similaire) avec ma clé publique pour m'authentifier sur mon serveur SSH?

— Âne en béton
source

La plupart des commentaires semblent être des rapports de bogues mentionnant qu'il est impossible d'utiliser PAM et l'authentification par clé publique avec OpenSSH. J'ai également trouvé des pièces mentionnant qu'il est redondant car j'utilise une phrase de passe avec ma clé. Avec toutes les solutions ne permettant apparemment que Google Authenticator et un mot de passe et non une clé publique. Je pourrais le manquer complètement, mais je ne vois tout simplement pas comment implémenter les deux.

— Concrete Donkey

Je ne sais pas pourquoi cela a un -1, c'est une question très intéressante et je voudrais moi aussi connaître la réponse (pas que je vais probablement l'utiliser, mais quand même, bon à cacher dans les banques de connaissances)

— Mark Henderson

@Pierre Essayez-vous d'exiger à la fois une authentification par clé publique et un OTP Google?

— mgorven

@mgorven Oui, j'essayais de configurer la clé publique et Google OTP. J'ai entendu certaines personnes dire que le fait d'avoir une phrase secrète sur la clé comptait pour deux facteurs, mais je crains que des logiciels malveillants ne volent la clé non chiffrée de la mémoire. Je préférerais avoir deux appareils complètement séparés pour l'authentification, je suis légèrement paranoïaque.

— Concrete Donkey

Ceci est destiné à être officiellement implémenté dans 6.2: bugzilla.mindrot.org/show_bug.cgi?id=983#c59

— Tobias Kienzler

8

Red Hat a ajouté un correctif à OpenSSH dans RHEL (et donc CentOS) 6.3 pour exiger plusieurs mécanismes d'authentification, vous pouvez donc faire quelque chose comme ceci:

RequiredAuthentications2 publickey,keyboard-interactive

Voir les notes de version pour pas beaucoup plus de détails.

Malheureusement, cette fonctionnalité ne semble pas être dans OpenSSH en amont ni dans Ubuntu 12.04, donc à moins que vous ne vouliez trouver le correctif et recompiler OpenSSH, je crains que vous n'ayez pas de chance.

— mgorven
source

Je dois dire que j'apprécie l'effort que vous avez déployé pour me trouver une réponse, j'ai certainement essayé de parcourir quelques pages de résultats Google, mais tout cela impliquait ce que vous avez mentionné, je devais utiliser un mot de passe et un OTP uniquement. Je vais probablement créer une machine virtuelle CentOS pour jouer avec la fonctionnalité.

— Concrete Donkey

@Pierre pas que beaucoup d' efforts, je connaissais cette fonction avant ;-)

— mgorven

J'ai trouvé le bug correspondant et quelques notes supplémentaires . Le bogue inclut le correctif en tant que pièce jointe.

— Robie Basak

Et voici un bug OpenSSH en amont . Il semble que des fonctionnalités similaires seront bientôt en amont dans openssh.

— Robie Basak

openssh 6.2 a atterri dans la version de développement d'Ubuntu, donc en cas de catastrophe, ce support sera dans la version 13.10 attendue. Il utilise en amont AuthenticationMethodspour spécifier plusieurs méthodes requises, de sorte que vous pouvez exiger à la fois une clé ssh et PAM, PAM faisant la fin de Google Authenticator.

— Robie Basak

8

Vous recherchez Duo Security

— Ajith
source

1

Cette. Oui. J'adore cette chose!

— LVLAaron

Certainement - Duo est facile à configurer pour Unix / Linux (lien en réponse), OpenVPN ( duosecurity.com/docs/openvpn_as ) ou tout service à deux facteurs basé sur OATH TOTP ou la gestion des mots de passe LastPass. Tout service compatible avec Google Authenticator (qui utilise TOTP) peut être utilisé avec l'application mobile Duo ou un jeton matériel prenant en charge TOTP.

— RichVel

5

Vous pouvez utiliser à la fois le module PAM Google Authenticator et les clés publiques, mais une seule à la fois sera utilisée pour une authentification donnée. Autrement dit, si un utilisateur se connecte avec une clé publique autorisée, aucun jeton ne sera requis.

Ou, pour le dire autrement: les jetons ne sont nécessaires que pour les authentifications de mot de passe, pas les clés SSH.

Cette limitation ne vient pas du module Google Authenticator, mais de SSH, qui n'implémente que l'authentification à deux facteurs (via ChallengeResponseAuthentication) pour PAM, mais n'appelle pas PAM lorsqu'une clé publique valide est fournie.

— ℝaphink
source

C'était correct, mais cela a maintenant changé. openssh 6.2 ajoute un AuthenticationMethodsparamètre de configuration qui peut inverser cela. Maintenant, vous pouvez avoir besoin des deux.

— Robie Basak

3

Cette question date de 2012. Depuis, SSH a changé et le protocole SSH2 a été implémenté.

Sur les versions plus récentes de SSH (> = 6.2), man sshd_config mentionne:

AuthenticationMethods
       Specifies the authentication methods that must be successfully completed for a user to be
       granted access.  This option must be followed by one or more comma-separated lists of
       authentication method names.  Successful authentication requires completion of every method
       in at least one of these lists.

       For example, an argument of ``publickey,password publickey,keyboard-interactive'' would
       require the user to complete public key authentication, followed by either password or key-
       board interactive authentication.  Only methods that are next in one or more lists are
       offered at each stage, so for this example, it would not be possible to attempt password or
       keyboard-interactive authentication before public key.

       This option is only available for SSH protocol 2 and will yield a fatal error if enabled if
       protocol 1 is also enabled.  Note that each authentication method listed should also be
       explicitly enabled in the configuration.  The default is not to require multiple authentica-
       tion; successful completion of a single authentication method is sufficient.

Cette page http://lwn.net/Articles/544640/ mentionne également la possibilité d'utiliser à la fois un publickey et une authentification PAM.

— liquidité
source

2

Je sais que cette question est un peu obsolète, mais pour le bien des personnes futures (moi y compris) qui recherchent une solution, il est également question d'utiliser l'option ForceCommand dans le fichier sshd_config pour exécuter un script qui effectue ensuite l'authentification. Il y a un exemple de script ici que vous pouvez modifier un peu selon vos besoins, bien que dans cet exemple, il l'appelle à partir du fichier authorized_keys au lieu de le faire à l'échelle du système avec ForceCommand de sshd_config.

— Incroyable
source

1

Obtenez une YubiKey et suivez ce guide http://berrange.com/posts/2011/12/18/multi-factor-ssh-authentication-using-yubikey-and-ssh-public-keys-together/

AFAIK, c'est le meilleur moyen d'implémenter Yubikey sur votre serveur pour l'accès SSH. Le guide ci-dessus vous permet d'utiliser la clé publique + yubikey alors que si vous allez avec le guide officiel ( http://code.google.com/p/yubico-pam/wiki/YubikeyAndSSHViaPAM ), cela ne fonctionne pas avec public- clé.

Cordialement, Vip

— vagarwal
source

0

Si vous définissez une phrase secrète sur votre clé privée, vous disposez déjà d'une authentification à deux facteurs. Pour se connecter, les gens auraient besoin de:

quelque chose que vous avez - votre clé privée
quelque chose que vous savez - la phrase secrète de votre clé privée

— Bart B
source

3

Deux mots de passe ne font pas d' authentification à deux facteurs. La clé elle-même n'est pas un "quelque chose que vous avez" valide parce que ce n'est pas une chose, juste une information. La chose doit être non copiable, ou du moins non copiable, pour être utilisée comme facteur d'authentification.

— MadHatter prend en charge Monica

2

Je suis totalement en désaccord. Si les clés et les certificats ne sont pas «quelque chose que vous avez», quels sont-ils? Ils ne sont certainement pas "quelque chose que vous connaissez" (avez-vous l'habitude d'apprendre votre clé SSH?), Et absolument pas "quelque chose que vous êtes". Ce sont les trois seuls choix, donc par un processus d'élimination, ils sont très certainement "quelque chose que vous avez".

— Bart B

1

Je suis d'accord; pour moi, le problème est dans la maxime (quelque chose que vous avez | savez | êtes). L'idée de l'authentification à deux facteurs est d'exiger des membres de deux classes avec des propriétés différentes; quelque chose que vous savez est facile à transporter, mais il peut être connu par quelqu'un d'autre en même temps que vous le savez; nous ajoutons donc un deuxième facteur différent. Le "quelque chose que vous avez" n'est différent que s'il n'est pas copiable (ou difficile à copier). Sinon, bien sûr, ce n'est pas quelque chose que vous savez, mais ce n'est pas qualitativement différent de quelque chose que vous savez , parce que quelqu'un d'autre peut l'avoir en même temps que vous.

— MadHatter prend en charge Monica

2

Je suis tout à fait d'accord pour dire qu'une paire de clés protégée par mot de passe est une grande amélioration de la sécurité par rapport au nom d'utilisateur + mot de passe. Je ne suis malheureusement pas d'accord pour dire qu'une telle paire compte pour deux facteurs, et nous devrons probablement accepter d'être en désaccord sur ce point.

— MadHatter prend en charge Monica le

3

Si vous disposez d'une clé privée chiffrée par mot de passe, vous ne prouvez qu'une seule chose au serveur: que votre client connaît la clé privée. Cela ne prouve pas au serveur que vous connaissez votre phrase secrète; le serveur ne connaît même pas l'existence de votre phrase secrète. Il ne s'agit donc que de «quelque chose que vous savez» (puisque votre client le sait) et d'un seul facteur. Si un attaquant s'empare d'une seule chose (votre clé privée), vous êtes compromis. Voilà un facteur. Faire valoir que votre phrase secrète et votre clé privée comptent comme deux facteurs n'est qu'un exercice de sophistique. Ce qui compte, c'est ce qui se passe sur le fil.

— Robie Basak