web-dev-qa-db-fra.com

Putty: Obtenir le serveur a refusé notre clé Erreur

J'ai créé une paire de clés à l'aide de puttygen.exe (le client est Windows 8). Sur le serveur (Ubuntu 12.04.3 LTS), j'ai mis ma clé publique dans ~/.ssh/authorized_keys. La clé publique est la suivante:

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAopfM6RHOgnuc4Aftn3t4k5UIAT3StCAbn/vg/IMbphbXadshC+79sIlRq3P4zGzMjFTP4hKnzu6ehLV5lmj/qorq3SKT+bPO5Qrac3VbIlrGvuBFDDjP82I2Hwg3HzlsFTstqk++KToapaTYZ7jENEYyPl2wnzITJnt//+4U1o6juoXTKgdNE02hHnRZyHOV/bnkZyJJCEwJv5U0eXSThQnhmXtUxGT8U0HQNFiXfqIIVllhWiCnyrhhIaKz/CIJNAd2VmzyJzQtJtTQX8aWSNVrZju6Sv2/RncTNvsACdNgjjh/FH8PQXaep00jlJ3MOdsC8vz6VSPFbh6iKy1oLQ== rsa-key-20131231

Donc c'est correct (une ligne, pas de commentaires, commence par ssh-rsa, etc.)

.ssh niveau d’autorisation dir est 700, l’autorisation de fichier allowed_keys est 600. Le répertoire et le fichier appartenant à l’utilisateur réel que j’essaie de connecter. 

Lorsque j'essaie de me connecter, je reçois 'server refused our key' et le serveur me demande un mot de passe. C'est tout. Rien n'est connecté à /var/log/auth.log lors d'une tentative de connexion avec la clé. 

J'ai regardé partout et tous les articles et conseils mentionnent le réglage correct des fichiers chmod 600 et 700 et le formatage de la clé. J'ai fait tout cela en obtenant toujours l'erreur de «refuser notre clé» et je suis à court d'idées.

sshputty
65
PawelRoman

OK, il y avait une petite faute de frappe dans ma clé. Apparemment, lors du collage pour classer, la première lettre a été coupée et elle a commencé par sh-rsa au lieu de ssh-rsa.

nrathathaus - votre réponse a été très utile, merci beaucoup, cette réponse vous est créditée :) Je vous ai bien dit, comme dans sshd_conf:

LogLevel DEBUG3

En regardant les journaux, j'ai réalisé que sshd lisait la clé correctement mais la rejetait à cause d'un identificateur incorrect.

47
PawelRoman

Ajouter quelques réflexions, car d’autres réponses ont aidé, mais ne correspondaient pas parfaitement.

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

/etc/ssh/sshd_config

et définir le niveau de journalisation:

LogLevel DEBUG3

Ensuite, essayez de vous authentifier et, en cas d'échec, recherchez le fichier journal:

/var/log/secure

Il y aura des erreurs que vous recherchez.

20
Ranty

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

13
Atif

Dans mon cas, c'est un problème de permission.

J'ai changé le niveau de journalisation 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

En gros, cela me dit de:

  • se débarrasser de la permission de groupe w de votre répertoire personnel
  • changer l'autorisation en 700 du .ssh dir
  • changez l'autorisation en 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 vaut utiliser un autre utilisateur.

5
WesternGun

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

/etc/ssh/keys/authorized_keys

Dès que j'ai fait cela, cela a fonctionné sans problèmes.

3
mrbronz

J'ajoute cette réponse pour aider ceux qui, comme moi, ont passé des heures à récurer Internet sans succès.

VOTRE DOSSIER DOMESTIQUE PEUT ÊTRE CRYPTÉ. 

Ou d'ailleurs n'importe quel dossier dans lequel votre fichier "allowed_keys" est imbriqué. Mec, ça m'aurait épargné beaucoup de temps. Pour vérifier, allez effectuer

ls -A

sur le répertoire dont vous souhaitez déterminer le statut 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 "allowed_keys" contenant la clé publique ssh nécessaire à la vérification. 

Pour résoudre ce problème, placez le fichier "registered_key" dans une arborescence de répertoires ne contenant aucun cryptage. 

3
Mackie Messer

Merci!

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

Il s’est avéré que mon mode .ssh/authorized_keys était 644 et non pas 600, et sshd pensait que cela seul était impossible, ce que j’ai finalement découvert en lisant ce fichier journal!

3
Sxilderik

ayant le même problème dans Windows Server 2008 R2 et exploré beaucoup de choses à résoudre, a finalement fait cela en suivant:

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

