web-dev-qa-db-ja.com

keytabファイルkrb5.keytabの読み取りエラー

SLES 11.2とCentOS 6.3の両方で、これらのkerberos keytabエラーメッセージに気づきました。

sshd[31442]: pam_krb5[31442]: error reading keytab 'FILE: / etc/ krb5. keytab'

/etc/krb5.keytabはホスト上に存在せず、私がkeytabファイルについて理解していることから、それは必要ありません。 このケルベロスのキータブの紹介 ：

キータブは、Kerberosプリンシパルと暗号化されたキーのペアを含むファイルです（これらはKerberosパスワードから派生しています）。このファイルを使用して、パスワードの入力を求められることなくKerberosにログインできます。 keytabファイルの最も一般的な個人的な使用法は、スクリプトが人の介入なしにKerberosに対して認証できるようにすること、またはパスワードをプレーンテキストファイルに保存することです。

これは私たちが必要としないもののように聞こえ、おそらくそれを持たない方がセキュリティ面で優れています。

このエラーがシステムログに表示されないようにするにはどうすればよいですか？ここに、便利な場合の私のkrb5.confがあります：

banjer@myhost:~> cat /etc/krb5.conf
# This file managed by Puppet
#
[libdefaults]
        default_tkt_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
        default_tgs_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
        preferred_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
        default_realm = FOO.EXAMPLE.COM
        dns_lookup_kdc = true
        clockskew = 300

[logging]
        default = SYSLOG:NOTICE:DAEMON
        kdc = FILE:/var/log/kdc.log
        kadmind = FILE:/var/log/kadmind.log

[appdefaults]
pam = {
        ticket_lifetime = 1d
        renew_lifetime = 1d
        forwardable = true
        proxiable = false
        retain_after_close = false
        minimum_uid = 0
        debug = false
        banner = "Enter your current"
}

他の構成を確認する必要がある場合はお知らせください。ありがとう。

[〜＃〜]編集[〜＃〜]

このメッセージは、root以外のユーザーがSSHまたはコンソール経由でログインするたびに/var/log/secureに表示されます。パスワードベースの認証でのみ発生するようです。サーバーに対してキーベースのSSHを実行しても、エラーは表示されません。 rootでログインしてもエラーは表示されません。私たちのLinuxサーバーはActive Directoryに対して認証を行うため、ユーザーの認証に使用されるPAM、samba、kerberos、winbindの豊富な組み合わせです。

linuxcentosactive-directorykerberos
6
Banjer

キータブ検証を無効にして、これらのログメッセージを抑制するには、no_validate PAM設定のオプション。例えば：

auth        sufficient    pam_krb5.so use_first_pass no_validate

私のCentOS 6サーバーでは、この変更をどこにでも行ったpam_krb5.soこれら2つのファイルで参照されています：

/etc/pam.d/password-auth-ac
/etc/pam.d/system-auth-ac

SLESも同様だと確信していますが、そのOSは段階的に廃止する予定なので、そこでテストする予定はありません。

1
Banjer

ホストにキータブがない場合、実際にはKerberosを適切に使用しておらず、攻撃者がDNSキャッシュを汚染する可能性がある場合は、比較的単純な攻撃に広くさらされています。

Kerberosは共有秘密システムであり、Kerberosチケットを受け入れるすべてのサーバーが効果的に機能するためには、Kerberosキー配布センター（KDC）も持つ共有秘密のローカルコピーが必要です。これがキータブとは何か、そのサービスの共有シークレットのローカルコピーです。

キータブは、Kerberosチケット許可チケット（TGT）を取得するためのキャッシュとしても使用できますが、これは、ホストをサーバーとしてではなく、Kerberosサーバーのクライアントとして機能させたい場合に使用します。

pam_krb5はkeytabを使用して、入力されたパスワードがKDC内の実際のパスワードであることを確認します。これを許可するキータブがない場合、確認しているのは、どこかのマシンがKerberosプロトコル要求に応答したことだけです。

4
Fred the Magic Wonder Dog

これは古いものかもしれませんが、同じ問題があり、メッセージを削除したかったのです。私はArchLinuxからのこれらの指示に従い、それを解決しました。

https://wiki.archlinux.org/index.php/Active_Directory_Integration#Creating_a_machine_key_tab_file

これを入力するだけです：

net ads keytab create -U administrator

ただし、設定によって異なる場合があります。

2
Abel Martín

検証を無効にして、Banjerによって提案されたログのメッセージを回避できますが、検証ステップの目的は、悪意のある人物が独自の偽のKDCを設定する攻撃を防ぐことです。つまり、KDCから提供されたTGTが本物であることを検証するには、Hostプリンシパルが必要です。

1
Ryan

@ ryan-fisherが返信で述べたように、ホストが事前認証用のTGTを取得できるようにするには、ホストにkeytabファイルが必要です。

Rootに対してメッセージが表示されない理由は、そのユーザーがローカルであるためです（認証にKerberosは必要ありません）。 SSH承認済みキーを使用する場合、Kerberosも回避されるため、欠落しているkeytabを再確認するエラーも発生しません。

さて、あなたがする必要があるのは、/etc/krb5.keytabにはプリンシパルのキーが含まれますHost/domain.name.of.Hostはマシン用です。リバースDNSが正しく設定されていると仮定すると、有効なTGTを持っていると想定して、パスワードを入力しなくてもsshを使用してログインできます。

0
Elias Mårtenson