Essayer de faire l’authentification ssh avec les fichiers de clés: le serveur a refusé notre clé

J'essaie de configurer l'authentification SSH avec des fichiers de clés au lieu de nom d'utilisateur / mot de passe. Le client est une machine Windows exécutant PuTTY et le serveur est un serveur Ubuntu 12.04 LTS.

J'ai téléchargé puttygen.exe et l'ai généré une paire de clés. En /etc/ssh/sshd_configj'ai cette ligne:

AuthorizedKeysFile %h/.ssh/authorized_keys

et sur le fichier de clé publique de mon client, il dit ceci:

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "my@email.address.com"
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAr3Qo6T5XU06ZigGOd3eKvfBhFLhg5kWv8lz6
qJ2G9XCbexlPQGanPhh+vcPkhor6+7OmB+WSdHeNO652kTofnauTKcTCbHjsT7cJ
GNrO8WVURRh4fabknUHPmauerWQZ6TgRPGaz0aucU+2C+DUo2SKVFDir1vb+4u83
AV1pKxs=my@email.address.com
---- END SSH2 PUBLIC KEY ----

J'ai copié la partie de "ssh-rsa AAA" dans "my@email.address.com" et l'ai mise dans le fichier ~/.ssh/authorized_keyssur mon serveur (dans mon propre dossier personnel). Dans PuTTY, sous Connexion> SSH> Auth, j'ai entré le chemin de la clé privée générée sur mon client et enregistré les paramètres de la session.

J'ai redémarré le serveur ssh avec

sudo service ssh restart

