SSH:二要素認証


30

現在、Sambaおよび他のいくつかのサービスとともにOpenSSHを実行しているUbuntu Server 12.04があります。現時点では、公開キー認証を設定していますが、2要素認証を設定できるかどうか疑問に思っていますか?現在、Gmailアカウントで使用しているGoogle認証システムを見てきました。

互換性があるように見えるPAMモジュールを見つけましたが、パスワードと生成されたコードの使用を余儀なくされているようです。

Google認証システムアプリケーション(または同様のもの)を公開キーと一緒に使用してSSHサーバーへの認証を行う方法があるかどうか疑問に思っていますか?


コメントの大部分は、OpenSSHでPAMおよび公開キー認証を使用することは不可能であると述べているバグレポートのようです。また、キーにパスフレーズを使用しているため、冗長であると言及している部分もあります。すべてのソリューションでは、公開鍵ではなくGoogle認証システムとパスワードのみが許可されているようです。私はそれを完全に見逃しているかもしれませんが、両方を実装する方法がわかりません。
コンクリートロバ

これが-1である理由がわからない、これは非常に興味深い質問であり、私も答えを知りたい(私はそれを使用する可能性はないが、それでもナレッジバンクに保管しておくのが良い)
Mark Henderson

@Pierre 公開鍵認証とGoogle OTPの両方を要求しようとしていますか?
mgorven

@mgorvenはい、公開鍵とGoogle OTPの両方を設定しようとしていました。鍵のパスフレーズを2つの要素としてカウントするだけで十分であると言う人もいますが、マルウェアがメモリから暗号化されていない鍵を盗むのが心配です。私は、認証に2つの完全に別個のデバイスを使用したいのですが、少し妄想的です。
コンクリートロバ

これは、正式に6.2で実装になることを目的としている:bugzilla.mindrot.org/show_bug.cgi?id=983#c59
トビアスKienzler

回答:


8

Red Hatは、RHEL(およびCentOS)6.3のOpenSSHにパッチを追加して、複数の認証メカニズムを必要としているため、次のようなことができます。

RequiredAuthentications2 publickey,keyboard-interactive

これ以上詳細な情報はリリースノートをご覧ください。

残念ながら、この機能はOpenSSHのアップストリームやUbuntu 12.04にはないようです。そのため、パッチを見つけてOpenSSHを再コンパイルする場合を除き、運が悪いのではないかと心配しています。


私が答えを見つけるのにあなたが注いだ努力に感謝しなければなりません、私は確かに数ページのGoogleの結果を調べてみましたが、すべてはあなたが言及したことを暗示しました。この機能を試すために、おそらくCentOS VMを作成します。
コンクリートロバ

@Pierre それほど努力はしいません、私は以前にこの機能について知っていました;-)
mgorven

対応するバグいくつかの追加のメモを見つけました。バグには添付ファイルとしてパッチが含まれます。
ロビーバサック

そして、ここにアップストリームのopensshバグがあります。似たような機能が、opensshですぐにアップストリームになるようです。
ロビーバサック

openssh 6.2はUbuntuの開発リリースに含まれているため、災害を除いて、このサポートは予定されている13.10リリースに含まれます。アップストリームを使用してAuthenticationMethods必要な複数のメソッドを指定するため、sshキーとPAMの両方を要求でき、PAMはGoogle認証システムの終了を行います。
ロビーバサック

8

Duo Securityを探しています


1
この。はい。このことが大好きです!
LVLAaron

間違いなく-Duoは、Unix / Linux(link in answer)、OpenVPN(duosecurity.com/docs/openvpn_as)、またはOATH TOTPベースの2要素サービス、またはLastPassパスワード管理用に簡単にセットアップできます。Google Authenticator(TOTPを使用)と互換性のあるサービスは、Duoのモバイルアプリ、またはTOTPをサポートするハードウェアトークンで使用できます。
RichVel

5

Google Authenticator PAMモジュールと公開キーの両方を使用できますが、特定の認証に使用されるのは一度に1つだけです。つまり、ユーザーが承認された公開キーでログインする場合、トークンは必要ありません。

または、別の言い方をすると、トークンはパスワード認証にのみ必要であり、SSHキーには必要ありません。