supprime les commentaires des lignes suivantes, après les avoir supprimées, elles devraient ressembler à ce qui suit:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

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

3
Ravi Anand

Grâce à nrathaus et à l'analyse /var/log/auth.log au niveau débogage, voici ce qui suit.

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

2
Intel83

J'ai rencontré ce problème aujourd'hui et mon problème était que lors de la copie de la clé publique à partir d'un fichier, les caractères de nouvelle ligne sont également inclus. Vous pouvez utiliser ": set list" dans vim pour voir toutes les nouvelles lignes cachées et vous assurer de supprimer toutes les nouvelles lignes à l'exception de la dernière. En outre, ma clé manquait "ssh-rsa" au début. Assurez-vous de l'avoir aussi.

2
hyeuc

Dans mon cas, je devais désactiver SELinux sur Centos6.6 pour le faire fonctionner :)

Éditez/etc/selinux/config et définissez les paramètres suivants, puis redémarrez l'hôte.

selinux=disabled

BTW ... a oublié de mentionner que je devais définir LogLevel = DEBUG3 pour identifier le problème. 

1
sagaya

J'ai eu la même erreur sur Solaris mais j'ai trouvé dans /var/adm/splunk-auth.log 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

Suppression de la partie "* LK *":

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

et je pourrais utiliser ssh avec registered_keys comme d'habitude.

1
Bruno Ruess

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

PermitRootLogin no

Remplacé par yes, redémarrez le service et entrez normalement.

1
Alex Fortuna

Pour ceux qui reçoivent cette erreur de Windows Server, j'ai reçu cette même erreur et il s'agissait d'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 vaut peut-être la peine de vérifier si vous avez confirmé qu'il n'y a pas de fautes de frappe dans la clé publique.

1
Andrew Campbell

J'ai résolu ce problème, puttygen est un logiciel tiers, la clé ssh générée par celui-ci n'étant pas utilisée directement, vous devez donc effectuer 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 alphabets au milieu, remplacés par *, sinon, StackOverflow m'a dit que le format du code est incorrect, ne me laissez pas poster

c'est ma clé ssh générée par puttygen, vous devez changer en cette

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 

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

et ajoutez ssh-rsa au début, ajoutez yourname@hostname au dernier . note : pas delete== dans le dernier et vous devez changer "yourname" et "hostname" pour vous, dans mon cas, est uaskh@mycomputer, votre nom est celui que vous souhaitez enregistrer dans votre vps Quand toutes ces choses sont faites, vous pouvez télécharger la clé publique sur le home~/.ssh/authorized_keys de uaskh _ par cat public-key >> ~/.ssh/authorized_keys puis Sudo chmod 700 ~/.sshSudo chmod 600 ~/.ssh/authorized_keys, vous devez alors modifier/etc/ssh/sshd_config. , RSAAuthentication yesPubkeyAuthentication yesAuthorizedKeysFile .ssh/authorized_keys mon système d’exploitation est CentOS 7, c’est la première fois que je réponds à une question, je vais essayer de faire mes efforts, merci!

0
toffee

J'ai ce problème où sshd lit seulement à partir 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 sous Windows et utilise PuTTyKeygen pour la génération de paires de clés.

0
Chad Liu

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

0
dghadge

J'étais confronté au même problème lorsque j'essayais de me connecter via Mobaxterm. La clé privée a été générée par puttygen. Régénérer la clé m'a aidé dans mon cas.

0
Prada

Étapes à suivre pour réparer le montage racine (que j'ai suivies lorsque j'ai changé d'autorisation avec le dossier ec2-user et le fichier de clé d'autorisation) Ce processus sera similaire à détacher et attacher une clé USB.

Voici d'autres scénarios que vous pouvez rencontrer -  

  1. Vous utilisez une clé privée SSH, mais la clé publique correspondante ne se trouve pas dans le fichier allowed_keys.
  2. Vous n'avez pas les autorisations pour votre fichier allowed_keys.
  3. Vous n'avez pas les autorisations pour le dossier .ssh.
  4. Votre fichier allowed_keys ou votre dossier .ssh n'est pas nommé correctement.
  5. Votre fichier allowed_keys ou votre dossier .ssh a été supprimé.

Étapes pour les réparer

  • Arrêtez l'instance problématique Ec2 
  • Détachez le volume racine (/ dev/sda1)
  • Créer une instance ec2 ou utiliser une instance en cours d'exécution
  • Montez le volume détaché (/ dev/sdvf) sur la nouvelle instance ec2 

