l'hôte ssh clé de vérification a échoué sur l'un des clients seulement
Je ne peux pas ssh à partir d'un client "Un" serveur "B" (mais j'ai peut de beaucoup d'autres clients ssh sur le même sous-réseau que les "A" sont tous des *nux machines)
serverA>ssh -v -p PORT utilisateur@serveur b
OpenSSH_5.3p1 Debian-3ubuntu5, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to serverB [serverB] port PORT.
debug1: Connection established.
debug1: identity file /home/user_A/.ssh/id_rsa type -1
debug1: identity file /home/user_A/.ssh/id_dsa type 2
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu5
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: checking without port identifier
Host key verification failed.
J'ai déjà vérifié ces pts sur le client comme le serveur A l'air d'être au point :
- user_A/.ssh autorisations de répertoire : 700 (voir man ssh)
- user_A/.ssh/known_hosts autorisations: 644 (voir man ssh)
- user_A/.ssh/known_hosts: n'a PAS de contenu serverB hôte de la clé publique
- otherusers/.ssh/known_hosts: n'a PAS de contenu serverB hôte de la clé publique
J'ai essayé :
- la suppression de known_hosts sur Un serveur: même erreur reste
- à vide known_hosts sur Un serveur: même erreur
- de vérifier si la clé d'hôte noms qui correspondent le serveur ssh config: ok (Clef /etc/ssh/ssh_host_rsa_key)
- régénérer le serveur B les clés d'hôte (ssh-keygen -t rsa/dsa -f /etc/ssh/ssh_host_dsa/rsa_key) : même erreur
- ssh -p PORT-moi@localhost sur le serveur b: il fonctionne aussi comme d'autres clients ssh
Donc, je suis vraiment empilés maintenant ! ssh spécialistes bienvenue à la maison.
Merci à l'avance
Vous devez vous connecter pour publier un commentaire.
Ne pas comprendre exactement ce que j'ai fait de mal pour ce serveur..
Ce qui reste "étrange" est que la destruction des "known_hosts" sur le côté client n'a pas de disque à l'effet positif attendu.
De toute façon pls trouver ci-après ce que j'ai fait manuellement, assez laid, mais fonctionne:
Note: Cela suppose un accès complet à la fois des machines (client et serveur)
côté serveur : régénérer les 2 paires de clés rsa et dsa)
côté client:
générer une paire de clés dsa (privé et public) pour l'utilisateur "toto"
ajouter cette nouvelle clé ssh-agent si l'exécution de
ajouter le contenu du serveur ssh_host_rsa_key.pub pour le client /home/toto/.ssh/known_hosts, après l'adresse IP/port:
maintenant de retour pour le côté serveur :
copier/coller le client de clé publique /home/toto/.ssh/my_client_key.pub dans /home/bar/.ssh/.authorized_keys afin de permettre la connexion de l'utilisateur "toto" pour se connecter à la "barre" du compte:
assurez-vous que le chemin d'accès à la cohérence avec /etc/ssh/sshd_config pour pouvoir l'utiliser le fichier .authorized_keys :
redémarrer le serveur ssh
client: maintenant, le client "foo" peut ssh pour l'utilisateur "bar" sur le serveur :
Remarque: dans mon cas, le client et le serveur s'exécutent localement à l'intérieur de l'ordinateur virtuel. Ne pas utiliser ces paramètres pour la production de toute évidence.
MODIFIER: Lire un peu plus attentivement l'homme ssh pages, il devrait être possible de contourner ce problème dans un bien de manière appropriée, ref de l'homme: "La StrictHostKeyChecking option peut être utilisée pour contrôler les connexions pour les machines dont la clé de l'hôte n'est pas connu ou qu'il a changé."
J'ai eu le même problème, sur un système embarqué que je n'ai aucun contrôle dessus. Je pense que la façon dont je l'ai corrigé, c'était d'installer toutes les clés publiques des deux côtés, manuellement.
Le problème a commencé avec ssh se plaindre que "ssh-askpass' n'a pas été trouvé. Le travail autour de ce qui était pour désactiver l' $variable d'environnement DISPLAY (oui, tout à fait évident). J'ai lu quelque part que OpenSSH essayez d'utiliser ssh-askpass si l'AFFICHAGE est réglé. J'ai donc fait cela
Alors en gros, j'ai eu le message d'erreur dans l'OP. Donc, pour continuer, j'ai tout fait sur cette page pour créer et copier la clé publique de A à B.
J'ai créé une clé RSA et DSA key. Je suppose que RSA est plus âgé et le DSA est plus récente. (On dirait qu'il a été à l'aide de la clé RSA.) De toute façon, cela n'a pas résolu le problème tout seul.
Ensuite, j'ai essayé de copier le serveur "B" de la clé publique retour au client "A"'s known_hosts. Et ça a fonctionné!
Le serveur B, prenez
Ensuite, ajoutez le contenu de ce que
sur le client "A", avec l'adresse IP du serveur "B" ajouté au début (et l'espace)
Utile de débogage astuce est d'utiliser l'-vvv option ssh pour se super sortie détaillée.
De référence pour l'avenir j'ai corrigé ce que je pense est le même problème en faisant (par le client)
J'ai ensuite retiré tout en
~/.ssh/known_hostset de copier coller les deux touches exactement la façon dont ils apparaissent dans~/.ssh/known_hosts.J'ai fait copier collé le ssh-rsa on ne, d'abord, parce que je pensais que c'est ce que j'utilisais. Pour une raison que ça ne marche pas, quand je copie collé de la seconde clés en, il a travaillé comme un charme. À noter que bien que j'ai activé PasswordAuthentication dans mon sshd config sur le serveur afin de ne pas s'inquiéter au sujet de clés.