SSH login delay - Nenhum cache de credenciais encontrado

Question

Eu tenho uma caixa de salto em que os logins de SSH para outros servidores começaram a sofrer atrasos pesados (mais de 20 segundos). Este problema é exibido a partir desta caixa de salto para qualquer destino, registrando no mesmo destino de uma fonte diferente não exibe o mesmo atraso.

Abaixo está a saída detalhada do cliente SSH, os atrasos na saída de depuração estão sempre em debug1: Miscellaneous failure :

# ssh -vvv x.x.x.x
OpenSSH_5.9p1 (CentrifyDC build 4.5.3-557) (CentrifyDC build 4.5.3-557),OpenSSL 0.9.8k (CentrifyDC build 4.5.3-557) 25 Mar 2009
debug1: Reading configuration data /root/.ssh/config
debug1: /root/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/centrifydc/ssh/ssh_config
debug1: /etc/centrifydc/ssh/ssh_config line 52: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to x.x.x.x [x.x.x.x] port 22.
debug1: Connection established.
debug3: permantently_set_uid getpwnam(root)
debug3: getpwnam returned 0, uid = 0 
debug1: permanently_set_uid: 0/0
debug3: Incorrect RSA1 identifier
debug3: Could not load "/root/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2
debug1: match: OpenSSH_6.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug2: fd 3 setting O_NONBLOCK
#######DELAY#######
debug1: Miscellaneous failure
No credentials cache found

#######DELAY#######
debug1: Miscellaneous failure
No credentials cache found

debug3: load_hostkeys: loading entries for host "x.x.x.x" from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /root/.ssh/known_hosts:36
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],[email protected],[email protected],ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 47:4f:f2:cb:0a:f3:47:f7:77:a4:12:d6:a8:81:21:d8
debug3: load_hostkeys: loading entries for host "x.x.x.x" from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /root/.ssh/known_hosts:36
debug3: load_hostkeys: loaded 1 keys
debug1: Host 'x.x.x.x' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:36
debug1: ssh_ecdsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/id_rsa (0x959db0)
debug3: input_userauth_banner
S
Kernel 3.10.0-327.10.1.el7.x86_64 on an x86_64

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
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
#######DELAY#######
debug1: Miscellaneous failure
No credentials cache found

#######DELAY#######
debug1: Miscellaneous failure
No credentials cache found

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: Offering RSA public key: /root/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp 89:18:67:ee:6a:09:90:f4:9a:9e:3f:1e:b3:1f:dc:41
debug3: sign_and_send_pubkey: RSA 89:18:67:ee:6a:09:90:f4:9a:9e:3f:1e:b3:1f:dc:41
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to x.x.x.x ([x.x.x.x]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: fd 3 setting TCP_NODELAY
debug2: channel 0: request pty-req confirm 1
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Thu Nov  9 02:30:14 2017 from y.y.y.y
[[email protected] ~]# 

    

Answer 1

As mensagens de erro vêm do mecanismo de autenticação Kerberos, embora eu possa adivinhar a causa exata dos atrasos.

• Seu cliente e servidor suportam a autenticação Kerberos por meio do GSSAPI.

  Na verdade, você não tem credenciais do Kerberos (kinit), mas o cliente realmente não sabe disso, apenas o mecanismo GSSAPI (Kerberos). Portanto, enquanto o GSSAPI estiver ativado, o cliente tentará usá-lo independentemente.

• Tradicionalmente, o Kerberos no lado do cliente depende do DNS reverso para determinar o nome completo do domínio do servidor. Às vezes, o rDNS para endereços IP internos é quebrado de tal forma que não retornará simplesmente um sucesso ou uma falha; ele não retornará uma resposta e o cliente é forçado a aguardar todo o tempo limite da consulta. (Por exemplo, o servidor DNS do ISP ou da empresa pode ter "proteções" que bloqueiam a resposta completamente.)

  O Kerberos pode precisar saber o nome do domínio para encontrar as credenciais corretas, portanto, ele executará a verificação do rDNS antes , mesmo procurando se você tem um cache de credenciais.

Recomendações:

1. Execute time host x.x.x.x (onde x.x.x.x é o endereço IP do servidor) e verifique quanto tempo demora para a resolução de DNS. Uma falha instantânea está bem; um longo atraso não é.

2. Defina as opções GSSAPIAuthentication e GSSAPIKeyExchange no cliente SSH como "off", via linha de comando ou ssh_config (5) , para desabilitar temporariamente o Kerberos.

3. Se você sabe que o Kerberos não é suportado pela sua rede, desabilite a mesma opção na configuração do SSH servidor para simplesmente ignorar completamente o processo.

   (Não há necessidade de desativá-lo em ambos os lados. Se os servidores não o oferecerem, os clientes não se incomodarão em tentar.)

Apesar de você ter instalado Centrify SSH ao invés do usual OpenSSH, eu acho que você faz tem uma configuração Kerberos funcionando (ou pelo menos tinha algum ponto), e em vez de desabilitá-lo, olhar para consertá-lo seria um pouco melhor.