Autenticação Putty Kerberos / GSSAPI

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

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

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

Também funciona no Cygwin (cliente openSSH), usando as mesmas configurações de .ssh / config, além de executar o comando kinit para obter um ticket.

Além disso, o Samba compartilha em todos os sistemas Linux, incluindo diretórios pessoais, funciona no Windows Explorer sem exigir uma senha (não tenho certeza se o GSSAPI entra em ação)

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

Ativei o registro de pacotes putty SSH. Achei esse tipo de coisa interessante, ainda não sei o que fazer com essas informações:

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.

Em máquinas Windows que fazem parte de um domínio do Active Directory, os usuários recebem seus tíquetes de concessão de tíquetes Kerberos ao fazer login no Windows e o PuTTY pode usá-los para autenticação se a autenticação GSSAPI estiver ativada em Conexão de configuração PuTTY | SSH | Auth | GSSAPI (e outros métodos de autenticação que ele tenta antes do GSSAPI, como chave pública via Pageant, não serem configurados ou desativados no Connection | SSH | Auth).

[Se você também precisar de delegação de tíquetes (por exemplo, para montar sistemas de arquivos kerberizados no servidor após o login), verifique se a delegação GSSAPI também está ativada no PuTTY e se os servidores nos quais você faz login estão marcados no Active Directory na guia Delegação como " Confie neste computador para delegação a qualquer serviço (somente Kerberos) ", o que não é por padrão. Essa última configuração de confiança no AD é estranhamente necessária apenas para que a delegação funcione a partir de clientes Windows como PuTTY; não é necessário para clientes "ssh -K" do Linux.]

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 delegação de ticket) via PuTTY, mas é necessário obter o ticket. Infelizmente, o Windows 7 não vem instalado com nenhum 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 MIT Kerberos para Windowspacote, que inclui as ferramentas comuns de linha de comando kinit / klist / kdestroy, bem como uma ferramenta de interface gráfica "MIT Kerberos Ticket Manager". Use-os para obter seu ticket e, em seguida, o PuTTY usará automaticamente a biblioteca MIT GSSAPI em vez da biblioteca Microsoft SSPI, e tudo deverá funcionar. Se o "MIT Kerberos Ticket Manager" estiver em execução, ele solicitará automaticamente sua senha Kerberos quando o PuTTY precisar de um ticket, portanto, é uma boa idéia vinculá-lo na pasta Inicialização.

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

Historicamente, é tudo o que preciso fazer para que o login SSH sem senha funcione via Kerberos.

O problema estava na instalação do Windows Kerberos. Acho que nosso Active Directory está configurado, que eu realmente não sei se não sou um administrador do Windows.

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

Após uma reinicialização na minha estação de trabalho remota, não consegui entrar no meu PC. Isso ocorre porque na configuração original a parte do TLD do meu domínio de região 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 nome completo do domínio de região (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 meu domínio padrão e estava em letras minúsculas.

Eu usei "nslookup -type = SRV _kerberos._tcp.domain.TLD" para obter todos os servidores kdc da minha região.

Eu não coloquei nenhuma bandeira.

Eu defini o meu nome de usuário "ksetup / mapuser user@domain.TLD user"

Recursos que usei: https://wiki.ncsa.illinois.edu/display/ITS/Windows+7+Kerberos+Login+using+External+Kerberos+KDC

https://www.cgl.ucsf.edu/Security/CGLAUTH/CGLAUTH.html

Se alguém tiver alguma sugestão que eu possa dar aos administradores do Windows sobre como eles podem corrigir isso (está quebrado?), Eu o passo adiante.