ошибка читая keytab файл krb5.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 похож, но мы поэтапный отказ от этой ОС, поэтому я не планирую ее там тестировать.
As @ryan-fisher mentioned in his reply, the host needs a keytab file in order for it to be able to retrieve a TGT for preauth.
The reason the message isn't seen for root is because that user is local (does not need Kerberos for authentication). When using SSH authorized-keys, you also circumvent Kerberos, so there will be no error regaring missing keytab there either.
Now, what you need to do is to make sure that /etc/krb5.keytab contains the keys for the principal host/domain.name.of.host for the machine. Assuming the reverse DNS is correctly set up, you will then be able to log in using ssh without typing a password assuming you have a valid TGT.
Если у вас нет keytab на хосте, вы действительно не используете Kerberos должным образом и широко открыты для относительно простой атаки, если злоумышленник может отравить ваши кеши DNS.
Kerberos - это система общего секрета, и для эффективной работы любой сервер, принимающий билеты Kerberos, должен иметь локальную копию общего секрета, который также есть в Центре распространения ключей Kerberos (KDC). Это и есть keytab, локальная копия общего секрета для этой службы.
Keytab также может использоваться в качестве кеша для получения билетов Kerberos Ticket-Granting-Tickets (TGT), но это когда вы хотите host, чтобы действовать как клиент для сервера Kerberos, а не как сервер.
pam_krb5 использует keytab для проверки того, что введенный пароль является фактическим паролем в KDC. Если у вас нет вкладки, позволяющей это сделать,
Вы можете отключить проверку, чтобы избежать появления сообщения в журнале, как это было предложено Банджером, но цель этапа проверки - предотвратить атаку, при которой злоумышленник устанавливает собственный фиктивный KDC. .
Это могло быть старое сообщение, но у меня была та же проблема, и я хотел избавиться от сообщения. Я следовал этим инструкциям ArchLinux и решил это.
https://wiki.archlinux.org/index.php/Active_Directory_Integration#Creating_a_machine_key_tab_file
Просто набрал это:
net ads keytab create -U administrator
Однако это может зависеть от вашей настройки.