SSH se bloque après l'authentification

10

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/securesur 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 sshdressemble à 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.

andrewrjones
la source
La première chose que je ferais est de supprimer tous les scripts de connexion utilisateur juste pour être sûr.
user9517

Réponses:

3

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)

  1. Comme Iain l'a mentionné, tous les scripts de connexion utilisateur.
    • ~/.bashrc, ~/.bash_profile, ~/.profile, ~/.kshrcEt ainsi de suite
  2. Trop de processus en cours d'exécution / redémarrage.
    • Quelque chose a eu fork()trop de processus enfants et la charge ( le 1/5/15 ) est trop élevée.
  3. Il y a un problème d'attente d'E / S.
    • Généralement causée par un disque dur mourant (commun) ou une carte réseau qui se comporte mal (rare).
  4. Un module PAM tiers suspendu (par exemple: une configuration Kerberos non standard)
    • Pas toujours le module lui-même, mais parfois un service (comme l'audit) qui a un serveur de journalisation complet quelque part.
Signal15
la source
2

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é

debug1: SSH2_MSG_NEWKEYS reçu

puis vérifiez ps auxw | grep askpasset 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.

Michael Shigorin
la source
2
Cela a résolu le problème que j'avais. Merci!
dents
Bienvenue :-) Ce n'était pas du tout évident pour moi pendant quelques minutes ...
Michael Shigorin
Je ne sais pas si c'était le problème sous-jacent pour moi, mais j'ai remarqué que je voyais l'erreur suivante en exécutant la commande ci-dessus dans WSL. Cela m'a amené à compter sur git-bash pour Windows qui n'a pas eu le même problème. `` Signal 11 (SEGV) capturé par ps (3.3.12). ps: ps / display.c: 66: veuillez signaler ce bogue `` `
jpierson
1

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/configpour cet hôte:

Host badHostName
    GSSAPIAuthentication no

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.

Shaun
la source