Maintenant, si je charge le profil dans PuTTY (j'ai vérifié que la clé privée est toujours dans Connection> SSH> Auth et que le chemin est correct) et que je lance le profil, il est indiqué

Server refused our key

J'ai essayé de mettre la clé publique dans un fichier sous le répertoire, ./ssh/authorized_keys/ mais cela ne m'a pas aidé. J'ai donc utilisé ./ssh/authorized_keysce fichier sous forme de fichier et y ai collé la clé. J'ai également essayé de générer une paire de clés privée / publique sur le serveur, d'y insérer la clé publique ./ssh/authorized_fileset de charger la clé privée dans PuTTY sur mon client. Le redémarrage du serveur n'a pas aidé non plus.

J'ai trouvé que l'erreur peut être résolue en plaçant la clé à un emplacement situé en dehors du dossier de base de l'utilisateur, mais cela n'est utile que si le dossier de base est crypté, ce qui n'est pas le cas de celui-ci.

Également essayé de générer une clé de 4096 bits, en pensant que 1024 était trop court.

Comment puis-je le faire fonctionner? Merci!

MODIFIER:

Ok, a /var/log/auth.logdit:

sshd: Authentication refused: bad ownership or modes for directory /home/vorkbaard/.ssh

Google me dit ~/.ssh/devrait être 700 et et ~/.ssh/authorized_keysdevrait être 600, alors je l'ai fait. Maintenant /var/log/auth.logdit:

sshd: error: key_read: uudecode AAAAB3N [etc etc etc until about 3/4 of my public key]

Ok, c'est corrigé mais je ne vois pas en quoi c'est différent de ce que j'ai déjà essayé.

Ce que j'ai fait:

• générer une paire de clés avec puttygen.exe (longueur: 1024 bits)
• charger la clé privée dans le profil PuTTY
• entrez la clé publique ~/.ssh/authorized_keys sur une seule ligne (il faut commencer par ssh-rsa)
• chmod 700 ~/.ssh
• chmod 600 ~/.ssh/authorized_keys
• chown $USER:$USER ~/.ssh -R
• changer de /etc/ssh/sshd_configsorte qu'il contientAuthorizedKeysFile %h/.ssh/authorized_keys
• sudo service ssh restart

Pour le dépannage, faites # tail -f /var/log/auth.log.

Merci de votre aide!

Je viens de rencontrer ce problème. Bien que la configuration soit correctement configurée, comme cela a déjà été mentionné dans ce fil (autorisations sur allowed_keys, etc.), il s'avère que j'ai eu la clé publique au mauvais format. C'était sous la forme de:

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "imported-openssh-key"
AAAAB3NzaC1yc2EAAAADAQABAAABAQDUoj0N3vuLpeviGvZTasGQ...
... lPmTrOfVTxI9wjax2JvKcyE0fiNMzXO7qiHJsQM9G9ZB4Lkf71kT
---- END SSH2 PUBLIC KEY ----

Ce qui ne fonctionnait pas. Mais ça marche en ayant le sous la forme:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDU.....j0N3vuLpeviGvZTasGQa1rcJiPXQMW7v3uurb+n94B9MQaaWR0odsg5DJQL92TNenOda5BO1nd08y6+sdLQmHXExTz6X8FzgoVsAkEl3RscxcxHUksiKA9JfTo38vQvG/bPxIHMCuSumCQVA1laf3rO/uOrkcB7iMWhaoi1/z6AbFtPzeh7xjGfInMWwtBI0CsHSRF73VWIxT26w0P+KjafCjSn/7vDO1bT8QHujSQelU/GqaVEvbbvPl1a7POVjKgHLNekolwRKfNeVEewcnmZaoqfHgOKlPmTrOfVTxI9wjax2JvKcyE0fiNMzXO7qiHJsQM9G9ZB4Lkf71kT UserName@HOSTNAME

Le problème est que Windows utilise une nouvelle ligne différente de linux. Ainsi, lors de la copie de la clé de Windows à Linux, il y a un \ n à la fin de la ligne que vous ne pouvez pas voir sous Linux dans l'éditeur.

Si vous suivez le fichier /var/log/auth.log et essayez de vous connecter, l'erreur est la suivante:

sshd: erreur: clé_read: code AAAAAB3N [....] == \ n

Si vous changez votre clé sur windows pour qu’elle soit sur une seule ligne sans nouvelle ligne à la fin et que vous la copiez ensuite sur linux, cela devrait fonctionner (a fait le tour pour moi).

Je devais changer les permissions du répertoire personnel

chmod 700 ~

J'ai dû modifier les autorisations du répertoire ~ / .ssh de 770 à 700 et les autorisations du fichier ~ / .ssh / allowed_keys de 660 à 600.

Pour une raison quelconque, la suppression des autorisations de groupe a résolu ce problème pour moi.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Le ~/.ssh/authorized_keysfichier nécessite que les clés soient sur une seule ligne. Si vous l'avez ajouté sur plusieurs lignes, comme dans votre collage ci-dessus, essayez de joindre les lignes.

Voici ce qui a fonctionné pour moi:

Dans puttygen, après avoir généré vos clés, assurez-vous de copier et de coller les informations du champ supérieur pour accéder à votre fichier allowed_keys. Si vous enregistrez votre clé publique sur votre ordinateur client, puis l'ouvrez, le texte est différent de celui en haut de l' puttygenécran. Encore une fois, assurez-vous de copier et coller le texte en haut de l' puttygenécran (après avoir créé vos clés) dans votre fichier allowed_keys, qui devrait se trouver dans ~/.ssh.

En plus de toutes les réponses ci-dessus, assurez-vous de copier et coller la clé puttygencorrectement!

Si vous double-cliquez simplement sur le gros de la chaîne de clé pour la sélectionner, vous risquez de ne pas obtenir la chaîne complète, car la zone de texte divise les lignes de certains caractères +, de sorte que vous ne sélectionnez pas le texte après le +caractère ( que vous ne pouvez pas voir car la zone de texte est trop petite). Assurez-vous de sélectionner la chaîne entière manuellement, de la ssh-rsafin de la zone de texte.

Parfois, il peut être un problème lié à avoir la clé publique sur une ligne, cette approche semble la résoudre

echo 'the content of the public key' > /root/.ssh/authorized_keys

pour moi le problème était que j'avais créé en ~/.ssh/authorized_keysutilisant root afin que root appartienne. Je devais chown sshuser:sshuser ~/.ssh/authorized_keysalors ça a commencé à fonctionner

Moi aussi, j'ai fait face à cette erreur et l'ai résolue en modifiant les autorisations du fichier allowed_keys 600.

chmod 600 ~/.ssh/authorized_keys

L'erreur courante est que les gens utilisent un éditeur de texte (comme Vim) et collent le texte copié avant l'activation de "l'insertion" (appuyez sur + i dans Vim avant de coller).

En fait, j'ai changé authorized_keysla permission en 644, puis le problème a été résolu.

chmod 644 ~/.ssh/authorized_keys

pour déboguer un ssh ouvert, on peut utiliser:

sudo `which sshd` -p 2020 -Dd

il exécute sshd sur un autre port 2020. Il exécute sshd en tant que programme actuel pour que la sortie passe à l'écran. si fermé il est fermé.

puis essayez de vous connecter.

explication:

• `quel sshd` - localise l'adresse sshd, essayez d'exécuter quel sshd voit ce qu'il affiche. lorsqu’il utilise des guillemets arrières, il s’exécute et renvoie le résultat à la place.
• -p 2020 - spécifie le port
• -D - enregistrer dans un fichier
• -d - se connecter à l'écran

https://www.attachmate.com/documentation/rsit-unix-802/rsit-unix-guide/data/sshd_options_ap.htm

Je créais les fichiers .ssh et registered_keys en étant connecté en tant que root, ce qui donnait des autorisations erronées. Il a également placé tous les fichiers dans le répertoire racine.

Changer la propriété de ces fichiers à l'utilisateur de votre choix ne sera pas une bonne pratique. Je suis donc revenu sur mes pas et je me suis assuré que j'étais connecté en tant qu'utilisateur pour lequel je voulais utiliser SSH et que je créais à nouveau .ssh et allowed_keys.

Instructions pour connecter Win7 au serveur Xubuntu 15.04: Comment créer des clés SSH avec Putty pour se connecter à un SMV