Question Autorisation SSH refusée (publickey)


J'ai essayé de chercher des réponses aux questions précédentes pour toutes mes questions, mais toutes les réponses qui ont été suggérées auparavant n'ont pas fonctionné pour moi.

J'essaie de me connecter à un linode (exécutant ubuntu 12.04 LTS) depuis mon ordinateur local (exécutant également ubnutu 12.04 LTS)

J'ai créé une clé privée et publique sur mon ordinateur local et copié ma clé publique dans le fichier authorized_keys de mon linode. Cependant, chaque fois que je tente de ssh sur ma linode, j'obtiens le message d'erreur "Autorisation refusée (publickey)".

Ce n'est pas un problème avec la configuration de ssh sur mon linode car je peux y accéder depuis ma machine Windows en utilisant l'authentification par clé.

Dans mon répertoire .ssh sur ma machine ubuntu locale, j'ai mes fichiers id_rsa et id_rsa.pub. Dois-je créer un fichier authorized_keys sur mon ordinateur local?

EDIT: C'est ce que j'obtiens quand je lance ssh -vvv -i id_rsa [youruser] @ [yourLinode]

debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

74
2018-06-22 21:20


origine


1) Que disent les journaux sur le serveur SSH à propos du moment où vous avez cette erreur sur le client? (/var/log/auth.log) 2) Comment avez-vous transféré la clé publique sur le serveur? Toujours utiliser ssh-copy-id pour être sûr des autorisations. Votre répertoire personnel, le .ssh répertoire et le authorized_keys fichier ont des exigences de permission strictes. (voir page de manuel de sshd (8) sur ~/.ssh/authorized_keys). 3) Avez-vous généré une nouvelle paire de clés sur Ubuntu? Si vous avez réutilisé la clé à partir de Windows, vous devrez d'abord la convertir au format OpenSSH. - gertvdijk
La commande devrait a été ssh -vvv -i .ssh/id_rsa .... (notez le chemin d'accès à id_rsa!) - veuillez remplacer - l'ancien journal montre seulement que "nous" n'avons pas de pubKey à envoyer. - guntbert
@ guntbert J'ai raté le .ssh car j'étais déjà dans le répertoire .ssh. Je l'ai aussi essayé avec .ssh / id_rsa mais j'ai eu le même résultat - Pattle
Je vois, alors j'ai mal lu - S'il vous plaît, répondez aux questions de @gertvdijk. - guntbert
Quelqu'un peut-il commenter stackoverflow.com/questions/51254328/unable-to-ssh-to-bitbucket J'ai le même problème. - Mrinmay Kalita


Réponses:


PubKeyAuthentication

Configurez votre client

  1. Générez votre clé
    • ssh-keygen
  2. Configurez ssh pour utiliser la clé
    • vim ~/.ssh/config
  3. Copiez votre clé sur votre serveur
    • ssh-copy-id -i /path/to/key.pub SERVERNAME

Votre fichier de configuration de étape 2 devrait avoir quelque chose de similaire à ce qui suit:

Host SERVERNAME
Hostname ip-or-domain-of-server
User USERNAME
PubKeyAuthentication yes
IdentityFile ./path/to/key

Dépannage

  1. utiliser l'option "-vvv"
  2. Assurez-vous que le serveur a votre clé PUBLIC (.pub).
  3. Assurez-vous que votre IdentiyFile pointe vers votre clé PRIVATE.
  4. Assurez-vous que votre répertoire .ssh contient 700 et que vos fichiers ont 700 autorisations (rwx ------).
  5. tail -f /var/log/auth.log (sur le serveur) et surveillez les erreurs lorsque vous tentez de vous connecter

66
2018-06-23 21:04



Pour info, j'ai créé un petit script à github.com/centic9/generate-and-send-ssh-key qui exécute les étapes nécessaires en une seule fois et assure en outre toutes les autorisations de fichiers / répertoires qui me causent toujours des maux de tête ... - centic
Juste pour élaborer l'étape 2: le IdentityFile line dans ~ / .ssh / config doit pointer sur la clé PRIVATE. - Danny Schoemann
Effectivement. - earthmeLon


Parfois, le problème vient des autorisations et de la propriété. Par exemple, si vous souhaitez vous connecter en tant que root, /root, .ssh et authorized_keys doit appartenir à root. Sinon, sshd ne pourra pas les lire et ne pourra donc pas savoir si l'utilisateur est autorisé à se connecter.

Dans votre répertoire personnel:

chown -R your_user:your_user .ssh

En ce qui concerne les droits, aller avec 700 pour .ssh et 600 pour authorized_keys

chmod 700 .ssh
chmod 600 .ssh/authorized_keys

39
2018-03-15 11:50



Cette réponse m'a aidé. J'avais pris le conseil de ce post et déplacé mon authorized_keys fichier en dehors de mon répertoire personnel crypté. Ce faisant, j'avais par inadvertance changé de propriétaire pour root:root. - Jordan Grant


Vous n'avez pas besoin authorized_keys sur votre client.

Vous devez dire au client ssh d'utiliser réellement la clé que vous avez générée. Il y a plusieurs façons de le faire. Juste pour tester le type ssh -vvv -i .ssh/id_rsa [youruser]@[yourLinode]. Vous devrez fournir votre phrase secrète chaque fois que vous souhaitez vous connecter au serveur.

Si cela a fonctionné, vous pouvez ajouter la clé du ssh-agent avec ssh-add .ssh/id_rsa (vous devrez fournir la phrase secrète une seule fois pour cela et cela devrait fonctionner tant que vous ne vous déconnectez pas / ne redémarrez pas)


12
2018-06-22 21:42



Merci pour votre aide, j'ai édité ma réponse pour montrer ce qui se passe lorsque je tape ce que vous avez suggéré. - Pattle
pour transférer une clé, sur le client, utilisez ssh-copy-id - Panther
@ bodhi.zazen Merci, mais j'ai déjà transféré la clé, ce n'est pas le problème - Pattle
"Vous devez dire au client ssh d’utiliser réellement la clé que vous avez générée." Non, par défaut, il cherchera la clé dans le chemin par défaut, par ex. ~/.ssh/id_rsa. De plus, pour autant que je sache, l'utilisation d'un agent clé est complètement facultative et sans rapport avec le problème. - gertvdijk
@gertvdijk, vous faites des suppositions ici qui ne sont pas encore soutenues par des faits - nous ne savons pas ce qui est arrivé sur le système. - guntbert


Assurez-vous également que le répertoire personnel de l'utilisateur (sur le serveur) appartient à l'utilisateur ssh'ing dans (a été défini sur root: root dans mon cas).

Aurait du être:

sudo chown username:username /home/username;

7
2018-04-20 19:07



Je suis capable de ssh avec des clés publiques / privées avec un utilisateur sur ma boîte Linux locale (par exemple abc), différent de l'utilisateur sur le serveur distant (par exemple, def@123.456.789). Je devais juste m'assurer que l'utilisateur local possédait les fichiers locaux .ssh (par exemple, abc: abc, pas root: abc) - Michael
Cela a fonctionné dans mon cas - Zerquix18


Le problème que j'avais était d'utiliser les mauvaises clés sur le client. J'ai renommé id_rsa et id_rsa.pub pour autre chose. Vous pouvez les renommer à leur valeur par défaut ou, lorsque vous émettez la commande ssh, utilisez-la comme ceci

ssh -i ~/.ssh/private_key username@host

6
2018-02-04 22:28





Vérifiez également la valeur de PasswordAuthentication dans /etc/ssh/sshd_config et si c'est no changer pour yes. N'oubliez pas de redémarrer le service ssh après cela.


6
2018-02-09 10:11



L'OP n'essaie pas d'utiliser l'authentification par mot de passe. Ils ont un sens et utilisent une clé publique / privée. - ctrl-alt-delor


J'ai récemment rencontré ce problème avec mon serveur Web.

Je conserve généralement une liste des clés autorisées sur tous mes serveurs ~/.ssh/authorized_keys2. Selon mon expérience, sshd va chercher ~/.ssh/authorized_keys ou ~/.ssh/authorized_keys2 par défaut.

Dans le cas de mon serveur Web, le /etc/ssh/sshd_config eu cette ligne

AuthorizedKeysFile    %h/.ssh/authorized_keys

au lieu de

AuthorizedKeysFile    %h/.ssh/authorized_keys2

J'ai appliqué ce dernier, redémarré mon démon ssh et résolu mon problème de connexion avec ssh en utilisant ma pubkey.


2
2017-11-24 05:55