Configurei alguns servidores Linux para autenticação com 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 fazer com que o Putty (0.63) se autentique sem uma senha.
GSSAPI funciona entre sistemas Linux (cliente openSSH) configurados para autenticação AD, usando as configurações .ssh/config para habilitar GSSAPI.
Ele também funciona no Cygwin (cliente openSSH), usando as mesmas configurações .ssh/config e executando o comando kinit para obter um ticket.
Além disso, os compartilhamentos do Samba em todos os sistemas Linux, incluindo os diretórios iniciais, 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 Putty. Além disso, não sou 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 AD.
Ativei o registro de pacotes SSH do PuTTY. Achei isso meio 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.
Responder1
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 login no Windows, e o PuTTY pode usá-lo para autenticação se a autenticação GSSAPI estiver habilitada em PuTTY Configuration Connection|SSH|Auth|GSSAPI (e outros métodos de autenticação que ele tenta antes do GSSAPI, como chave pública via Pageant, não estão configurados ou desabilitados em Connection|SSH|Auth).
[Se você também precisar de delegação de tickets (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,eos 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 em clientes Windows como PuTTY; não é necessária para clientes Linux "ssh -K".]
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 tickets) via PuTTY, mas você mesmo precisa obter o ticket. Infelizmente, o Windows 7 não vem instalado com nenhum equivalente ao programa kinit (para você solicitar manualmente um ticket), e o PuTTY também não solicita sua senha Kerberos se você não tiver um ticket. Portanto, você deve instalar oKerberos do MIT para Windowspacote, que inclui as ferramentas usuais de linha de comando kinit/klist/kdestroy, bem como uma ferramenta GUI bacana "MIT Kerberos Ticket Manager". Use-os para obter seu tíquete e o PuTTY usará automaticamente a biblioteca MIT GSSAPI em vez da biblioteca SSPI da Microsoft, 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, por isso é uma boa ideia vinculá-lo na pasta Inicialização.
Atualizar:A partir do Windows 10 versão 21H1 e do Windows Server 2022, oOpenSSH para Windows(versão 8.1 ou mais recente) cliente e servidor integrados ao Windows agora também suportam autenticação e delegação GSSAPI (ou seja, ssh -K). Portanto, se tudo que você precisa é isso, a partir de 2021 você não precisará mais instalar o PuTTY e o MIT Kerberos.
Responder2
Primeiro verifique se a saída do seu klist na caixa do Windows executando o PuTTY mostra um TGT válido. Então, na configuração da sua sessão PuTTY, certifique-seTentar autenticação GSSAPIestá habilitado em Connection - SSH - Auth - GSSAPI. Por fim, certifique-se de que esteja configurado para fazer login com seu nome de usuário automaticamente no Connection - Data. Você pode especificar explicitamente o nome de usuário ou selecionar o botão de opção paraUsar nome de usuário do sistema.
Historicamente, isso é tudo que preciso fazer para que o login SSH sem senha funcione via Kerberos.
Responder3
O problema estava na configuração do Windows Kerberos. Acho que nosso Active Directory está configurado de maneira estranha, realmente não sei, não sou um administrador do Windows.
Mas resolvi o problema configurando manualmente o Kerberos usando ksetup na CLI do Windows 7.
Após reiniciar minha estação de trabalho remota, não consegui fazer login no meu PC. Isso ocorre porque na configuração original a parte TLD do meu domínio de domínio estava sempre ausente (domínio\usuário), mas depois de configurá-lo manualmente, tive que alterar meu domínio de login para refletir o nome de 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 meu domínio padrão e estava em letras minúsculas.
Usei " nslookup -type=SRV _kerberos._tcp.domain.TLD " para obter todos os servidores kdc do meu reino.
Eu não coloquei nenhum sinalizador.
Eu configurei meu nome de usuário mapeado "ksetup /mapuser[e-mail protegido]do utilizador "
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 ao pessoal administrador do Windows sobre como eles podem consertar isso (está quebrado?), Vou repassar.