Может ли кто-нибудь объяснить это, потому что я сделал все, от восстановления ключей до «выхода» и повторного присоединения к домену (Centrify) для хоста SSH, к которому я, похоже, не могу добраться с помощью одного клиента. Все остальные клиенты могут получить доступ к этому хосту, кроме одного. Как ни странно, я могу подключиться к хосту по SSH от клиента, если использую IP-адрес:
$ ssh ddecker@host
Connection closed by 10.0.0.250
$ ssh ddecker@10.0.0.250
Password:
[ddecker@host ~]$
Единственное, что у меня есть, это внутри / var / log / messages на хосте, при попытке использовать имя хоста я получаю следующее:
fatal: accept_ctx died [preauth]
Я попытался удалить /etc/krb5.keytab, но потом Centrify не запускается; поэтому я вернул его обратно. На самом деле не уверен, что происходит, почему все другие клиенты могут подключаться по имени, и это, поскольку клиент может подключаться только через IP.
ОБНОВЛЕНИЕ №1:
Вот результат ssh -v ddecker@host:
debug1: Reading configuration data /etc/centrifydc/ssh/ssh_config
debug1: /etc/centrifydc/ssh/ssh_config line 52: Applying options for *
debug1: Connecting to host [10.0.0.250] port 22.
debug1: Connection established.
debug1: identity file /home/ddecker/.ssh/id_rsa type 1
debug1: identity file /home/ddecker/.ssh/id_rsa-cert type -1
debug1: identity file /home/ddecker/.ssh/id_dsa type -1
debug1: identity file /home/ddecker/.ssh/id_dsa-cert type -1
debug1: identity file /home/ddecker/.ssh/id_ecdsa type -1
debug1: identity file /home/ddecker/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9
debug1: match: OpenSSH_5.9 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: Offering GSSAPI proposal: gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-gex-sha1-A/vxljAEU54gt9a48EiANQ==,gss-group1-sha1-A/vxljAEU54gt9a48EiANQ==,gss-group14-sha1-A/vxljAEU54gt9a48EiANQ==
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: Doing group exchange
debug1: Calling gss_init_sec_context
debug1: Delegating credentials
Connection closed by 10.0.0.250
Так что спасибо всем, что они дали мне несколько рекомендаций. Однако в итоге я нашел проблему. Я написал простой сценарий ожидания, который в основном копирует мой SSH-ключ на каждый сервер и знает, что это за серверы, с помощью простого файла.
Итак, я ни в чем не обнаружил ошибок, но для этого хоста, похоже, у меня была запись «known_hosts», которая конфликтовала с моим ключом SSH, и она просто разорвала мое соединение. Я удалил файл known_hosts (все, что мне действительно нужно было сделать, это удалить один элемент в known_hosts), а затем повторил попытку подключения - и получил доступ.
Простое исправление, но ошибки не помогали и не указывали на очевидное исправление.
Спасибо!
Симптомы говорят о том, что керберос сломан для одного клиента. Если вы используете ssh через IP, Kerberos обычно не используется.
Наиболее частая причина поломки Kerberos для одного клиента - это рассинхронизация времени на этом клиенте. Kerberos требует, чтобы системные часы всех задействованных узлов были примерно синхронизированы.
/bin/date
и на клиенте, и на сервере должны находиться в пределах нескольких секунд друг от друга.
Отладка AD / Kerberos Centrify всегда утомляет.
Вы можете попробовать включить отладку Centrify на своем сервере с помощью /usr/share/centrifydc/bin/addebug on. Имейте в виду, что это может создать очень большие файлы журналов и потенциально привести к полным томам, если оставить их включенными слишком долго.
Проверьте SPN и KVNO
Получите список принципов и KVNO на локальной вкладке на вашем сервере. Для этого может потребоваться установить RPM-пакет клиентских утилит Kerberos на сервере Linux (yum install krb5-workstation).
klist -kte
Сравните это с Kerberos KVNO, определенным вашим AD. Из другой системы Centrify enebales Linux: (Требуется активный сеанс входа в систему Kerberos, инициированный с помощью «kinit», проверьте с помощью klist если у вас есть действующий билет на выдачу билетов Kerberos)) Лучше всего делать это с другого хоста, а не с того, на котором возникли проблемы. SSH использует принципала hosts.
kvno host/hostname
kvno host/hostname.domain.name
Если две приведенные выше команды возвращают разные KVNO, найденные с помощью klist по тому же принципу, то обычно локальный файл keytab на сервере UNIX требует сброса. Сброс локальной вкладки, когда она не синхронизирована с KDC в AD, выполняется из командной строки соответствующего хоста и требует привилегий root.
adkeytab -r -u <username>
или используйте учетные данные локального компьютера вместо привилегированного пользователя AD, указанного выше
adkeytab -r -m