Putty: obtenir le serveur a refusé notre erreur de clé

Ajouter quelques pensées comme d'autres réponses ont aidé, mais n'étaient pas en forme exacte.

Tout d'abord, comme mentionné dans la réponse acceptée, éditez

/etc/ssh/sshd_config

Et définir le niveau du journal:

LogLevel DEBUG3

Ensuite, essayez de vous authentifier, et quand il échoue, recherchez le fichier journal:

/var/log/secure

Il aura des erreurs que vous recherchez.

Dans mon cas, j'ai également dû modifier les autorisations de /home/user de 0755 à 0700.

J'ajoute cette réponse pour aider quiconque, comme moi, a passé des heures à parcourir internet sans succès.

VOTRE DOSSIER PERSONNEL PEUT ÊTRE CHIFFRÉ.

Ou d'ailleurs tout dossier dans lequel votre fichier "authorized_keys" est imbriqué. L'homme, qui m'aurait sauvé beaucoup de temps. Pour vérifier, allez effectuer

ls -A

Dans le répertoire dont vous souhaitez déterminer l'état de chiffrement. Si le dossier contient un dossier nommé ".encryptfs " la réponse est, oui, ce dossier est crypté. Cela entravera votre capacité à accéder au fichier "authorized_keys" contenant la clé publique SSH nécessaire à la vérification.

Pour résoudre ce problème, placez le fichier" authorized_key " dans une arborescence de répertoires qui ne contient aucun chiffrement.

La solution simple que j'ai trouvée était de déplacer le fichier authorized_keys loin du caché .répertoire SSH et placez-le dans le répertoire SSH du système:

/etc/ssh/keys/authorized_keys

Dès que je l'ai fait, cela a fonctionné sans problème.

Ayant le même problème dans windows server 2008 r2 et exploré beaucoup à résoudre, a finalement fait cela en suivant:

Ouvrir C:\Program Files (x86)\OpenSSH\etc \ sshd_config avec textpad ou tout autre éditeur de texte

Supprimer le commentaire des lignes suivantes, après la suppression, ils devraient ressembler à ce qui suit:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

Enregistrez-le et essayez de vous connecter avec une clé privée maintenant. amuser.

Dans mon cas, est un problème d'autorisation.

J'ai changé le niveau du journal en DEBUG3, et dans /var/log/secure je vois cette ligne:

Authentication refused: bad ownership or modes for directory

Googlé et j'ai trouvé ce post:

Https://www.daveperrett.com/articles/2010/09/14/ssh-authentication-refused/

chmod g-w /home/your_user
chmod 700 /home/your_user/.ssh
chmod 600 /home/your_user/.ssh/authorized_keys

Fondamentalement, il me dit de:

• débarrassez-vous du groupe w autorisation de votre utilisateur home dir
• modifier l'autorisation en 700 du répertoire .ssh
• modifier l'autorisation à 600 du fichier authorized_keys.

Et ça marche.

Une autre chose est que même si j'ai activé la connexion root, Je ne peux pas faire fonctionner root. Mieux utiliser un autre utilisateur.

Merci à nrathaus et /var/log/auth.log enquête sur le niveau de débogage vient ce qui suit.

Une autre raison est que votre répertoire personnel peut avoir des autorisations différentes de 755.

Merci!

Merci pour LogLevel DEBUG3 (dans mon cas, CentOS 7 le journal est dans /var/log/secure)

Il S'avère que mon mode .ssh/authorized_keys était 644 et non 600, et sshd a estimé que seul était un non-go, que j'ai finalement découvert en lisant ce fichier journal!

Dans mon cas, j'ai dû désactiver SELinux sur Centos6. 6 pour le faire fonctionner :)

Modifiez /etc / selinux / config et définissez ce qui suit, puis redémarrez l'hôte.

selinux=disabled

BTW...j'ai oublié de mentionner que j'ai dû définir le LogLevel = DEBUG3 pour identifier le problème.

J'ai eu la même erreur sur solaris mais trouvée dans / var / adm / splunk-auth.enregistrez ce qui suit:

sshd: [auth.debug] debug1: PAM conv function returns PAM_SUCCESS
sshd: [auth.notice] Excessive (3) login failures for weblogic: locking account.
sshd: [auth.debug] ldap pam_sm_authenticate(sshd-kbdint weblogic), flags = 1
sshd: [auth.info] Keyboard-interactive (PAM) userauth failed[9] while authenticating: Authentication failed

Dans /etc / shadow, le compte était verrouillé:

weblogic:*LK*UP:16447::::::3

Supprimé la partie " * LK*":

weblogic:UP:16447::::::3

Et je pourrais utiliser ssh avec authorized_keys comme d'habitude.

Dans mon cas, il a été causé par (/etc/ssh/sshd_config):

PermitRootLogin no

Changé en yes, redémarré le service et est entré normalement.

J'ai rencontré ce problème aujourd'hui et mon problème était que lors de la copie de la clé publique à partir du fichier, de nouveaux caractères de ligne sont également inclus. Vous pouvez utiliser ":set list" dans vim pour voir tous les cachés de nouvelles lignes et assurez-vous de supprimer toutes les lignes sauf la dernière. En outre, ma clé manquait "ssh-rsa" au début. Assurez-vous que vous avez cela.

