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 через Шпаклевку, и войти в систему с помощью пароля вместо ключа.

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

Это - сервер RHEL 6.4, 64 бита.

8
задан 21 May 2014 в 12:47
4 ответа

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

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

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

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

1
ответ дан 2 December 2019 в 23:05

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

debug1: SSH2_MSG_NEWKEYS получено

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

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

1
ответ дан 2 December 2019 в 23:05

Древний пост, но на случай, если он поможет кому-то еще, я выяснил, почему мой SSH зависал после входа в систему (Debian 10). Именно эту строку я включил и установил в своем файле sshd_config:

PermitTTY no
0
ответ дан 1 May 2021 в 19:47

Теги

Похожие вопросы