Maintenant, après vous être connecté au nouvel ec2, exécutez les étapes suivantes  

  • Commande Lsblk - liste tous les montages disponibles
  • Choisissez la valeur de montage que vous démontez de l'instance problématique 
  • En tant qu'utilisateur ec2, exécutez “Sudo mount/dev/mapper/rootvg-home /mnt” Sudo mount /dev/mapper/rootvg-home /mnt
  • Puis changez de répertoire en/mnt
  • Faire tous les changements nécessaires

Maintenant, nous avons fixé notre volume avec le problème auquel nous sommes confrontés. La plupart du temps, il pourrait s'agir d'un problème d'autorisation d'utilisateur - Umount/mnt pour le démonter - Allez maintenant à la console et pointez le volume associé à la nouvelle instance et détachez-le - Après l'avoir détaché, attachez-le à votre nouveau volume en tant que/dev/sda1 

Cela dit, vous devriez pouvoir vous connecter avec succès  

0
Barath Ravichander

Sous Windows 8.1, j'ai rencontré le problème server refused our key.

En suivant le guide: https://winscp.net/fr/docs/guide_windows_openssh_server Il était facile d'établir une connexion à l'aide des identifiants Windows username et password. Cependant, en s’authentifiant avec username en combinaison avec un private key, la réponse était server refused our key.

Le faire fonctionner avec une clé publique dépendait des autorisations sur le fichier: C:\ProgramData\ssh\administrators_authorized_keys

C'est une page utile: https://github.com/PowerShell/Win32-OpenSSH/wiki/Troubleshooting-Steps

Arrêtez les deux services OpenSSH, puis ouvrez un command Prompt avec admin permissions. Puis lancez: C:\OpenSSH-Win32>c:\OpenSSH-Win32\sshd.exe -ddd

Note: spécifiez le chemin complet vers l'exe sinon sshd se plaint. Cela crée un écouteur de connexion à usage unique. Le -ddd correspond au niveau 3 détaillé.

Après avoir établi une connexion, l’analyse des journaux a révélé:

debug1: trying public key file __PROGRAMDATA__/ssh/administrators_authorized_keys
debug3: Failed to open file:C:/ProgramData/ssh/administrators_authorized_keys error:2
debug1: Could not open authorized keys '__PROGRAMDATA__/ssh/administrators_authorized_keys':
        No such file or directory

Il fallait créer le fichier: C:\ProgramData\ssh\administrators_authorized_keys et copier le texte public key dans celui-ci, par exemple: ssh-rsa AAAA................MmpfXUCj rsa-key-20190505, puis enregistrer le fichier. J'ai enregistré le fichier en tant que UTF-8 avec le BOM. N'a pas testé ANSI.

Ensuite, réexécutez la ligne de commande unique, dans les journaux suivants:

debug1: trying public key file __PROGRAMDATA__/ssh/administrators_authorized_keys
debug3: Bad permissions. Try removing permissions for user: S-1-5-11 on file C:/ProgramData/ssh/administrators_authorized_keys.
        Authentication refused.

S-1-5-11 est le nom donné à la System.

Pour corriger le Bad permissions, cliquez avec le bouton droit sur le fichier administrators_authorized_keys, passez au Security Tab, cliquez sur le bouton Advanced et supprimez les autorisations héritées. Supprimez ensuite tout Group or user names: à l'exception du nom d'utilisateur de connexion Windows, par exemple: YourMachineName\username. Les autorisations pour cette username doivent être Read Allow, Write Deny tout le reste étant décoché. Le propriétaire du fichier doit également être YourMachineName\username

Cela a résolu le problème.

Autres liens utiles:

Téléchargez OpenSSH-Win32.Zip à partir de: https://github.com/PowerShell/Win32-OpenSSH/releases

Exemple C # d'utilisation de WinSCPnet.dll pour établir une connexion avec le serveur OpenSSH: https://winscp.net/eng/docs/library#csharp

Voici l'extrait de code pour établir une connexion à l'aide du WinSCPnet.dll:

static void WinSCPTest() {
    SessionOptions ops = new SessionOptions {
        Protocol = Protocol.Sftp, 
        PortNumber = 22,
        HostName = "192.168.1.188", 
        UserName = "user123",
        //Password = "Password1",
        SshHostKeyFingerprint = @"ssh-rsa 2048 qu0f........................ddowUUXA="
    };

    ops.SshPrivateKeyPath = @"C:\temp\rsa-key-20190505.ppk";

    using (Session session = new Session()) {
        session.Open(ops);
        MessageBox.Show("success");
    }
}

Remplacez SshHostKeyFingerprint et SshPrivateKeyPath par vos propres valeurs.

