Я заметил эти сообщения об ошибках Kerberos keytab как на SLES 11.2, так и на CentOS 6.3:
sshd[31442]: pam_krb5[31442]: error reading keytab 'FILE: / etc/ krb5. keytab'
/etc/krb5.keytab не существует на наших хостах, и, насколько я понимаю, файл keytab нам не нужен. За это введение в Kerberos 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"
}
Дайте мне знать, если вам понадобятся другие конфиги. Спасибо.
РЕДАКТИРОВАТЬ
Это сообщение появляется в /var/log/secure всякий раз, когда пользователь без полномочий root входит в систему через SSH или консоль. Кажется, это происходит только при аутентификации на основе пароля. Если я использую ssh на основе ключей для сервера, я не вижу ошибки. Если я захожу в систему под root, то ошибки не вижу. Наши серверы Linux аутентифицируются в Active Directory, поэтому для аутентификации пользователя используется смесь PAM, samba, kerberos и winbind.
Если у вас нет keytab на хосте, вы действительно не используете Kerberos должным образом и широко открыты для относительно простой атаки, если злоумышленник может отравить ваши кеши DNS.
Kerberos - это система общего секрета, и для эффективной работы любой сервер, принимающий билеты Kerberos, должен иметь локальную копию общего секрета, который также есть в Центре распространения ключей Kerberos (KDC). Это и есть keytab, локальная копия общего секрета для этой службы.
Keytab также может использоваться в качестве кеша для получения билетов Kerberos Ticket-Granting-Tickets (TGT), но это для тех случаев, когда вы хотите, чтобы ваш хост действовал как клиент для сервера Kerberos, а не как сервер.
pam_krb5 использует keytab для проверки того, что введенный пароль является действительным паролем в KDC. Если у вас нет вкладки, позволяющей это сделать, то все, что вы проверяете, - это то, что какая-то машина где-то ответила на запрос протокола Kerberos.
Это могло быть старое сообщение, но у меня была та же проблема, и я хотел избавиться от сообщения. Я выполнил эти инструкции ArchLinux и решил это.
https://wiki.archlinux.org/index.php/Active_Directory_Integration#Creating_a_machine_key_tab_file
Просто введите это:
net ads keytab create -U administrator
Однако это может зависеть от вашей настройки.
Вы можете отключить проверку, чтобы избежать появления сообщения в журнале, как предлагает Банджер, но цель этапа проверки - предотвратить атаку, при которой злоумышленник устанавливает свой собственный фиктивный KDC. Другими словами, вам нужен принципал хоста для проверки подлинности TGT, предоставленного KDC.
Чтобы отключить проверку keytab и, следовательно, подавить эти сообщения журнала, добавьте no_validate в настройках PAM. Например:
auth sufficient pam_krb5.so use_first_pass no_validate
На своих серверах CentOS 6 я внес это изменение везде, где видел pam_krb5.so на которые есть ссылки в этих двух файлах:
/etc/pam.d/password-auth-ac
/etc/pam.d/system-auth-ac
Я уверен, что SLES похожа, но мы постепенно отказываемся от этой ОС, поэтому я не планирую ее там тестировать.
Как заметил @ ryan-fisher в своем ответе, хосту нужен файл keytab, чтобы он мог получить TGT для предварительной проверки.
Причина, по которой сообщение не отображается для пользователя root, заключается в том, что этот пользователь является локальным (не требует Kerberos для аутентификации). При использовании авторизованных ключей SSH вы также обходите Kerberos, поэтому не будет ошибок, связанных с отсутствием keytab.
Теперь вам нужно убедиться, что /etc/krb5.keytab содержит ключи для главного host/domain.name.of.host для машины. Предполагая, что обратный DNS настроен правильно, вы сможете войти в систему с помощью ssh, не вводя пароль, при условии, что у вас есть действующий TGT.