ちなみに、この制限はGoogle AuthenticatorモジュールによるChallengeResponseAuthenticationものではなく、PAMに対して2要素認証(を介して)のみを実装し、有効な公開キーが提供されたときにPAMを呼び出さないSSH によるものです。


これは正しいものでしたが、現在では変更されています。openssh 6.2では、AuthenticationMethodsこれを反転できる構成パラメーターが追加されています。これで両方を要求できます。
ロビーバサック

3

この質問は2012年のものです。以来、SSHが変更され、SSH2プロトコルが実装されました。

SSHのより新しいバージョン(6.2以上)で、man sshd_configは次のように述べています:

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.

このページhttp://lwn.net/Articles/544640/では、公開鍵とPAM認証を同時に使用する可能性についても言及しています。


2

私はこの質問が少し古いことを知っていますが、解決策を探している将来の人々(私自身を含む)のために、sshd_configファイルのForceCommandオプションを使用して認証を実行するスクリプトを実行することの話もあります。スクリプトの例があります、ここではその一例では、彼はsshd_configファイルのForceCommandでシステム全体のそれを作るのではなく、authorized_keysファイルからそれを呼び出しますが、あなたが、あなたのニーズにビットを変更することができます。


1

YubiKeyを取得し、このガイドに従ってくださいhttp://berrange.com/posts/2011/12/18/multi-factor-ssh-authentication-using-yubikey-and-ssh-public-keys-together/

私の知る限り、これはSSHアクセスのためにサーバーにYubikeyを実装する最良の方法です。上記のガイドでは、公開キー+ yubikeyを使用できますが、公式ガイド(http://code.google.com/p/yubico-pam/wiki/YubikeyAndSSHViaPAM)を使用すると、public- キー。

よろしく、VIP


0

秘密鍵にパスフレーズを設定した場合、すでに2要素認証があります。ログインするには、次のものが必要です。

  1. あなたが持っているもの-あなたの秘密鍵
  2. 知っていること-秘密鍵へのパスフレーズ

3
2つのパスワードは2要素認証を行いません。キー自体は有効な「あなたが持っているもの」ではありません。なぜなら、それは情報ではなく単なる情報だからです。Thingは、認証要素として使用するために、コピー不可、または少なくとも重要なコピー不可でなければなりません。
MadHatterは、モニカをサポートします

2
私はまったく同意しません。鍵と証明書が「持っているもの」ではない場合、それらは何ですか?それらは間違いなく「知っているもの」ではなく(SSHキーから学習する習慣がありますか?)、絶対に「あなたのもの」ではありません。これらは唯一の3つの選択肢であるため、排除のプロセスによって、最も確実に「あなたが持っているもの」です。
バートB

1
同意する; 私にとって、問題は格言にあります(あなたが持っている|知っている|ある)。2要素認証の考え方は、異なるプロパティを持つ2つのクラスのメンバーを要求することです。あなたが知っているものは持ち運びが簡単ですが、あなたがそれを知っているのと同時に他の人がそれを知ることができます。そこで、2番目の異なる要因を追加します。「あなたが持っているもの」は、コピーできない(またはコピーするのが難しい)場合にのみ異なります。そうでなければ、確かに、それはあなたが知っているものではありませんが、他の誰かがあなたと同時にそれを持つことができるので、あなたが知っているものと質的には違いはありません。
マッドハッターはモニカをサポートしています

2
パスワードで保護されたキーペアは、ユーザー名とパスワードをそのまま使用した場合よりもセキュリティが大幅に向上することに同意します。悲しいことに、そのようなペアが2要素としてカウントされることに同意するわけではありません。おそらく、これに反対することに同意する必要があります。
MadHatterは、モニカをサポートしています

3
パスフレーズで暗号化された秘密鍵を持っている場合、サーバーに証明することは1つだけです。それは、クライアントが秘密鍵を知っていることです。パスフレーズを知っていることをサーバーに証明しません。サーバーはパスフレーズの存在さえも知りません。したがって、それは「あなたが知っていること」(クライアントがそれを知っているため)であり、1つの要素にすぎません。攻撃者がたった1つのこと(あなたの秘密鍵)を手に入れると、あなたは危険にさらされます。それが一つの要因です。パスフレーズと秘密鍵が2つの要素としてカウントされると主張することは、so弁の練習に過ぎません。重要なのは、ワイヤ上で何が起こるかです。
ロビーバサック
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.