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

Helo,

J'ai un problème avec SSH après l'installation de fedora 23.

Lorsque je ne veux pas me connecter à mon hôte distant avec une clé privée, mon hôte trouve la clé:

debug1: matching key found: file /home/theo/.ssh/authorized_keys, line 1 RSA {REDACTED}
debug1: restore_uid: 0/0
Postponed publickey for theo from {REDACTED} port 60351 ssh2 [preauth]
Connection closed by {REDACTED} [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed

Mais comme vous voyez mon client se déconnecter par lui-même

debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tbouge/.ssh/id_rsa
debug3: send_pubkey_test
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
debug1: No more authentication methods to try.
Permission denied (publickey).

Je peux me connecter à mon hôte avec du mastic sur Windows en utilisant la même clé privée et je peux me connecter avec mon téléphone en utilisant une clé privée différente.

Avez-vous une idée ?

/ etc / ssh / ssh_conf

Host *
        GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
        ForwardX11Trusted yes
# Send locale-related environment variables
        SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
        SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
        SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
        SendEnv XMODIFIERS

Je vous remercie

Modifier: je peux me connecter avec un mot de passe

Tout d'abord, il existe de nombreux documents très bien écrits et détaillés sur la façon d'installer ou de configurer l'authentification basée sur une clé publique sont disponibles en ligne. Jetez un œil à l'un d'eux et voyez si vous avez tout suivi correctement. En voici un. Je ne vais donc pas répéter cela.

Le concept très basique est (copié d' ici ):

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

Maintenant, à partir du journal de débogage que vous avez publié:

• Il semble que deux utilisateurs différents soient impliqués. /home/theo/.ssh/authorized_keyset /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..signifie que la méthode d'authentification indésirable a été essayée avant la méthode de clé publick. SSH essaiera toutes les méthodes d'authentification qui sont activées dans la configuration, l'une après l'autre. Dans votre cas, vous avez GSSAPIAuthentication yesactivé 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 methodest très probablement qu'il ne peut pas traiter le fichier de clé privée (problème de permission de fichier ou de nom). SSH est très sensible aux autorisations de répertoire et de fichier sur les ordinateurs locaux et distants. ( chown user_name:user_group -R /home/user, chmod 700 /home/.ssh, chmod 600 /home/.ssh/authorized_keys). Assurez-vous donc que le vôtre est correctement configuré. Voir ceci: /unix/131886/ssh-public-key-wont-send-to-server

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

  • Nom d'utilisateur incorrect
  • Mauvaise paire de clés

  • Hôte cible incorrect

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

La partie suivante est un peu déroutante:

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 le comprendre, passons par le processus d'authentification étape par étape comme décrit ici chez digitalocean :

1. Le client commence par envoyer un ID pour la paire de clés avec laquelle il souhaite s'authentifier auprès du serveur.
2. Le serveur vérifie le fichier authorized_keys du compte auquel le client tente de se connecter pour l'ID de clé.
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 numéro.
4. Le serveur envoie au client ce message crypté.
5. Si le client possède réellement la clé privée associée, il pourra décrypter le message à l'aide de cette clé, révélant le numéro d'origine.
6. Le client combine le numéro déchiffré avec la clé de session partagée utilisée pour chiffrer la communication et calcule le hachage MD5 de cette valeur.
7. Le client renvoie ensuite ce hachage MD5 au serveur comme réponse au message de numéro chiffré.
8. Le serveur utilise la même clé de session partagée et le numéro d'origine 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 que le client est authentifié.

Dans votre cas, comme vous pouvez le voir, l'ordinateur distant n'a accepté que votre public key, a chiffré le paquet avec cette clé et l'a renvoyé à l'ordinateur client. Maintenant, l'ordinateur client doit prouver qu'il a le droit private key. Avec seulement la bonne clé privée, il peut déchiffrer le message reçu et renvoyer une réponse. Dans ce cas, le client ne parvient pas à le faire et le processus d'authentification se termine sans succès.

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

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

Dossier .ssh -> 700

clé publique -> 644

clé privée -> 600

Vérifiez é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 de mastic que ssh ne comprend pas facilement. Dans tous les 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 au lieu de réutiliser une clé d'une autre machine. Vous pouvez simplement ajouter la nouvelle clé publique au fichier authorized_keys sur l'hôte, puis vous pouvez utiliser à la fois la clé Windows de Windows et la nouvelle clé Linux de Fedora.

votre problème semble être assez commun et aussi clair, je l'ai dit.

 Permission denied (publickey).

cela signifie-t-il quelque chose pour vous? pour moi, cela signifie beaucoup pour moi.

pouvez-vous vérifier côté serveur si vous avez selinux runnin en mode forcé pls? sinon, dites-moi dans quel mode selinux fonctionne.

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

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

C'est un problème d'autorisation qui est clair mais pas l'autorisation de fichier :-)

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

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

PubkeyAcceptedKeyTypes=+ssh-dss

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

Je ne sais pas si quelqu'un d'autre a toujours ce problème, mais je l'ai finalement résolu pour ma seule machine (un ordinateur portable) qui rencontrait le problème. Je crois que je sais ce qui a finalement été réglé, et je laisserai les informations ici dans l'espoir que cela aidera toute autre personne qui pourrait encore rencontrer cela - et aussi pour que quelqu'un puisse, espérons-le, vérifier ma solution et confirmer que c'est réellement ce que résolu le problème.

Il s'avère que le problème n'était pas (pour moi) avec SSH, mais avec la façon dont PAM configurait mes clés. La configuration dans /etc/pam.détait obsolète (même si elle fonctionnait correctement via Fedora 22), et par conséquent, les choses correctes n'étaient plus faites lors de la connexion [pour] récupérer mes clés $HOME/.ssh/. Exécuter cette commande:

# sudo authconfig --updateall

reconstruit correctement la configuration /etc/pam.d. Au redémarrage suivant, après ma connexion, la première fois que j'essayais de me déconnecter de mon serveur, une boîte de dialogue m'a demandé de saisir ma phrase secrète pour ma clé ssh ( $HOME/.ssh/id_rsa). Je l'ai fait, j'ai coché la case "Déverrouiller automatiquement à la connexion", et le tour est joué! Ma capacité à sortir de l'ordinateur portable a été restaurée.

Contexte

L'indice qui m'a amené à résoudre ce problème est venu lorsque j'ai importé une clé RSA à partir d'une source externe. (Une clé USB que je transporte, avec ma touche « accès à distance » pour mon réseau domestique. Je mis hors tension PasswordAuth à mes il y a quelques années de serveur orientées vers l' extérieur après une intrusion.) Après ssh-add-ment QUE clé RSA, contrairement à celui qui était assis dans $HOME/.ssh/id_rsa, il a été accepté par le serveur distant sans problème.

Ensuite, j'ai fini par faire ce qui aurait dû être redondant ssh-add, pour reprendre $HOME/.ssh/id_rsa. J'ai remarqué qu'après avoir fait cela, ssh-add -lcontenait deux entrées pour la même clé:

% ssh-add -l
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX id_rsa (RSA)
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX me@host (RSA)
2048 SHA256:YYYYYYYYYYYYYYYYYYYYYY imported@usbkey (RSA)

Notez que l'une des deux entrées n'affiche pas l'identifiant de clé, juste le nom de fichier de la clé privée correspondant à sa signature publique. Comme si la clé privée n'était pas vraiment déverrouillée par le gestionnaire de porte-clés.

Je crois que c'est exactement ce qui se passait, et PAM transmettait des "mauvaises clés" à l'agent SSH qui n'avait pas été déverrouillé avec la phrase secrète. Ainsi, lorsque ssh a tenté de s'authentifier avec la clé, il n'a pas réellement eu la moitié privée (déverrouillée) de la paire de clés, et l'authentification a donc échoué.

Ce dernier bit est une conjecture, mais peu importe si quelqu'un a des problèmes avec les clés ssh qui ne sont pas acceptées par les hôtes distants (où elles étaient) après la mise à niveau vers F23, la reconstruction du /etc/pam.d/répertoire à l'aide authconfigvaut la peine d'être essayée comme solution.

Vérifiez les autorisations du répertoire de base des utilisateurs. C'est important. Doit être 755. 700 ou 770 ne fonctionnera pas.

Dans votre ssh_config, essayez décommentant et / ou l' ajout / suppression / annexant soit à la Cipher, Ciphersou la MACsligne (s).

Il me semble que vous sshdrecherchez un chiffrement particulier d'une sorte qui n'est pas inclus dans la demande, qui peut être ajouté en le configurant dans votre ssh_config.

... et je suppose que vous ne par hasard ont PubkeyAuthenticationmis à nosur le serveur distant, car ce serait certainement provoquer ce à l' échec.