Я следовал стандартной документации, чтобы установить сервер и клиент FreeIPA на хосты SRV и CLT соответственно. Затем я добавил пользователя «X» в FreeIPA с помощью веб-интерфейса. Теперь, когда я пытаюсь использовать SSH как X в CLT, я получаю 'Permission denied, please try again.' ошибка. Я проверяю '/ var / log / messages' на клиенте и вижу это - '[sssd[krb5_child[3277]]]: Decrypt integrity check failed'.
Я сбрасывал пароль несколько раз, но это не решило проблему. Потом я наткнулся на эти -
Похоже, удаление файла '/etc/krb5.keytab' из SRV и CLT, а затем их воссоздание решит проблему.
Какой метод аутентификации SSH вы используете? Вы вводите свой пароль или пытаетесь использовать аутентификацию на основе билетов Kerberos (gssapi-with-mic или gssapi-keyex)?
Сообщение «Ошибка проверки целостности дешифрования» может поступать из двух источников. Если вы дадите ему неправильный пароль (ваш пароль не совпадает с ключами вашего принципала в KDC), вы получите это. Вы также получите его, если ваш пароль в порядке, но вкладка на сервере устарела; это произойдет с аутентификацией как по билету, так и по паролю (поскольку с паролем сервер получает билет для своего собственного принципала хоста после выполнения kinit, чтобы аутентифицировать KDC).
Похоже, удаление файла ’/etc/krb5.keytab’ из SRV и CLT с последующим их воссозданием решит проблему.
Keytab на клиенте не имеет значения; это не часть этого сценария. Вероятная проблема здесь в том, что таблица ключей на сервере не синхронизирована с KDC (сервером аутентификации Kerberos или «Центром распространения ключей», который является частью FreeIPA). С Kerberos у всех удостоверений (или «участников») в системе есть ключи, которые они используют совместно с KDC. Ключи пользователя создаются на основе его пароля. Ключи для программной службы, такой как sshd, генерируются случайным образом и сохраняются в файле, называемом keytab (от «таблицы ключей»), чтобы служба могла получить к ним доступ. Похоже, что ключи для участника SSH были изменены в KDC, но таблица ключей не была обновлена для соответствия. Ваше основное имя имеет вид пользователь @ REALM. Основное имя службы SSH имеет вид host /имя хоста@REALM. Пытаться:
$ ipa-getkeytab -s <FreeIPA server> -p host/<hostname>@REALM -k <keytab file>.
... чтобы извлечь текущие ключи для участника службы SSH в новую вкладку ключей. Ты можешь использовать klist -ek <keytab> для просмотра содержимого старой и новой вкладок. Если у вас есть несоответствие ключей, оно должно отображаться как ключи для одного и того же принципала с разными номерами версий ключей (или «kvno»). Вы можете увидеть что-то вроде:
# look at the system keytab
$ sudo klist -ek
KVNO Principal
---- --------------------------------------------------------------------------
1 host/foo.example.com@EXAMPLE.COM (AES-256 CTS mode with 96-bit SHA-1 HMAC)
# look at the new keytab
$ klist -ek <new keytab>
KVNO Principal
---- --------------------------------------------------------------------------
2 host/foo.example.com@EXAMPLE.COM (AES-256 CTS mode with 96-bit SHA-1 HMAC)
Я тоже решил эту проблему. поскольку ccache содержал старый ключ для IPA-сервера из предыдущей установки, просто нужно удалить /var/lib/sss/db/ccache_* файл
подробнее в билете: https://fedorahosted.org/sssd/ticket/2781
На клиенте я удалил /etc/krb5.keytab На сервере я удалил хост ipa host-del host.example.com
Я удаляю клиентское программное обеспечение ipa.
Я переустанавливаю клиент ipa
НО, клиент не работает.
Аt Наконец, мне пришлось перезапустить ipa-server ipactl restart и ...
Клиент работает нормально. Я полагаю, что у kdc server или подобного было что-то в кеше о клиентских ключах.
С уважением.