web-dev-qa-db-ja.com

sshdがまだPAMに関与しているのはなぜですか？

背景/動作は次のとおりです。sshでboxを介してGSSAPI/Kerberosが成功し、ローカルユーザーが/ etc/passwdにいる場合は、以下のPAM構成に従って正常にログインします。そこにすべて良い。

ただし、ローカルユーザーが/ etc/passwdにいないが、Host/XXXXXXサービスチケットを取得できる場合（GSSAPIは機能します）、sshdはログインに失敗し、SecurID（当社のpam）のプロンプトを取得しません。 radiusはSecurIDを指します）。という事は承知しています。サーバーはユーザーを「認証」し、pam_unixはユーザーが/ etc/passwdにいないことを知っているので、他の認証メソッドを使用する必要はありません。

しかし、私の質問は、最初にkdestroyを実行した場合（意図的にGSSAPIが失敗した場合）（そして/ etc/passwdにまだ存在しない場合）、突然Securidプロンプトが表示される（つまり、PAMが使用されている）のはなぜですか？

デバッグでsshdを実行すると、次のように表示されます。キーボードの延期-無効なユーザー「user」に対して対話型。まず、なぜそれは単に失敗しないのでしょうか？第二に、なぜ遅れるのですか？ pam_radiusは「required」ではなく「requisite」です。

認証をしていなくても、pam_unixを通過することは決してないので、単に失敗することも予想されます。

ファイル：

/ etc/ssh/sshd_config

....  
ChallengeResponseAuthentication yes  
GSSAPIAuthentication            yes  
HostbasedAuthentication         no  
KerberosAuthentication          no  
PasswordAuthentication          no  
PubkeyAuthentication            yes  
RhostsRSAAuthentication         no  
RSAAuthentication               yes  
UsePAM                          yes      
....

/ etc/pam.d/sshd

auth       requisite        pam_radius_auth.so conf=pam_radius_auth.conf debug retry=3  
auth       required     pam_nologin.so  
auth     required     pam_krb5.so.1  
account  sufficient      pam_radius_auth.so conf=pam_radius_auth.conf  
account    required     pam_stack.so service=system-auth  
password   required     pam_stack.so service=system-auth  
session    required     pam_stack.so service=system-auth  
session    required     pam_limits.so  
session    optional     pam_console.so

/ etc/pam.d/system-auth

auth        required      pam_env.so  
auth        sufficient    pam_krb5.so.1  
auth        sufficient    pam_unix.so  
auth        required      pam_deny.so  
account     required      pam_unix.so  
password    required      pam_cracklib.so retry=3  
password    sufficient    pam_unix.so use_authtok md5 shadow  
password    required      pam_deny.so  
session     required      pam_limits.so  
session     required      pam_unix.so
linuxsshkerberospamgssapi
4
jouell

GSSAPI認証はPAMによって処理されません。 Kerberos用のPAMモジュールは、有効なチケットを取得するためにKerberosプロトコルを使用して、ユーザーのパスワード認証に使用されます。

GSSAPI認証には3つの結果があります。

  1. 資格情報が送信されたが、資格情報が無効だったため、認証に失敗しました。
  2. 提示された資格情報を使用して認証が成功しました。
  3. 資格情報が提供されなかったため、認証は無視されます。

結果が1の場合、トークンが送信されたが失敗したため、要求は完全に拒否されます。 SSHDは、他の認証方法を試行しません。

結果が3の場合、sshdは次に、PAM authセクションを含む他の認証方法を試行します。

私はpam_radiusに精通していませんが、セキュリティ上の理由から、ユーザーが存在するかどうかに関係なく、認証トークンを要求すると思います。失敗するとすぐに、そのようなユーザーが存在することをユーザー/攻撃者に示しますnot存在するため、消去法からユーザーを列挙できます。

「requisite」オプションに関しては、「required」と「requisite」を指定したスタック設定で同じ効果があります。 pam_krbはとにかく有効なユーザーなしではチケットをリクエストできないため、すぐに失敗してしまいます。

指定された構成の場合、pam_unixは認証ではなく承認に使用されます。これは、認証後に発生するステップです。明確にするために;認証は、あなたが本人であると証明することを扱いますが、承認は、あなたがやりたいこと（この場合はログイン）を実行するための正しい権限を持っていることを扱います。

4
Matthew Ife