MIT Kerberos continua pedindo senha ao autenticar no OpenSSH

2

Estou tentando configurar um ambiente Kerberos simples, que consiste em um servidor Kerberos (KDC), uma máquina cliente e uma máquina servidor executando um daemon OpenSSH. O cliente deve ser autenticado através do Kerberos ao estabelecer uma conexão SSH com a máquina do servidor.

O nome do usuário do Kerberos que estou tentando autenticar é krbuser . Este usuário existe na máquina de serviço e tem um fluxo de 1001 . O estranho é que eu preciso digitar a senha do usuário Kerberos ao fazer o login com o SSH. Toda vez que eu faço login. Não só pela minha primeira conexão. Isso parece estranho porque o objetivo do Kerberos é autenticar sem uma senha.

Eu peguei um tcpdump durante o processo de autenticação e notei que o cliente está fazendo AS-REQs para o KDC com cname root . Esse nome de usuário do Kerberos não e eu tenho não idéia do motivo pelo qual o cliente está usando esse nome. Como esperado, o KDC responde com uma mensagem eRR-C-PRINCIPAL-UNKNOWN , já que não há nenhum usuário root no banco de dados.

Para mim, parece que o principal problema é o fato de que o cliente tenta autenticar como root em vez de krbuser .

Vou postar algumas informações sobre minha configuração atual abaixo. Por favor, deixe-me saber se você precisar de alguma informação adicional.

No KDC:

/etc/krb5.conf

[logging]
    default = FILE:/usr/local/krb5/var/log/krb5lib.log 
    kdc = FILE:/usr/local/krb5/var/log/krb5kdc.log
    admin_server = FILE:/usr/local/krb5/var/log/kadmin.log

[libdefaults]
    default_realm = metz.prac.os3.nl
    rdns = false

# The following krb5.conf variables are only for MIT Kerberos.
    krb4_config = /etc/krb.conf
    krb4_realms = /etc/krb.realms
    kdc_timesync = 1
    ccache_type = 4
    forwardable = true
    proxiable = true

[realms]
    metz.prac.os3.nl = {
        kdc = krb-0.metz.prac.os3.nl
        admin_server = krb-0.metz.prac.os3.nl
    }

Na máquina de serviço:

/etc/ssh/sshd config (um extrato)

# Kerberos options
KerberosAuthentication yes
# KerberosGetAFSToken no
# KerberosOrLocalPasswd no
# KerberosTicketCleanup yes

# GSSAPI options
GSSAPIAuthentication yes
# GSSAPICleanupCredentials yes

Arquivos de log capturados durante a autenticação SSH:

