Autenticação Putty Kerberos / GSSAPI

Question

Configurei alguns servidores Linux para autenticar com o Kerberos do Active Directory usando sssd no RHEL6. Eu também habilitei a autenticação GSSAPI na esperança de logins sem senha.

Mas parece que não consigo colocar Putty (0,63) para autenticar sem uma senha.

O GSSAPI funciona entre os sistemas Linux (cliente openSSH) que estão configurados para autenticação do AD, usando as configurações de .ssh / config para ativar o GSSAPI.

Ele também funciona a partir do Cygwin (cliente openSSH), usando as mesmas configurações de .ssh / config, bem como executando o comando kinit para obter um ticket.

Também os compartilhamentos de Samba em todos os sistemas Linux, incluindo os diretórios home, funcionam no Windows Explorer sem exigir uma senha (não tenho certeza se o GSSAPI entra em ação lá)

Que tipo de coisas posso tentar solucionar isso? A maioria dos meus usuários usa o Putty. Além disso, não sou um administrador do Windows, portanto não posso fazer nada nos controladores de domínio. Minha conta só tem privilégios para adicionar servidores ao domínio do AD.

Liguei o log de pacotes SSH. Eu achei isso interessante, não sei o que fazer com essa informação ainda:

Event Log: Server version: SSH-2.0-OpenSSH_5.3
Event Log: Using SSH protocol version 2
Event Log: We claim version: SSH-2.0-PuTTY_Release_0.63
Outgoing packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
Incoming packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
Event Log: Doing Diffie-Hellman group exchange
Outgoing packet #0x1, type 30 / 0x1e (SSH2_MSG_KEX_DH_GEX_REQUEST)
Incoming packet #0x1, type 31 / 0x1f (SSH2_MSG_KEX_DH_GEX_GROUP)
Event Log: Doing Diffie-Hellman key exchange with hash SHA-256
Outgoing packet #0x2, type 32 / 0x20 (SSH2_MSG_KEX_DH_GEX_INIT)
Incoming packet #0x2, type 33 / 0x21 (SSH2_MSG_KEX_DH_GEX_REPLY)
Outgoing packet #0x3, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Initialised AES-256 SDCTR client->server encryption
Event Log: Initialised HMAC-SHA1 client->server MAC algorithm
Outgoing raw data at 2014-11-25 00:21:08
Incoming packet #0x3, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Initialised AES-256 SDCTR server->client encryption
Event Log: Initialised HMAC-SHA1 server->client MAC algorithm
Outgoing packet #0x4, type 5 / 0x05 (SSH2_MSG_SERVICE_REQUEST)
Incoming packet #0x6, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
...%gssapi-keyex
,gssapi-with-mic
,password.
Event Log: Using SSPI from SECUR32.DLL
Event Log: Attempting GSSAPI authentication
Outgoing packet #0x6, type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
Incoming packet #0x7, type 60 / 0x3c (SSH2_MSG_USERAUTH_GSSAPI_RESPONSE)
Event Log: GSSAPI authentication initialised
Outgoing packet #0x7, type 61 / 0x3d (SSH2_MSG_USERAUTH_GSSAPI_TOKEN)
Incoming packet #0x8, type 61 / 0x3d (SSH2_MSG_USERAUTH_GSSAPI_TOKEN)
Event Log: GSSAPI authentication initialised
Event Log: GSSAPI authentication loop finished OK
Outgoing packet #0x8, type 66 / 0x42 (SSH2_MSG_USERAUTH_GSSAPI_MIC)
Incoming packet #0x9, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
...%gssapi-keyex
,gssapi-with-mic
,password.

    

Answer 1

Em máquinas Windows que fazem parte de um domínio do Active Directory, os usuários recebem seu tíquete de concessão de tíquete Kerberos quando fazem logon no Windows, e o PuTTY pode usá-lo para autenticação se a autenticação GSSAPI estiver ativada no PuTTY Configuration Connection | SSH | O Auth | GSSAPI (e outros métodos de autenticação que ele tenta antes do GSSAPI, como a chave pública via Pageant, não estão configurados ou estão desativados no Connection | SSH | Auth).

[Se você também precisar de delegação de ticket (por exemplo, para montar sistemas de arquivos kerberizados no servidor após o login), certifique-se de que a delegação GSSAPI também esteja habilitada no PuTTY, e nos servidores nos quais você faz login são marcados no Active Directory na guia Delegação como " Confiar neste computador para delegação para qualquer serviço (somente Kerberos) ", que não são por padrão. Essa configuração de confiança no AD é estranhamente necessária apenas para que a delegação trabalhe em clientes Windows como o PuTTY; não é necessário para o Linux" ssh -K "clientes.]

Em máquinas Windows autogerenciadas (pessoais) que não fazem parte de um domínio do Active Directory, você ainda pode usar a autenticação Kerberos / GSSAPI (e a delegação de tickets) via PuTTY, mas é necessário obter o ticket por conta própria. Infelizmente, o Windows 7 não vem instalado com qualquer equivalente do programa kinit (para você solicitar manualmente um ticket), e o PuTTY também não solicita sua senha do Kerberos se você não tiver um ticket. Portanto, você precisa instalar o pacote MIT Kerberos para Windows , que inclui os dois comandos usuais kinit / klist / kdestroy. ferramentas de linha, bem como uma ferramenta limpa GUI "MIT Kerberos Ticket Manager". Use-os para obter seu tíquete e, em seguida, o PuTTY usará automaticamente a biblioteca MIT GSSAPI em vez da Microsoft, e tudo deve funcionar. Se o "MIT Kerberos Ticket Manager" estiver em execução, ele solicitará automaticamente a senha do Kerberos quando o PuTTY precisar de um ticket, por isso é uma boa ideia vinculá-lo a partir da pasta de inicialização.

    

Answer 2

Primeiro, verifique se a sua saída de klist na caixa do Windows que executa o PuTTY mostra um TGT válido. Em seguida, na configuração de sua sessão PuTTY, certifique-se de que a opção Tentativa de autenticação GSSAPI esteja ativada em Connection - SSH - Auth - GSSAPI . Por fim, verifique se ele está configurado para fazer login com seu nome de usuário automaticamente em Connection - Data . Você pode especificar explicitamente o nome de usuário ou selecionar o botão de opção Usar nome de usuário do sistema .

Historicamente, isso é tudo o que eu precisava fazer para tornar o trabalho de login SSH sem senha via Kerberos.

    

Answer 3

O problema estava na configuração do Windows Kerberos. Acho que nosso Active Directory está configurado como funky, não sei se sou administrador do Windows.

Mas eu consertei o problema configurando manualmente o Kerberos usando o ksetup na CLI do Windows 7.

Após uma reinicialização em minha estação de trabalho remota, não consegui fazer login no meu PC. Isso porque na configuração original a parte do TLD do meu território estava sempre ausente (domínio \ usuário), mas depois que eu o configurei manualmente tive que alterar meu domínio de login para refletir o domínio completo do domínio (domínio.TLD \ usuário) e Consegui fazer login no meu PC com Windows, embora pareça demorar mais para autenticar agora.

Antes das alterações, a saída do ksetup mostrava apenas o meu padrão, e estava em minúsculas.

Eu usei "nslookup -type = SRV _kerberos._tcp.domain.TLD" para obter todos os servidores kdc do meu domínio.

Não defini sinalizadores.

Eu configurei meu nome de usuário mapeado "ksetup / user do usuário do [email protected]"

Recursos que usei: link

link

Se alguém tiver alguma sugestão, posso dar ao pessoal de administração do Windows como ele pode consertar isso (será que foi quebrado?). Vou passar adiante.