Pour ceux qui reçoivent cette erreur de Windows Server, j'ai reçu cette même erreur et c'était un problème de Compte d'utilisateur. Avec de nombreuses organisations, la stratégie de groupe pour les administrateurs peut ne pas autoriser la configuration du serveur SSH et des connexions. Avec ce type de configuration, cela doit être fait à partir du compte administrateur Local. Cela pourrait être intéressant si vous avez confirmé qu'il n'y a pas de fautes de frappe dans la clé publique.

J'utilise un fichier PUTTYgen avec psftp, et j'ai rencontré ce problème sur mon serveur Windows lorsque nous devions créer de nouvelles clés pour un client. Le private_key_name.fichier ppk et open_ssh.le fichier txt doit être dans le même répertoire pour que la connexion fonctionne.

Dans mon cas, la maison sur NFS était 777, devait être 750. Qui a résolu le problème.

J'ai résolu ce problème, puttygen est un logiciel tiers, la clé ssh qui générée par elle n'a pas été utilisée directement, donc vous devez apporter quelques modifications. Par exemple, cela ressemble à ceci

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7
*******C4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ==
---- END SSH2 PUBLIC KEY ---- 

J'Omets certains des alphabets au milieu, remplacés par*, sinon, StackOverflow m'a dit que le format de code est mauvais, ne me laissez pas poster。

C'est ma clé SSH générée par puttygen, vous devez changer pour cela

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7wfvKGWWR7wxA8GEXJsM01FQw5hYWbNF0CDI7nCMXDUEDOzO1xKtNoaidlLA0qGl67bHaF5t+0mE+dZBGqK7jG9L8/KU/b66/tuZnqFqBjLkT+lS8MDo1okJOScuLSilk9oT5ZiqxsD24sdEcUE62S8Qwu7roVEAWU3hHNpnMK+1szlPBCVpbjcQTdiv1MjsOHJXY2PWx6DAIBii+/N+IdGzoFdhq+Yo/RGWdr1Zw/LSwqKDq1SmrpToW9uWVdAxeC4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ== yourname@hostname

Dans mon cas, j'ai supprimé certains commentaires, tels que comme

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
---- END SSH2 PUBLIC KEY ----

Et ajouter ssh-rsa Au début, ajouter yourname@hostname à la dernière. note: ne pas supprimer== dans le dernier et vous devez changer "votrenom" et "nom d'hôte" pour vous, Dans mon cas, est - uaskh@mycomputer,votrenom, c'est que vous souhaitez vous connecter dans votre vps .lorsque toutes ces choses ont fait,vous pouvez télécharger de la clé publique à uaskh de la maison~/.ssh/authorized_keys par cat public-key >> ~/.ssh/authorized_keys, puis sudo chmod 700 ~/.ssh sudo chmod 600 ~/.ssh/authorized_keys ensuite, vous devez modifier /etc/ssh/sshd_config, RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys mon système d'exploitation CentOS 7,C'est ma première fois pour répondre question, je vais essayer mes efforts à faire, merci!

J'ai ce problème où sshd ne lit que de authorized_keys2.

Copier ou renommer le fichier a résolu le problème pour moi.

cd  ~/.ssh
sudo cat authorized_keys >> authorized_keys2

P.S. j'utilise Putty de Windows et utilisé PuTTyKeygen pour la génération de paires de clés.

J'étais confronté à un problème similaire en essayant de me connecter via Mobaxterm. La clé privée a été générée via puttygen. Régénérer la clé a aidé dans mon cas.

Lorsque vous utilisez Cpanel, vous pouvez vérifier si la clé est autorisée dans

Accès SSH > > clés publiques > > Gérer > > autoriser ou annuler l'autorisation.

Si vous obtenez cette erreur dans /var/log/secure

Erreur: key_read: key_from_blob AA
AAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwx04nfg + rKz93l7em1BsUBzjHPMsswD

Cela signifie que votre clé a de l'espace, si vous avez généré la clé via puttgen lorsque vous affichez le fichier .ppk, Cela ressemblera à ceci:

AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswD
al74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5
GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBC
gLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqz
xjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5L
VwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ==

Et lorsque vous essayez de coller, vous obtiendrez une erreur dans la lecture de la clé, alors essayez de modifier la clé et d'en faire une ligne et essayez -

Cela devrait ressembler à quelque chose

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswDal74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBCgLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqzxjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5LVwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ== username@domainname

Ce qui fonctionne pour moi est que:

• a arrêté l'instance ec2
• détacher le volume
• attachez le volume avec l'ancienne instance en utilisant la même clé et a pu SSH
• monter le volume dans un dossier temporaire
• vérifié le fichier dans le répertoire mount_point/home/ec2/utilisateur.SSH / authorized_keys
  • Idéalement, ce fichier doit avoir nos Informations clés mais pour moi ce fichier était vide
• copié l'ancien fichier authorized_keys de l'instance le volume nouvellement monté
• démonter l'appareil
• rattacher à l'instance ec2 d'origine
• démarrer et laisser passer les contrôles de santé,

Cette fois, ça marche pour moi. Mais je ne sais pas pourquoi il n'a pas mes informations de fichier clé au début lorsque l'instance a été lancée. Vérifiez ce lien aussi https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html#TroubleshootingInstancesConnectingMindTerm

Une autre raison pourrait être UTF-8 BOM dans le fichier authorized_keys.