Назад | Перейти на главную страницу

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. Как упоминал Иэн, любые сценарии входа в систему.
    • ~/.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: это скорее не виноват здесь, но я не искал более актуального в Google вопросы до сих пор.

Он подключается напрямую, если вы используете 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/ но так и не узнал причину.