Problema SSH estranho - Host único que não permite que eu faça login por nome

Question

Alguém pode explicar isso, porque eu fiz de tudo, desde a regeneração de chaves, até "sair" e reunir o domínio (Centrify) para um host SSH que não consigo acessar por um único cliente. Todos os outros clientes podem acessar esse host, exceto um. Estranhamente, no entanto, posso SSH para o host do cliente se eu usar o endereço IP:

$ ssh ddecker@host
Connection closed by 10.0.0.250
$ ssh [email protected]
Password:
[ddecker@host ~]$

A única coisa que eu tenho sobre isso é dentro de / var / log / messages no host, eu recebo o seguinte ao tentar usar o hostname:

fatal: accept_ctx died [preauth]

Eu tentei remover o /etc/krb5.keytab, mas o Centrify não inicia; então eu reverti de volta. Realmente não tenho certeza do que está acontecendo a respeito de porque todos os outros clientes podem se conectar pelo nome e isso, já que o cliente só pode se conectar via IP.

UPDATE # 1:

Aqui está a saída de 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

    

Answer 1

Depurando AD / Kerberos Centrify é sempre irritante.

Você pode tentar ativar a depuração do Centrify no seu servidor com /usr/share/centrifydc/bin/addebug on . Esteja ciente de que isso pode criar arquivos de log muito grandes e, potencialmente, levar a volumes completos, se deixado ativado por muito tempo.

Verifique os SPN's e os KVNO's

Obtenha uma lista de princípios e KVNOs do keytab local no seu servidor. Isso pode exigir que o pacote RPM de utilitários do cliente Kerberos esteja instalado em um servidor Linux (yum install krb5-workstation).

klist -kte 

Compare isso com o Kerberos KVNO conforme determinado pelo seu AD. De outro sistema Centrify enebales Linux: (Requer sessão de login ativa do Kerberos iniciada com “kinit”, verifique com klist se você tiver um ticket de concessão de ticket do kerberos válido) Melhor usar o de outro host que aquele com problemas. o diretor principal.

kvno host/hostname
kvno host/hostname.domain.name

Se os dois comandos acima retornarem diferentes KVNOs, então encontrados com klist para o mesmo princípio, então, tipicamente, o arquivo keytab local no servidor UNIX requer um reset. A redefinição do keytab local quando ele não está em sincronia com o KDC no AD é feito a partir da linha de comando do host em questão e requer privilégios de root.

adkeytab -r -u <username>

ou use as credenciais da conta do computador local em vez do usuário AD privilegiado acima

adkeytab -r -m

    

Answer 2

Os sintomas sugerem que o kerberos está quebrado para um cliente. Se você ssh via IP, o kerberos geralmente não está envolvido.

A causa mais comum de kerberos quebrada para um cliente é que o tempo está fora de sincronia naquele cliente. O Kerberos requer que todos os hosts envolvidos tenham seus relógios do sistema aproximadamente em sincronia.

/bin/date 

no cliente e no servidor deve estar dentro de segundos um do outro.

    

Answer 3

Então, graças a todos eles me deram algumas recomendações. Acabei encontrando o problema, no entanto. Eu tinha escrito um script simples que basicamente copia minha chave SSH para cada servidor e sabe quais são os servidores por um arquivo simples.

Então, eu não vi nenhum erro em nada, mas para esse host, parece que eu tinha uma entrada "known_hosts" que entrava em conflito com a minha chave SSH, e basicamente seria apenas soltar minha conexão. Eu apaguei o arquivo known_hosts (tudo que eu tinha que fazer era remover o item em known_hosts) e, em seguida, tentei novamente a minha conexão - e recebi acesso.

Correção simples, mas os erros não ajudavam ou apontavam para uma correção óbvia.

Obrigado!