web-dev-qa-db-fra.com

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. Dans /etc/ssh/sshd_config j'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: "[email protected]"
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAr3Qo6T5XU06ZigGOd3eKvfBhFLhg5kWv8lz6
qJ2G9XCbexlPQGanPhh+vcPkhor6+7OmB+WSdHeNO652kTofnauTKcTCbHjsT7cJ
GNrO8WVURRh4fabknUHPmauerWQZ6TgRPGaz0aucU+2C+DUo2SKVFDir1vb+4u83
[email protected]
---- END SSH2 PUBLIC KEY ----

J'ai copié la partie de "ssh-rsa AAA" dans "[email protected]" et l'a mise dans le fichier ~/.ssh/authorized_keys sur 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 annuaire ./ssh/authorized_keys/ mais cela n'a pas aidé alors j'ai utilisé ./ssh/authorized_keys en tant que fichieren y collant la clé. J'ai également essayé de générer une paire de clés privée/publique sur le serveur, de placer la clé publique dans ./ssh/authorized_files et 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 que celui-ci ne correspond pas.

É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, /var/log/auth.log a dit:

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

Google me dit que ~/.ssh/ devrait être 700 et que et ~/.ssh/authorized_keys devrait être 600, c'est ce que j'ai fait. /var/log/auth.log dit maintenant:

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

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 dans ~/.ssh/authorized_keyssur une ligne (doit commencer par ssh-rsa)
  • chmod 700 ~/.ssh
  • chmod 600 ~/.ssh/authorized_keys
  • chown $USER:$USER ~/.ssh -R
  • change /etc/ssh/sshd_config pour qu'il contienne AuthorizedKeysFile %h/.ssh/authorized_keys
  • Sudo service ssh restart

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

Merci de votre aide!

89
Forkbeard

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 de discussion (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
22
kuraara

le problème est que windows utilise une nouvelle ligne différente de celle de linux. Ainsi, lors de la copie de la clé de windows vers linux, il existe 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 copiez-la ensuite sur linux, cela devrait fonctionner (ne le truc pour moi).

9
Mischa

Je devais changer les permissions du répertoire personnel

chmod 700 ~
8
Michal Zmuda

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
6
dopple

Le fichier ~/.ssh/authorized_keys 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.

5
Paul

pour moi, le problème était que j'avais créé ~/.ssh/authorized_keys en utilisant root pour qu'il appartienne à root. Je devais chown sshuser:sshuser ~/.ssh/authorized_keys puis il a commencé à fonctionner

1
PeanutPower

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

chmod 600 ~/.ssh/authorized_keys
1
Kaleem

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

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

En plus de toutes les réponses ci-dessus, assurez-vous de copier et coller la clé de 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 coupe les lignes de certains caractères, tels que +, 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, du ssh-rsa à la fin de la zone de texte.

1
Mark Lakata

Voici ce qui a fonctionné pour moi:

Dans puttygen, après avoir généré vos clés, assurez-vous de copier et 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 situé en haut de l'écran puttygen. Encore une fois, assurez-vous de copier et coller le texte du haut de l'écran puttygen (après avoir créé vos clés) dans votre fichier allowed_keys, qui devrait se trouver dans ~/.ssh.

1
zach

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

0
Shimon Doodkin

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

0
hakabe

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. Je crois que c'est la racine de beaucoup de problèmes avec "la clé refusée par le serveur".

Changer la propriété de ces fichiers à l'utilisateur de votre choix ne sera pas une bonne pratique. Je suis donc revenu sur mes étapes 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. Erreur.

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

0
Leo F

En fait, j'ai changé l'autorisation de authorized_keys en 644, puis le problème a été résolu.

chmod 644 ~/.ssh/authorized_keys
0
Peter Liang