Вопрос: ошибка чтения файла keytab krb5.keytab


Я заметил эти сообщения об ошибках 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, которое используется для аутентификации пользователя.


5
2017-11-08 14:21


Источник


Это происходит при перезагрузке sshd или при попытке входа в систему через ssh? Вы также видите сообщение при входе в систему с консоли? - chutz
@chutz Я добавил дополнительную информацию к моему вопросу. - Banjer


Ответы:


Если у вас нет ключа на хосте, вы действительно не используете Kerberos правильно и широко открыты для относительно простой атаки, если злоумышленник может отравить ваши кэши DNS.

Kerberos - это общая секретная система и эффективно работать на любом сервере, который принимает билеты Kerberos, должен иметь локальную копию общего секрета, который также имеет Центр распространения ключей Kerberos (KDC). Вот что такое keytab, локальная копия общего секрета для этой службы.

Keytab также может использоваться в качестве кеша для получения билетов на Ticket-Granting-Tickets (TGT) Kerberos, но это необходимо, если вы хотите, чтобы ваш хост выступал в качестве клиента для сервера Kerberos, а не как сервер.

pam_krb5 использует keytab для проверки того, что введенный пароль является фактическим паролем в KDC. Если у вас нет ключа, чтобы разрешить это, то все, что вы проверяете, это то, что какая-то машина где-то ответила на запрос протокола Kerberos.


4
2018-04-22 20:03





Чтобы отключить проверку ключа и, следовательно, подавить эти сообщения журнала, добавьте 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 похож, но мы поэтапно отказываемся от этой ОС, поэтому я не планирую тестировать ее там.


1
2017-07-17 13:42





Вы можете отключить проверку, чтобы избежать сообщения в журнале, как это было предложено Banjer, но цель шага проверки - предотвратить атаку, когда плохой парень создает свой собственный фиктивный KDC. Другими словами, вам нужен главный хозяин для проверки TGT, предоставленный KDC, является подлинным.


1
2018-04-22 18:40





Это может быть старый, но у меня была такая же проблема, и я хотел избавиться от сообщения. Я следовал этим инструкциям от ArchLinux и решил его.

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

Просто набрал:

net ads keytab create -U administrator

Однако это может зависеть от вашей настройки.


1
2017-10-26 07:37





Как упоминал в своем ответе @ ryan-fisher, хосту нужен файл keytab, чтобы он мог получить TGT для preauth.

Причина, по которой сообщение не отображается для root, заключается в том, что этот пользователь является локальным (для проверки подлинности Kerberos не требуется). При использовании авторизованных ключей SSH вы также обходите Kerberos, поэтому не будет ошибок при обнаружении отсутствующего keytab.

Теперь вам нужно сделать, чтобы убедиться, что /etc/krb5.keytab содержит ключи для принципала host/domain.name.of.host для машины. Предполагая, что обратный DNS настроен правильно, вы сможете войти в систему, используя ssh, не набрав пароль, если у вас есть действующий TGT.


0
2017-11-22 02:32



Первое предложение явно неверно. Хост не получает TGT. Пользователь получает TGT. Также TGT не используется для preauth. Вместо этого может потребоваться предварительная аутентификация, чтобы получить TGT. Видеть kerberos.org/software/tutorial.html - Ryan