Autenticação SSH usando gssapi-keyex ou gssapi-with-mic (chave pública não permitida)

Question

Minha empresa desativou a autenticação de chave pública de SSH, portanto, preciso inserir manualmente cada vez minha senha (não devo alterar /etc/ssh/sshd_config ).

No entanto, as autenticidades gssapi-keyex e gssapi-with-mic estão ativadas (veja abaixo ssh debug output).

Como eu poderia usar o login automático neste caso?
Posso explorar gssapi-keyex e / ou gssapi-with-mic autenticações?

> ssh -v -o PreferredAuthentications=publickey hostxx.domainxx
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to hostxx.domainxx [11.22.33.44] port 22.
debug1: Connection established.
debug1: identity file /home/me/.ssh/identity type -1
debug1: identity file /home/me/.ssh/id_rsa type -1
debug1: identity file /home/me/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
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: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'hostxx.domainxx' is known and matches the RSA host key.
debug1: Found key in /home/me/.ssh/known_hosts:2
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,password
debug1: No more authentication methods to try.
Permission denied (gssapi-keyex,gssapi-with-mic,password).

    

Answer 1

Talvez.

• Você pode obter um ticket para seu principal no sistema do cliente como parte do processo de login padrão ou manualmente ( kinit , MIT Kerberos for Windows)?
• O servidor tem um diretor kerberos ou você pode dar um? Deve estar no formato host/[email protected] .
• A GSSAPI de autenticação está ativada no seu cliente?
• O seu cliente sabe qual região o servidor pertence ao registro de recurso TXT do DNS ou ao mapeamento local?

Se você disse "sim" para all do acima, parabéns, você pode usar GSSAPIAuthentication .

• Você também pode precisar ativar a delegação de credenciais, dependendo da sua configuração.

Passos do teste:
(Supondo que: domain = example.com; realm = EXAMPLE.COM)

1. %código%
   • Idealmente, isso é tratado pelo seu processo de login padrão, incluindo kinit [email protected] ou pam_krb5 (com pam_sss ) no auth_provider = krb5 apropriado.
2. %código%
   • Esta é uma etapa de depuração. pam stack faz isso automaticamente se você tiver um cache válido e estiver falando com um kvno host/[email protected] que suporta ssh ou sshd .
3. gssapi-with-mic deve retornar gssapi-keyex
   • Como alternativa, o mapeamento pode ser armazenado na seção dig _kerberos.example.com txt de "EXAMPLE.COM" as [domain_realm] , mas o método /etc/krb5.conf é muito melhor.
4. %código%
   • Para entrar em um nome de usuário que não seja o do seu principal no servidor, você precisará mapear os detalhes dos quais eu não estou entrando aqui.

Answer 2

O método de 4 etapas está correto (também existem registros SRV do Kerberos no DNS que são ainda mais elegantes e estão presentes em todos os Active Directory). Eu uso isso o tempo todo, e venho advogando os métodos acima mencionados, principalmente por razões de segurança e controle.

Dito isso, isso só dá um login interativo, embora possa ser quase interativo quando você recebe um ticket em sua estação de trabalho. O tíquete Kerberos age muito como o agente SSH; uma vez que você as tenha, as novas conexões são vagas e sem senha; embora com um limite de tempo.

Para obter login em lote interativo, você precisa obter um arquivo keytab, um arquivo que contém essencialmente a senha de uma conta do Kerberos, bem como a metade privada de uma chave SSH. De acordo com as precauções de segurança aplicáveis; especialmente desde que o keytab não é criptografado ou protegido com uma senha.

Estou bastante relutante em fornecer aos meus usuários seus keytabs para suas contas pessoais, mas estou usando agressivamente contas de serviço com permissões mínimas para vários trabalhos em lote, especialmente onde é fundamental que as credenciais sejam delegadas ao sistema remoto, algo pubkey simplesmente não consegue alcançar.

Os keytabs podem ser criados usando o ktutil no Unix ou o KTPASS.EXE no Windows (o segundo nos serviços do AD Kerberos). Note que o ktutil existe em dois tipos, Heimdal e MIT, e sua sintaxe é diferente. Ler a manpage em um sistema relevante ajuda.