Clé Ssh acceptée par l'hôte mais déconnexion du client

Tout d'abord, il existe de nombreuses documentations détaillées, très bien écrites, sur les thèmes suivants comment mettre en place ou configurer l'authentification basée sur une clé publique sont disponibles en ligne. Jetez un coup d'œil à l'un d'entre eux et vérifiez si vous avez bien suivi les instructions. Ici est un. Je ne vais donc pas le répéter.

Le concept de base est le suivant (copié de aquí ) :

L'authentification par clé utilise deux clés, une clé "publique" que tout le monde est autorisé à voir, et une clé "publique" que tout le monde est autorisé à voir. n'importe qui est autorisé à voir, et une autre clé "privée" que seul le propriétaire. Pour communiquer en toute sécurité à l'aide de l'authentification clé, il faut créer une paire de clés, stocker en toute sécurité la clé privée sur l'ordinateur. la clé privée sur l'ordinateur à partir duquel on souhaite se connecter, et stocker la clé publique sur l'ordinateur à partir duquel on souhaite se connecter. la clé publique sur l'ordinateur auquel on veut se connecter.

Maintenant, d'après le journal de débogage que vous avez posté :

• Il semble que deux utilisateurs différents soient impliqués. /home/theo/.ssh/authorized_keys y /home/tbouge/.ssh/id_rsa . Essayez-vous de vous connecter en tant qu'utilisateur au répertoire personnel d'un autre utilisateur ?
• L'erreur Postponed publickey for theo.. moyens d'authentification non souhaités ont été essayées avant la méthode de la clé publique. SSH essaiera toutes les méthodes d'authentification activées dans la configuration, l'une après l'autre. Dans votre cas, vous avez GSSAPIAuthentication yes activer ce que vous n'utilisez pas. Vous pouvez le désactiver en toute sécurité en faisant GSSAPIAuthentication no .
• debug2: we did not send a packet, disable method est très probablement qu'il ne peut pas traiter le fichier de clé privée (soit un problème de permission de fichier, soit un problème de nom). SSH est très sensible aux autorisations de répertoires et de fichiers sur les ordinateurs locaux et distants. ( chown user_name:user_group -R /home/user , chmod 700 /home/.ssh , chmod 600 /home/.ssh/authorized_keys ). Veillez donc à ce que les vôtres soient correctement réglés. Voir ceci : https://unix.stackexchange.com/questions/131886/ssh-public-key-wont-send-to-server

• Quant à la troisième erreur : Permission denied (public key). Il y a quelques points à vérifier.

  • Mauvais nom d'utilisateur
  • Mauvaise paire de clés

  • Mauvais hôte cible

    • Voici plus de détails : https://stackoverflow.com/questions/18551556/permission-denied-publickey-when-ssh-access-to-amazon-ec2-instance .

La partie suivante est un peu confuse :

debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method

Pour mieux comprendre, examinons étape par étape le processus d'authentification tel qu'il est décrit à l'adresse suivante digitalocean :

1. Le client commence par envoyer l'identifiant de la paire de clés qu'il souhaite utiliser. s'authentifier auprès du serveur.
2. Le serveur vérifie l'ID de la clé dans le fichier authorized_keys du compte auquel le client tente de se connecter.
3. Si une clé publique avec l'ID correspondant est trouvée dans le fichier, le serveur génère un nombre aléatoire et utilise la clé publique pour crypter le nombre.
4. Le serveur envoie au client ce message crypté.
5. Si le client possède effectivement la clé privée associée, il pourra décrypter le message à l'aide de cette clé, révélant ainsi le numéro original.
6. Le client combine le nombre décrypté avec la clé de session partagée qui est utilisée pour crypter la communication et calcule le hachage MD5 de cette valeur.
7. Le client renvoie ensuite ce hachage MD5 au serveur en guise de réponse au message chiffré.
8. Le serveur utilise la même clé de session partagée et le numéro original qu'il a envoyé au client pour calculer lui-même la valeur MD5. Il compare son propre calcul à celui que le client a renvoyé. Si ces deux valeurs correspondent, cela prouve que le client était en possession de la clé privée et le client est authentifié.

Dans votre cas, comme vous pouvez le constater, l'ordinateur distant n'a accepté que votre public key Il crypte le paquet à l'aide de cette clé et le renvoie à l'ordinateur client. L'ordinateur client doit maintenant prouver qu'il possède la bonne clé. private key . Avec la bonne clé privée, il peut décrypter le message reçu et renvoyer une réponse. Dans le cas présent, le client ne parvient pas à le faire et le processus d'authentification se termine sans succès.

J'espère que cela vous aidera à comprendre les problèmes et à les résoudre.

Les privilèges de vos fichiers ssh sont-ils corrects ?

Dossier .ssh --> 700

clé publique --> 644

clé privée --> 600

Vérifier également l'utilisateur et le groupe

Vous dites que vous avez la même clé sur une machine Windows ; êtes-vous sûr que le fichier de clé privée que vous avez sur votre machine Linux est correct ? Peut-être que la clé privée est dans un format putty que ssh ne comprend pas facilement. En tout cas, si je mets un fichier de clé privée incorrect ou invalide, j'obtiens exactement la même erreur que vous.

Pour corriger le problème, il serait plus approprié de générer une nouvelle clé sur la machine Linux plutôt que de réutiliser une clé provenant d'une autre machine. Il suffit d'ajouter la nouvelle clé publique au fichier authorized_keys de l'hôte, puis d'utiliser à la fois la clé Windows de Windows et la nouvelle clé Linux de Fedora.

Votre problème semble être assez courant et aussi clair je dois dire.

 Permission denied (publickey).

Est-ce que cela signifie quelque chose pour vous ? Pour moi, c'est très important.

Pouvez-vous vérifier sur le serveur si Selinux fonctionne en mode forcé ? Si ce n'est pas le cas, dites-moi quel est le mode de fonctionnement de Selinux.

De plus, si vous pouvez faire une autre tentative et capturer les journaux d'audit de cette tentative et les poster ici, nous saurons certainement pourquoi :

  tail -f /var/log/audit/audit.log  (and try to attempt)

C'est un problème de permission qui est clair, mais pas de permission de fichier :-)

Il semble que le problème (dans mon cas...) ait été causé par le type de clé.

Je viens de résoudre le problème en ajoutant ce qui suit au fichier local ~/.ssh/config (la machine cliente de Fedora 23) :

PubkeyAcceptedKeyTypes=+ssh-dss

Bien que j'aie ajouté cette ligne au fichier de configuration du serveur et du client, seul le côté client a fait la différence. Notez que les permissions doivent être 600 pour que le fichier de configuration soit lu.