Edit: ajout d'une capture d'écran des autorisations du fichier administrators_authorized_keys:  enter image description here 

Lorsque OpenSSH SSH Server est exécuté en tant que service, seule System doit alors disposer de l'autorisation. Toutefois, si vous exécutez sshd.exe à partir de la commande Invite, l'utilisateur actuel doit être le seul utilisateur répertorié (read allow, write deny).

0
Loathing

connectez-vous en tant que ec2-user si vous utilisez une machine Amazon Linux

0
sachin_ur

vérifiez votre clé, cela devrait être une clé rsa (id_rsa.pub) aujourd'hui et non plus une clé dss (id_dsa.pub), utilisez puttygen 0.70 et choisissez RSA sur le type de clé à générer, remplacez la clé publique sur l'hôte ~ /. ssh/registered_keys

0
Don Matteo

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 Deauthorize.

0
Tomás Cot

Ce qui fonctionne pour moi c'est que:

  • Arrêté l'instance ec2
  • détache le volume
  • attacher le volume avec l'ancienne instance en utilisant la même clé et était capable de SSH
  • monter le volume dans un dossier temporaire
  • vérifié le fichier dans le répertoire mount_point/home/ec2-user/.ssh/registered_keys
    • Idéalement, ce fichier doit contenir nos informations de clé, mais pour moi, ce fichier était vide.
  • a copié le fichier de l'ancien instance Commande_clé_instance sur le volume nouvellement monté
  • démonter l'appareil
  • rattachez-vous à l'instance ec2 d'origine
  • démarrez-le et laissez-le passer les contrôles de santé

Cette fois, ça marche pour moi. Mais je ne sais pas pourquoi il ne dispose pas de mes informations de fichier de clé au premier lancement de l'instance. Vérifiez également ce lien https://docs.aws.Amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html#TroubleshootingInstancesConnectingMindTerm

0
Sohaib Mustafa

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 fichier private_key_name . Ppk et le fichier open_ssh.txt doivent se trouver dans le même répertoire pour que la connexion fonctionne. 

0
Geir Borse

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, il se présentera comme suit:

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

et lorsque vous essayez de le coller, vous obtiendrez une erreur de lecture de la clé. Essayez donc d'éditer la clé en une ligne et essayez-la. 

cela devrait ressembler à quelque chose

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

0
Sandeep Chhabra

Dans mon cas, le problème était le suivant: lors de la génération des clés SSH, j'ai intentionnellement changé les répertoires par défaut des clés. Ainsi, au lieu d'utiliser l'emplacement ~/.ssh/registered_keys, j'ai choisi d'utiliser ~/home/user/folder1/.ssh/authorized_keys, pour que ces modifications fonctionnent, j'étais supposé effectuer les mêmes modifications concernant le nouvel emplacement de ce fichier /etc/ssh/sshd_config. Mais jusqu'à ce que je m'en rende compte, j'avais déjà essayé plusieurs solutions suggérées par d'autres personnes, y compris la définition de l'autorisation du dossier personnel sur 700 et celle du répertoire .ssh sur 600.

0
jstMusa

Comme mon expérience, je suggère que vous devriez générer des clés de PuTTY, ne devrait pas générer du côté de Linux. Parce que la clé sera l'ancien format PEM. En tout cas, juste ma suggestion. J'ai suivi les étapes ci-dessous et j'ai bien travaillé avec moi et avec mon équipe.

  1. Générez une paire de clés avec PuTTYGen.exe sur votre serveur local (type: RSA, longueur: 2048 bits).

  2. Enregistrez la clé privée/publique sous forme de fichiers " id_rsa.ppk/id_rsa.pub " sur votre serveur local.

  3. Créez le fichier "allowed_keys" sur votre réseau local, puis entrez la clé publique dans " id_rsa.pub " pour " allowed_keys ". Rappelez-vous que le contenu doit commencer par " ssh-rsa " et une seule ligne .

 enter image description here 

  1. Utilisez WinScp (ou la commande PuTTY) pour copier " registered_keys & id_rsa.pub " de votre local sur votre linux-user-home " /home/$USER/.ssh/ ".

 enter image description here 

  1. Exécutez ces commandes:

    chmod 700 .ssh

    chmod 600 .ssh/registered_keys

    chown $ USER: $ USER .ssh -R

  2. Testez votre paramètre de connexion en chargeant la clé privée " id_rsa.ppk " dans le profil PuTTY.exe, puis cliquez sur Ouvrir (mettez votre phrase secrète le cas échéant).

 enter image description here 

 enter image description here 

0
m.nguyencntt