При входе одного из моих серверов по 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 бита.
Есть несколько вещей, которые могут вызвать зависание сразу после аутентификации SSH.
Однако большинство из них также будут иметь другие симптомы (зависание сразу после SSH-аутентификации является наиболее заметным симптом)
~ / .bashrc
, ~ / .bash_profile
, ~ / .profile
, ~ / .kshrc
и так далее fork ()
слишком много дочерних процессов и нагрузка ( оценка 1/5/15 ) слишком высока. Он подключается напрямую, если вы используете 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 / , но причину так и не выяснил.
Еще одна проблема источником могут быть клиенты ssh, ожидающие ssh-agent (конечно, все настроенные на его использование). Если ssh'ing где-нибудь застревает на
debug1: SSH2_MSG_NEWKEYS получено
, тогда проверьте ps auxw | grep askpass
и его диалоговые окна, которые могли ускользнуть от вашего внимания.
PS: это скорее , а не виновник здесь, но я не искал более подходящие вопросы ] так далеко.