SSH Permission refusée (publickey)

Voici ce qui a fonctionné pour moi, la solution n'est pas la mienne mais je préfère l'écrire ici au cas où quelqu'un d'autre aurait le même problème.

L'auteur original l'a posté ici : digital-ocean-public-access-key-denied

sudo nano /etc/ssh/sshd_config

Remplacez ceci

UsePAM yes
IgnoreUserKnownHosts no
PasswordAuthentication no

Avec cette

UsePAM no
IgnoreUserKnownHosts no
PasswordAuthentication yes

Sauvegardez le fichier et redémarrez ssh

reload ssh

ssh devrait fonctionner maintenant en demandant un mot de passe

J'ai eu le même problème que celui décrit dans la question. Le résultat de l'exécution de ssh -vvv -i id_rsa [youruser]@[yourLinode] sur la machine cliente était similaire à celle décrite dans la question. J'ai vérifié toutes les autorisations de fichiers et de répertoires comme indiqué dans les autres réponses, et elles étaient correctes.

Il s'est avéré que lors de la copie du fichier généré id_rsa.pub sur la machine serveur, en tant que fichier ~username/.ssh/authorized_keys , J'avais accidentellement omis le mot ssh-rsa depuis le début. Le fait de l'ajouter a résolu le problème.

J'avais ajouté un mauvaise clé au serveur. Comme je n'ai pas utilisé la commande avec une option pour spécifier une certaine clé, elle a ajouté le fichier clé standard.

Assurez-vous que vous avez utilisé ssh-copy-id -i CORRECT_KEY.pub

Cette mauvaise clé a bien fonctionné avec un client, car ce client avait aussi cette clé. Mais lorsqu'on essaie de se connecter avec un autre client au même serveur, cela échoue évidemment.

De plus, ce qui pourrait être intéressant, c'est que vous obtenez plus de logging avec ssh -vv au lieu de l'unique -v .

Dans mon cas, le problème était dû à la copie d'un fichier .ssh d'une ancienne machine. Il s'est avéré que mon ancienne configuration SSH utilisait des clés DSA qui ont depuis été déprécié . Le passage à une nouvelle paire de clés, cette fois basée sur RSA, a résolu le problème pour moi.