ssh se bloque sans invite de mot de passe - fonctionne dans les comptes root ou autres

J'avais une connexion basée sur une clé ssh qui fonctionnait bien. Ensuite, j'ai changé le nom d'hôte sur mon ordinateur et la connexion basée sur les clés a cessé de fonctionner. Semblait logique. les clés reposaient probablement sur mon ancien nom d'hôte. J'ai donc supprimé toutes mes clés et tous les fichiers dans ~ / .ssh / et les ai régénérés (et changé les clés autorisées sur les serveurs auxquels je me connecte)

Maintenant, chaque fois que j'essaie de ssh, il se bloque simplement sans l'invite de mot de passe, peu importe où j'essaie de ssh - même les serveurs sur lesquels je n'ai pas de connexion basée sur une clé. Il n'y a rien dans .ssh / config.

De plus, quand je «su -» pour rooter, ssh fonctionne parfaitement. aucun problème. Cela ne se produit que sur mon compte utilisateur.

Voici quelques informations de débogage de ssh

ssh -vv mylogin@myremoteserver.com
OpenSSH_5.2p1, OpenSSL 0.9.8k 25 mars 2009
debug1: lecture des données de configuration /Users/myname/.ssh/config
debug1: lecture des données de configuration / usr / etc / ssh_config
......
debug1: l'hôte «myremoteserver.com» est connu et correspond à la clé d'hôte RSA.
debug1: clé trouvée dans /Users/myname/.ssh/known_hosts:1
debug2: ensemble de bits: 512/1024
debug1: ssh_rsa_verify: signature correcte
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS envoyé
debug1: attend SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS reçu
debug1: SSH2_MSG_SERVICE_REQUEST envoyé
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT reçu

Et puis il se bloque juste ici .....

Voici la sortie de dtruss (comme strace mais pour OSX) vers la fin où elle se bloque: sudo dtruss ssh -vv mylogin@myremoteserver.com

sélectionner (0x4, 0x508200, 0x0, 0x0, 0x0) = 1 0
lire (0x3, "$ \ 222 \ 351 {L \ 363 \ 261 \ 25063sN \ 216 \ 300 @ q7 \ 203 \ 276b \ 257 \ 354 \ 337 \ 356 \ 260! {\ 342 \ 017 \ 271 = \ 222, \ 245 \ 347t \ 006 \ 225 \ 257 \ 333; \ 204 \ 020] \ 242 \ 005z # \ 0 ", 0x2000) = 48 0
écrire (0x2, "debug2: service_accept: ssh-userauth \ r \ n \ 0", 0x26) = 38 0
connecter (0x4, 0xBFFFEEA2, 0x6A) = 0 0
écriture (0x4, "\ 0", 0x4) = 4 0
écrire (0x4, "\ v5 \ 004 \ 0", 0x1) = 1 0
lire (0x4, "\ 0", 0x4) = -1 Err # 4

Il semble essayer de lire quelque chose et se bloque juste dessus. Si quelqu'un a des suggestions ou des idées, je vous en serais très reconnaissant!

La raison pour laquelle votre client ssh se bloque pour votre compte mais pas pour les autres comptes (root) est probablement parce qu'il y a un problème avec votre agent ssh. Soit que le ssh-agentne fonctionne pas ou que sa configuration est incorrecte d'une manière ou d'une autre.

Pour en avoir la confirmation, vous pouvez essayer ce qui suit:

unset SSH_AUTH_SOCK
ssh mylogin@myremoteserver.com

Si vous êtes ensuite invité à saisir la phrase de passe sur votre ssh_key, cela signifie que vous avez un problème avec votre ssh-agent.

Voir aussi mon article sur cette question connexe .

Puis-je vous intéresser au DNS inversé?

Essentiellement, le client fait le DNS inverse sur le serveur, ou vice versa.

Je propose un test:

Désactivez les recherches DNS sur le serveur en éditant / etc / ssh / sshd_config et en vous assurant que "UseDNS" est défini sur "no".

Exécutez "service ssh reload" (ou quoi que ce soit qui amène votre démon ssh à relire la configuration), puis réessayez.

Soit dit en passant, il n'est pas heureux de finalement vous inviter après une longue période de temps, n'est-ce pas?

Une autre chose que vous pourriez vérifier est de regarder le contenu de / etc / hosts sur le serveur pour vous assurer qu'il n'y a rien de mal là-bas.

Vérifiez les autorisations sur le répertoire ~ / .ssh et les fichiers qu'il contient. Votre umask par défaut peut être trop permissif et lorsque vous avez recréé les fichiers, vous leur avez peut-être accordé par inadvertance les mauvaises autorisations. J'ai été moi-même brûlé par cela plusieurs fois. Aucun des clients (ou serveurs) ssh que j'ai utilisés n'a donné de message d'erreur utile à ce sujet non plus ...

vous avez de l'espace disque libre sur votre client (et sur votre serveur)?

df -h

J'avais un problème similaire.

ssh domain.ip:user.name

Il semble que je puisse contourner le problème en forçant un nom de connexion comme celui-ci.

ssh -v domain.ip -l user.name

Pour moi, la mise à niveau vers Snow Leopard a résolu le problème. Donc, je pense que c'était lié à un bogue dans OSX.

Si c'est à cause d'une clé enregistrée, vous devriez pouvoir la supprimer de votre répertoire ~ / .ssh dans le fichier known_hosts. Il suffit de trouver l'entrée et de la supprimer, puis elle devrait vous inviter à nouveau.

D'un autre côté, il devrait donner un avertissement lorsque l'hôte ne correspond pas à ce qui est enregistré.

J'ai eu des problèmes où sous OS X la recherche de nom d'hôte se comportait comme si elle échouait; la connexion arrive à expiration si vous attendez si longtemps, ou lorsque l'invite apparaît, elle attend depuis si longtemps qu'il vous faut environ dix secondes pour entrer un mot de passe avant de couper la connexion. Je n'ai jamais pu le retracer malgré les gens suggérant d'ajouter l'hôte en question au fichier hôte. Je suppose que c'était juste un "problème avec les recherches DNS d'OS X" et qu'il était censé être toléré ... si quelqu'un d'autre avait ce problème et le résolvait, j'adorerais le savoir.

Vérifiez les journaux sur le serveur. Il se trouve généralement dans /var/log/auth.log(Debian / Ubuntu) ou /var/log/secure(RedHat / CentOS). Tous les problèmes de connexion y sont généralement enregistrés.

Assurez-vous que / etc / hostname se termine par une nouvelle ligne.