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

Je ne sais pas si quelqu'un d'autre a encore ce problème, mais je l'ai finalement résolu pour ma seule machine (un ordinateur portable) qui rencontrait ce problème. I croire Je sais ce qui a permis de résoudre le problème, et je vais laisser l'information ici dans l'espoir qu'elle aidera quelqu'un d'autre qui pourrait encore rencontrer ce problème - et aussi pour que quelqu'un puisse vérifier ma solution et confirmer que c'est bien ce qui a résolu le problème.

Il s'est avéré que le problème n'était pas du tout (pour moi) lié à SSH, mais à la façon dont PAM configurait mes clés. La configuration dans /etc/pam.d n'était plus à jour (bien qu'il fonctionnait correctement avec Fedora 22), et par conséquent les choses correctes n'étaient pas faites lors de l'ouverture de session [plus] pour récupérer mes clés à partir de $HOME/.ssh/ . L'exécution de cette commande :

# sudo authconfig --updateall

reconstruit la configuration /etc/pam.d correctement. Au redémarrage suivant, après m'être connecté, la première fois que j'ai essayé de sortir en ssh de mon serveur, une boîte de dialogue m'a demandé d'entrer ma phrase de passe pour ma clé ssh ( $HOME/.ssh/id_rsa ). Je l'ai fait, j'ai coché la case "Déverrouiller automatiquement lors de la connexion" et voilà ! J'ai retrouvé la possibilité de me déconnecter en ssh de l'ordinateur portable.

Contexte

L'indice qui m'a permis de résoudre ce problème est apparu lorsque j'ai importé une clé RSA à partir d'une source externe. (Une clé USB que je transporte avec moi, avec ma clé d'"accès à distance" pour mon réseau domestique. J'ai désactivé PasswordAuth sur mon serveur externe il y a des années après une intrusion). Après ssh-add -ing CELA RSA, contrairement à celle qui se trouve dans $HOME/.ssh/id_rsa il a été accepté sans problème par le serveur distant.

Puis j'ai fini par faire ce qui aurait dû être une redondance ssh-add , à ramasser $HOME/.ssh/id_rsa . Je l'ai remarqué après l'avoir fait, ssh-add -l contenu zwei 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)

Remarquez que l'une des deux entrées n'indique pas l'identifiant de la clé, mais seulement le nom du fichier de la clé privée correspondant à sa signature publique. Comme si la clé privée n'était pas vraiment déverrouillé par le gestionnaire du trousseau.

Je pense que c'est exactement ce qui se passait, et que PAM transmettait à l'agent SSH des "mauvaises clés" qui n'avaient pas été déverrouillées avec la phrase de passe. Ainsi, lorsque ssh tentait de s'authentifier avec la clé, il ne disposait pas de la moitié privée (déverrouillée) de la paire de clés, et l'authentification échouait.

Ce dernier point est une conjecture, mais si quelqu'un a des problèmes avec les clés ssh qui ne sont pas acceptées par les hôtes distants (alors qu'elles l'étaient auparavant) après la mise à jour vers F23, il faut reconstruire le fichier /etc/pam.d/ à l'aide de authconfig est une solution qui vaut la peine d'être essayée.

Vérifier les autorisations du répertoire personnel de l'utilisateur. C'est important. Elles doivent être de 755. 700 ou 770 ne fonctionneront pas.

Dans votre ssh_config essayez de décommenter et/ou d'ajouter/supprimer/appliquer à l'un ou l'autre des éléments suivants Cipher , Ciphers o MACs ligne(s).

Il me semble que sshd recherche un chiffrement particulier qui n'est pas inclus dans la requête, qui peut être ajouté en le configurant dans le fichier ssh_config .

...et je suppose que vous n'avez pas par hasard PubkeyAuthentication fixé à no sur le serveur distant, car cela entraînerait certainement l'échec de l'opération.