SSH trava após a autenticação

Question

Ao efetuar login em um dos meus servidores por meio do ssh, ele apenas trava após a autenticação. Esta é a saída no cliente com -v .

OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to host1 [10.6.27.64] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type -1
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: loaded 3 keys
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_4.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 'host1' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:172
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: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/identity
debug1: Offering public key: /home/user/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = C
debug1: Sending env LC_ALL = C
Last login: Wed May 21 10:24:14 2014 from host2
This machine has been configured with kickstart
host1 in bcinf17 in bay 3 in rack D10-Mid

E em /var/log/secure no servidor, vejo isso (ainda tenho uma sessão aberta):

May 21 10:27:31 host1 sshd[12387]: Accepted publickey for user from 1.1.11.239 port 34135 ssh2
May 21 10:27:31 host1 sshd[12387]: pam_unix(sshd:session): session opened for user user by (uid=0)

Então, nada de óbvio está errado. O cliente e o servidor parecem capazes de se comunicar. Nada em /var/log/messages .

Muito espaço em disco. Alguns caminhos são montados (incluindo áreas de origem), mas meu shell ainda ativo pode acessá-los OK.

Eu posso me conectar a outros servidores; só este tem o problema. Eu tentei reiniciar o sshd . O arquivo de configuração para sshd se parece com o padrão, então nada ali. Tanto quanto sei, nada mudou recentemente.

Tentar executar um comando ( ssh host1 -t bash , ou -t vi ) também parece travar, então não pense que seja alguma coisa a ver com meus scripts de login.

Também tentei fazer login de outros hosts no mesmo local e em outros locais, ou do Windows via Putty, e fazer login usando a senha em vez da chave.

Não tenho certeza de onde mais procurar ou o que mais tentar.

Este é um servidor RHEL 6.4, 64 bits.

    

Answer 1

Existem várias coisas que podem causar um travamento logo após a autenticação SSH.

No entanto, a maioria deles também carrega outros sintomas (o problema ocorre logo após o SSH-auth ser apenas o sintoma mais visível)

1. Como Iain mencionou, qualquer script de login de usuário.
   • ~/.bashrc , ~/.bash_profile , ~/.profile , ~/.kshrc e assim por diante
2. Muitos processos em execução / reinicialização.
   • Alguma coisa tem fork() 'muitos processos-filhos e a carga ( Pontuação 1/5/15 ) é muito alta.
3. Existe um problema de espera de E / S.
   • Geralmente causado por um disco rígido em estado de morte (comum) ou por um NIC mal comportado (raro).
4. Um módulo PAM de terceiros suspenso (por exemplo: uma configuração do Kerberos não padrão)
   • Nem sempre o módulo em si, mas às vezes um serviço (como auditoria) que possui um servidor de log completo em algum lugar.

Answer 2

Ele se conecta diretamente se você usa ssh -o GSSAPIAuthentication=no user@host ?

Em caso afirmativo, o sistema pode estar suspenso em algum momento, decidindo sobre um método GSSAPI. Para mim, apenas um host fez isso. Por isso, desativei o GSSAPI em ~/.ssh/config para esse host:

Host badHostName
    GSSAPIAuthentication no

Eu aprendi isso com link < mas nunca aprendi a causa.

    

Answer 3

No entanto, outra fonte de problemas pode ser os clientes ssh esperando por ssh-agent (todos configurados para usá-lo, é claro). Se ssh'ing em qualquer lugar fica preso em

debug1: SSH2_MSG_NEWKEYS received

verifique então ps auxw | grep askpass e suas caixas de diálogo que podem ter escapado à sua atenção.

PS: não é o culpado, mas ainda não pesquisei questões mais relevantes até agora.