Lorsque vous vous connectez à l'un de mes serveurs via ssh, il se bloque juste après l'authentification. Il s'agit de la sortie sur le client avec -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
Et /var/log/secure
sur le serveur, je vois cela (j'ai de la chance d'avoir une session ouverte):
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)
Donc, rien d’évident ne va mal. Le client et le serveur semblent capables de communiquer. Rien dedans /var/log/messages
.
Beaucoup d'espace disque. Certains chemins sont montés (y compris les zones d'accueil), mais mon shell encore actif peut y accéder correctement.
Je peux me connecter à d'autres serveurs; seul celui-ci a le problème. J'ai essayé de redémarrer sshd
. Le fichier de configuration pour sshd
ressemble à celui par défaut, donc rien dedans. Pour autant que je sache, rien n'a changé récemment.
Essayer d'exécuter une commande ( ssh host1 -t bash
, ou -t vi
) semble également se bloquer, alors ne pensez pas que cela a quelque chose à voir avec mes scripts de connexion.
J'ai également essayé de me connecter à partir d'autres hôtes au même emplacement et d'autres emplacements, ou à partir de Windows via Putty, et à me connecter en utilisant un mot de passe au lieu d'une clé.
Je ne sais pas où chercher ni quoi essayer.
Il s'agit d'un serveur RHEL 6.4, 64 bits.
Réponses:
Plusieurs éléments peuvent provoquer un blocage juste après l'authentification SSH.
Cependant, la plupart d'entre eux porteront également d'autres symptômes (le blocage juste après un SSH-auth est juste le symptôme le plus visible)
~/.bashrc
,~/.bash_profile
,~/.profile
,~/.kshrc
Et ainsi de suitefork()
trop de processus enfants et la charge ( le 1/5/15 ) est trop élevée.la source
Une autre source de problèmes pourrait être les clients ssh attendant ssh-agent (tous ceux configurés pour l'utiliser, bien sûr). Si quelque chose reste coincé
puis vérifiez
ps auxw | grep askpass
et ses dialogues qui pourraient avoir échappé à votre attention.PS: ce n'est pas le coupable ici, mais je n'ai pas cherché sur Google des questions plus pertinentes jusqu'à présent.
la source
Se connecte-t-il directement si vous l'utilisez
ssh -o GSSAPIAuthentication=no user@host
?Si tel est le cas, le système peut être suspendu à un moment donné pour décider d'une méthode GSSAPI. Pour moi, un seul hôte a fait cela, donc je viens de désactiver GSSAPI
~/.ssh/config
pour cet hôte:J'ai appris cela de http://germanrumm.eu/fixing-ssh-login-delay-how-to-disable-gssapi-with-mic-on-ubuntu-linux/ mais je n'ai jamais tout à fait appris la cause.
la source