debug1: rekey after 4294967296 blocks [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user root service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "root"
debug1: PAM: setting PAM_RHOST to "218.65.30.30"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user root service ssh-connection method password [preauth]
debug1: attempt 1 failures 0 [preauth]
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: restore_uid: 0/0
debug1: Kerberos password authentication failed: Client '[email protected]' not found in Kerberos database
debug1: krb5_cleanup_proc called
debug1: inetd sockets after dupping: 5, 5
Connection from 145.100.110.115 port 51946 on 145.100.110.116 port 22
debug1: Client protocol version 2.0; client software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.2 pat OpenSSH* compat 0x04000000
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: permanently_set_uid: 106/65534 [preauth]
debug1: list_hostkey_types: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: algorithm: [email protected] [preauth]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256 [preauth]
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none [preauth]
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: rekey after 134217728 blocks [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: rekey after 134217728 blocks [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user krbuser service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "krbuser"
debug1: PAM: setting PAM_RHOST to "145.100.110.115"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user krbuser service ssh-connection method gssapi-with-mic [preauth]
debug1: attempt 1 failures 0 [preauth]
debug1: PAM: password authentication failed for root: Authentication failure
Failed password for root from 218.65.30.30 port 18460 ssh2
debug1: userauth-request for user root service ssh-connection method password [preauth]
debug1: attempt 2 failures 1 [preauth]
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: restore_uid: 0/0
debug1: Kerberos password authentication failed: Client '[email protected]' not found in Kerberos database
debug1: krb5_cleanup_proc called
debug1: PAM: password authentication failed for root: Authentication failure
Failed password for root from 218.65.30.30 port 18460 ssh2
debug1: userauth-request for user root service ssh-connection method password [preauth]
debug1: attempt 3 failures 2 [preauth]
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: restore_uid: 0/0
debug1: Kerberos password authentication failed: Client '[email protected]' not found in Kerberos database
debug1: krb5_cleanup_proc called
debug1: PAM: password authentication failed for root: Authentication failure
Failed password for root from 218.65.30.30 port 18460 ssh2
debug1: userauth-request for user krbuser service ssh-connection method password [preauth]
debug1: attempt 2 failures 0 [preauth]
debug1: temporarily_use_uid: 1001/1001 (e=0/0)
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 1001/1001 (e=0/0)
debug1: restore_uid: 0/0
debug1: do_pam_account: called
Accepted password for krbuser from 145.100.110.115 port 51946 ssh2
debug1: monitor_child_preauth: krbuser has been authenticated by privileged process
debug1: monitor_read_log: child log fd closed
debug1: temporarily_use_uid: 1001/1001 (e=0/0)
debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism
debug1: restore_uid: 0/0
debug1: PAM: establishing credentials
User child is on pid 20617
debug1: SELinux support disabled
debug1: PAM: establishing credentials
debug1: permanently_set_uid: 1001/1001
debug1: rekey after 134217728 blocks
debug1: rekey after 134217728 blocks
debug1: ssh_packet_set_postauth: called
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_global_request: rtype [email protected] want_reply 0
debug1: server_input_channel_req: channel 0 request pty-req reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug1: session_new: session 0
debug1: SELinux support disabled
debug1: session_pty_req: session 0 alloc /dev/pts/2
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request shell reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
Starting session: shell on pts/2 for krbuser from 145.100.110.115 port 51946 id 0
debug1: Setting controlling tty using TIOCSCTTY.
debug1: userauth-request for user root service ssh-connection method password [preauth]
debug1: attempt 4 failures 3 [preauth]
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: restore_uid: 0/0
debug1: Kerberos password authentication failed: Client '[email protected]' not found in Kerberos database
debug1: krb5_cleanup_proc called
debug1: PAM: password authentication failed for root: Authentication failure
Failed password for root from 218.65.30.30 port 18460 ssh2
debug1: userauth-request for user root service ssh-connection method password [preauth]
debug1: attempt 5 failures 4 [preauth]
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: restore_uid: 0/0
debug1: Kerberos password authentication failed: Client '[email protected]' not found in Kerberos database
debug1: krb5_cleanup_proc called
debug1: PAM: password authentication failed for root: Authentication failure
Failed password for root from 218.65.30.30 port 18460 ssh2
debug1: userauth-request for user root service ssh-connection method password [preauth]
debug1: attempt 6 failures 5 [preauth]
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: restore_uid: 0/0
debug1: Kerberos password authentication failed: Client '[email protected]' not found in Kerberos database
debug1: krb5_cleanup_proc called
debug1: PAM: password authentication failed for root: Authentication failure
Failed password for root from 218.65.30.30 port 18460 ssh2
maximum authentication attempts exceeded for root from 218.65.30.30 port 18460 ssh2 [preauth]
Disconnecting: Too many authentication failures [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed
debug1: do_cleanup
debug1: PAM: cleanup
debug1: Killing privsep child 20604
debug1: audit_event: unhandled event 12
debug1: inetd sockets after dupping: 5, 5
Connection from 218.65.30.30 port 58146 on 145.100.110.116 port 22
debug1: Client protocol version 2.0; client software version nsssh2_4.0.0032 NetSarang Computer, Inc.
debug1: no match: nsssh2_4.0.0032 NetSarang Computer, Inc.
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: permanently_set_uid: 106/65534 [preauth]
debug1: list_hostkey_types: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: algorithm: diffie-hellman-group14-sha1 [preauth]
debug1: kex: host key algorithm: ssh-rsa [preauth]
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha1 compression: none [preauth]
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha1 compression: none [preauth]
debug1: expecting SSH2_MSG_KEXDH_INIT [preauth]

Na máquina do cliente:

kinit e klist antes da autenticação:

$ kinit -p krbuser
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: [email protected]

Valid starting     Expires            Service principal
06/15/17 00:24:05  06/15/17 10:24:05  krbtgt/[email protected]
    renew until 06/16/17 00:23:56

/etc/ssh/ssh config (um extrato):

    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials yes
#   GSSAPIKeyExchange no
#   GSSAPITrustDNS no

E finalmente a autenticação SSH:

$ ssh [email protected] -vvv
...
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "service-0.metz.prac.os3.nl" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to service-0.metz.prac.os3.nl [145.***.***.***] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
...
debug1: Found key in /home/client/.ssh/known_hosts:3
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/client/.ssh/id_rsa ((nil))
debug2: key: /home/client/.ssh/id_dsa ((nil))
debug2: key: /home/client/.ssh/id_ecdsa ((nil))
debug2: key: /home/client/.ssh/id_ed25519 ((nil))
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug3: send packet: type 50
debug2: we sent a gssapi-with-mic packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: send packet: type 50
debug2: we sent a gssapi-with-mic packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: send packet: type 50
debug2: we sent a gssapi-with-mic packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: send packet: type 50
debug2: we sent a gssapi-with-mic packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
...
debug1: Next authentication method: password
[email protected]'s password: <entering PW of Kerberos user> !!!
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 52
debug1: Authentication succeeded (password).
Authenticated to service-0.metz.prac.os3.nl ([145.***.***.***]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug3: receive packet: type 91
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
...
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Thu Jun 15 00:28:57 2017

Connection established

Agora, klist mostra os seguintes tickets:

$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: [email protected]

Valid starting     Expires            Service principal
06/15/17 00:24:05  06/15/17 10:24:05  krbtgt/[email protected]
    renew until 06/16/17 00:23:56
06/15/17 00:27:37  06/15/17 10:24:05  host/service-0.metz.prac.os3.nl@
    renew until 06/16/17 00:23:56
06/15/17 00:27:37  06/15/17 10:24:05  host/[email protected]
    renew until 06/16/17 00:23:56

Então, para resumir: O usuário Kerberos no cliente pode estabelecer uma sessão SSH para o servidor digitando sua senha Kerberos (!). Não é sua senha do UNIX. O tcpdump mostrou que o cliente autentica como root , que não é um usuário do Kerberos, e não tenho idéia de por que ele está usando esse nome de usuário, em vez de krbuser . Qual é o que eu usei com o comando kinit .

Alguém pode me dizer por que esta autenticação não está funcionando corretamente? Por favor, deixe-me saber se você precisar de informações adicionais. Eu tentei manter isso curto.

    
por arne.z 15.06.2017 / 00:58

3 respostas

2

Login raiz

A julgar pelos seus arquivos de log fornecidos, eu diria que a tentativa de login raiz não é seu problema aqui. Observe que todas as tentativas de autenticação como raiz vêm de 218.65.30.30 , um simples comando whois nos diz que este é um IP da China. Os outros IPs envolvidos com êxito nesta autenticação 145.100.110.11{5,6} são provenientes do mesmo netblock (administrado pela universidade). Eu suponho que estas são suas máquinas de interesse. Eu também recomendaria muito instalar algo como fail2ban que bloqueia IPs que estão tentando forçar você.

SSH

Agora vamos resolver o problema do Kerberos. Eu configurei recentemente um ambiente Kerberos, isso foi cheio de dificuldades, então eu sinto sua dor! Sua configuração do SSH parece boa para que possamos descartar isso. Embora, do ponto de vista da segurança, você queira considerar, a configuração de GSSAPIDelegateCredentials yes no seu /etc/ssh/ssh_config é realmente necessária? Embora seja conveniente, esta opção irá expor o seu TGT a qualquer máquina em que você esteja trabalhando.

Cavalos do Keberos

Duas das principais coisas que as configurações do kerberos são sensíveis são a distorção de tempo e a resolução de nomes. Acho improvável que o tempo skew seja o seu problema aqui . Seria mais fácil confirmar isso com seus logs do kerberos. A maioria das distribuições GNU / Linux modernas vem com o tempo de rede já configurado. Você pode verificar isso usando algo como timedatectl . Você também deve certificar-se de que o DNS direto e reverso esteja configurado corretamente para cada host em seu ambiente.

Um aparte sobre reinos - embora nem sempre estritamente necessário, a convenção é manter seu reino em MAIÚSCULAS. Esta é uma necessidade absoluta quando você está trabalhando em ambientes GNU / Linux e Windows mistos, às vezes isso resultará em falha total para o trabalho. Se você mantiver isso em geral, você tornará a vida mais fácil para você.

Os nomes de host correspondem a nomes DNS e nomes de teclas?

A principal coisa que mais me chama a atenção aqui é o tíquete de serviço que você tem com o domínio vazio, ou seja, do SPN host/service-0.metz.prac.os3.nl@ . Para mim, isso cheira a algo que está acontecendo com sua configuração de rede . Parece que o seu default_realm está definido corretamente, por isso, acho que há um problema nos hosts finais . Para depurar isso, eu recomendaria iniciar uma nova instância de sshd no serviço com log extra ( sudo /usr/sbin/sshd -p 9001 -D -dd ) e, em seguida, tentar conectar-se a partir do cliente ( ssh -p 9001 -vv [email protected] ). Isso mostrará de ambos os lados exatamente o que está acontecendo durante a autenticação e quais SPNs estão realmente sendo usados.

Ocorreu um problema recentemente em que a autenticação falhou porque o serviço ao qual eu estava me conectando não conhecia seu próprio FQDN (ou seja, o serviço tentou localizar a entrada keytab para host/service-0@REALM em vez de host/service-0.rest.of.domain@REALM ). Você pode verificar isso usando hostname --fqdn , se isso não retornar o nome DNS completo do sistema, então você pode editar /etc/hosts . Certifique-se de que a saída de hostname --fqdn corresponda ao que está no DNS .

Por fim, verifique se você tem um arquivo keytab para cada host que possui o SPN correto . Isso deve parecer com host/service-0.rest.of.domain@REALM . Você pode verificar o conteúdo do seu arquivo keytab usando klist -k /path/to/keytab . Depuração feliz! Eu sei o quão frustrante o Kerberos pode ser.

A opção nuclear

Se você ainda está muito adiantado em sua fase de configuração, pode ser mais fácil matar sua configuração com fogo e começar do zero :). Manter tudo isso em mente e seguir um bom guia pode poupar algum tempo a longo prazo.

    
por 20.06.2017 / 12:32
1

Há várias coisas a serem consideradas:

1. Você consegue o tíquete de serviço na sua máquina cliente?

Verifique se você pode obter o ticket para o serviço que deseja usar. Para o SSH, geralmente é host / @ REALM ou, no seu caso, host/[email protected]. Se você executar kvno host/[email protected] na máquina do cliente (onde também executa o ssh), ele deverá informar um número de versão da chave e o ticket deverá ser exibido em klist .

2. Você conseguiu sincronizar o tempo certo?

Certifique-se de que ambas as máquinas tenham o mesmo tempo e fuso horário (caso contrário, o horário pode ser o mesmo, mas em um fuso horário diferente). É provavelmente mais fácil configurar o NTP em todas as máquinas que executam kerberos

3. Você adicionou os princípios do host ao /etc/krb5.keytab?

Na máquina à qual você está se conectando, você deve ter entradas para o host-principal (host / @ REALM) com o número da versão da chave correta (aquele determinado na etapa 1). O arquivo também deve ser legível por sshd

4. Você conseguiu o seu Networking básico certo?

O Kerberos realmente ama DNS avançado e DNS reverso. Na verdade, a maioria dos problemas estranhos com o Kerberos que tive que depurar até agora tinha a ver com a resolução de DNS quebrada, o DNS reverso não apontando para o host FQDN, nomes de host mal configurados, etc.

Certifique-se de que todos os hosts possam resolver todos os outros hosts para frente e para reversão. Também verifique se o nome do host está configurado corretamente ( com nome do domínio) em todas as máquinas. Os comandos hostname , hostname -f , hostname -s e hostname -i devem retornar resultados sensatos.

Tendo dito tudo isso: considere renomear seu reino. O padrão de fato para reinos kerberos é ALL.CAPS. Então, quando você reconstruir seu laboratório ou começar com seu ambiente de produção, ele deverá ser ALL.IN.UPPER.CASE, então "METZ.PRAC.OS3.NL". Esta é apenas uma convenção, mas talvez alguém dependa disso. Além disso, agora você pode diferenciar seu domínio DNS de seu reino apenas olhando para ele:)

    
por 19.06.2017 / 19:13
0

Você adicionou o nome da máquina cliente aos diretores?
 podemos usar esse comando listprincs ou list_principals para listar essas informações, assim:

Além disso, devemos adicionar a conta de usuário krbuser ao KDC, cliente1 e cliente2, dessa forma, podemos usar o cliente 1 para o cliente ssh 2 com kerberos.

Aqui está o meu laboratório :
servidor: kerberos.example.com
cliente: client.example.com
client2: client2.example.com

servidor KDC :
/etc/krb5.conf

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 dns_lookup_realm = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 rdns = false
 default_realm = EXAMPLE.COM
 default_ccache_name = KEYRING:persistent:%{uid}

[realms]
 EXAMPLE.COM = {
  kdc = kerberos.example.com
  admin_server = kerberos.example.com
 }

[domain_realm]
 .example.com = EXAMPLE.COM
 example.com = EXAMPLE.COM

/var/kerberos/krb5kdc/kdc.conf

[kdcdefaults]
 kdc_ports = 88
 kdc_tcp_ports = 88

[realms]
 EXAMPLE.COM = {
  master_key_type = aes256-cts
  default_principal_flags = +preauth  
  acl_file = /var/kerberos/krb5kdc/kadm5.acl
  dict_file = /usr/share/dict/words
  admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
  supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal camellia256-cts:normal camellia128-cts:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
 }

/ etc / ssh / sshd_conf

# Kerberos options
#KerberosAuthentication yes
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
#KerberosUseKuserok yes

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
#GSSAPIEnablek5users no

Cliente:

/etc/krb5.conf same como servidor, ou você pode copiar o krb5.conf do servidor para este cliente.
/etc/ssh/sshd_conf same como servidor.

client2:

/etc/krb5.conf same como servidor, ou você pode copiar o krb5.conf do servidor para este cliente.
/etc/ssh/sshd_conf same como servidor.

result:

Devemos adicionar uma conta de usuário ao servidor, cliente e cliente2; no meu teste, adicionei user01 ao servidor, cliente e cliente2 .

Servidor:

[user01@kerberos ~]$ klist
Ticket cache: KEYRING:persistent:1001:1001
Default principal: [email protected]

Valid starting       Expires              Service principal
06/16/2017 07:18:18  06/17/2017 07:18:18  krbtgt/[email protected]

Cliente

[root@client ~]# su - user01
Last login: Fri Jun 16 08:16:28 UTC 2017 from client2.example.com on pts/1
[user01@client ~]$ klist
Ticket cache: KEYRING:persistent:1001:1001
Default principal: [email protected]

Valid starting       Expires              Service principal
06/16/2017 08:16:27  06/17/2017 08:16:27  krbtgt/[email protected]

Client2

[root@client2 jason]# su - user01
Last login: Fri Jun 16 08:18:51 UTC 2017 on pts/0
[user01@client2 ~]$ klist
Ticket cache: KEYRING:persistent:1003:1003
Default principal: [email protected]

Valid starting       Expires              Service principal
06/16/2017 08:18:58  06/17/2017 08:18:54  krbtgt/[email protected]

Depois disso, podemos usar user01 para ssh do client2 para o cliente:

[root@client2 jason]# ssh [email protected]
Password: 
Last login: Fri Jun 16 08:17:59 2017
[user01@client ~]$ 

Nota:

Use kerberos que devemos usar ao mesmo tempo, devemos definir NTP para eles, no meu laboratório, eu os crio no Azure, eles têm o mesmo tempo.

Além disso, devemos adicionar o nome da máquina cliente aos principais .

    
por 16.06.2017 / 10:23