SSH зависает после аутентификации

При входе на один из моих серверов через ssh он просто зависает после аутентификации. Это вывод на клиент с -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

И /var/log/secureна сервере я вижу это (к счастью, у меня все еще открыт сеанс):

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)

Так что ничего очевидного не получается. Кажется, клиент и сервер могут общаться. Ничего в /var/log/messages.

Много места на диске. Некоторые пути смонтированы (включая домашние области), но моя все еще активная оболочка может получить к ним доступ.

Я могу подключиться к другим серверам; только у этого есть проблема. Я попытался перезапустить sshd. Файл конфигурации для sshdвыглядит как по умолчанию, так что там ничего нет. Насколько я знаю, ничего не изменилось в последнее время.

Попытка выполнить команду ( ssh host1 -t bashили -t vi) также кажется зависшей, так что не думайте, что это как-то связано с моими сценариями входа.

Также пытались войти с других хостов в том же месте и в других местах, или из Windows через Putty, и войти, используя пароль вместо ключа.

Не уверен, где еще искать или что еще попробовать.

Это сервер RHEL 6.4, 64-битный.

Есть несколько вещей, которые могут вызвать зависание сразу после аутентификации SSH.

Однако большинство из них также будут иметь другие симптомы (зависание сразу после SSH-аутентификации является наиболее заметным симптомом)

1. Как уже упоминалось Iain, любые сценарии входа пользователя.
   • ~/.bashrc, ~/.bash_profile, ~/.profile, ~/.kshrcИ т.д.
2. Слишком много запущенных / перезапускаемых процессов.
   • У чего fork()-то слишком много дочерних процессов, и нагрузка ( оценка 1/5/15 ) слишком высока.
3. Существует проблема ожидания ввода-вывода.
   • Обычно это связано с умирающим жестким диском (обычным) или плохим поведением сетевого адаптера (редко).
4. Зависание стороннего модуля PAM (например, нестандартная конфигурация Kerberos)
   • Не всегда сам модуль, но иногда служба (например, аудит), которая имеет где-то полный лог-сервер.

Еще одним источником проблем могут быть клиенты ssh, ожидающие ssh-agent (конечно, все, кто настроен на его использование). Если ssh'ing где-нибудь застревает

debug1: SSH2_MSG_NEWKEYS получено

затем проверьте ps auxw | grep askpassи его диалоги, которые могли ускользнуть от вашего внимания.

PS: это скорее не виновник, но я до сих пор не нашел более актуальные вопросы .

Подключается ли он напрямую, если вы используете ssh -o GSSAPIAuthentication=no user@host?

Если это так, система может зависнуть в какой-то момент в зависимости от метода GSSAPI. Для меня только один хост сделал это, поэтому я просто отключил GSSAPI ~/.ssh/configдля этого хоста:

Host badHostName
    GSSAPIAuthentication no

Я узнал об этом от http://germanrumm.eu/fixing-ssh-login-delay-how-to-disable-gssapi-with-mic-on-ubuntu-linux/, но так и не узнал причину.