SSH Permission refusée (publickey)

72

J'ai essayé de chercher des réponses à ma question dans les questions précédentes, mais toutes les réponses qui ont été suggérées précédemment n'ont pas fonctionné pour moi.

J'essaie de me connecter à un linode (exécutant ubuntu 12.04 LTS) depuis mon ordinateur local (également sous 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 j'essaie 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 mon ordinateur 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 [votre-user] @ [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).
    
posée Pattle 22.06.2013 - 23:20
la source

17 réponses

65

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. utilisez 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
réponse donnée earthmeLon 23.06.2013 - 23:04
la source
37

Parfois, le problème provient des autorisations et de la propriété. Par exemple, si vous souhaitez vous connecter en tant que root, /root , .ssh et authorized_keys doivent 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, choisissez 700 pour .ssh et 600 pour authorized_keys

chmod 700 .ssh
chmod 600 .ssh/authorized_keys
    
réponse donnée Buzut 15.03.2016 - 12:50
la source
12

Vous n’avez pas besoin de authorized_keys sur votre client.

Vous devez indiquer 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é à 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)

    
réponse donnée guntbert 22.06.2013 - 23:42
la source
6

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

    
réponse donnée iman 09.02.2017 - 11:11
la source
5

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

Cela aurait dû être:

sudo chown username:username /home/username;
    
réponse donnée canoodle 20.04.2015 - 21:07
la source
5

Le problème que je rencontrais était l’utilisation de 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 [email protected]
    
réponse donnée Todd 04.02.2017 - 23:28
la source
2

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 dans ~/.ssh/authorized_keys2 . D'après mon expérience, sshd recherchera ~/.ssh/authorized_keys ou ~/.ssh/authorized_keys2 par défaut.

Dans le cas de mon serveur Web, /etc/ssh/sshd_config avait 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.

    
réponse donnée Justin C 24.11.2013 - 06:55
la source
2

C'est ce qui a fonctionné pour moi, le correctif n'est pas le mien 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 clé d'accès public refusée

sudo nano /etc/ssh/sshd_config

Remplacez cette

UsePAM yes
IgnoreUserKnownHosts no
PasswordAuthentication no

Avec cela

UsePAM no
IgnoreUserKnownHosts no
PasswordAuthentication yes

Enregistrez le fichier et redémarrez ssh

reload ssh

ssh devrait fonctionner maintenant en demandant un mot de passe

    
réponse donnée mau 08.04.2017 - 03:25
la source
1

J'ai eu le même problème lors de la copie d'une clé publique d'un utilisateur normal (par exemple, johndoe) d'un système cPanel Centos vers un serveur Ubuntu sur AWS. Comme suggéré par gertvdijk ci-dessus, j'ai coché /var/log/auth.log et bien sûr, il a dit Authentication refused: bad ownership or modes for directory /home/johndoe Il s'est avéré que j'avais à tort /home/johndoe lorsque j'essayais de définir /home/johndoe/public_html comme racine de document virtualhost par défaut pour apache2 (ce n'est pas nécessaire non plus pour cette tâche).

Voir aussi les réponses ici et ici

Le serveur doit uniquement avoir la clé publique dans .ssh/authorized_keys et le client (ordinateur sur lequel vous travaillez) doit avoir la clé privée (.pem ou, si vous utilisez SFTP avec Filezilla, .ppk)

    
réponse donnée site80443 07.01.2017 - 22:54
la source
1

Pour les utilisateurs de Putty comme moi qui sont venus sur ce sujet, vous pouvez également obtenir cette erreur si vous avez oublié d’ajouter l’utilisateur user @ Ip!

D'autres étant la permission sur le fichier de clé chmod à 600)

ssh 1.1.1.1 -i /path/to/.pem file 
Permission denied (publickey).'

ssh [email protected] -i /path/to/.pem file 
    
réponse donnée Alex Punnen 28.03.2017 - 13:06
la source
1

J'ai eu le même problème que décrit dans la question. Le résultat de l'exécution de ssh -vvv -i id_rsa [youruser]@[yourLinode] sur l'ordinateur client était similaire à celui décrit 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 dès le début. le problème.

    
réponse donnée Teemu Leisti 16.05.2017 - 11:41
la source
1

Dans mon cas, le client est ubuntu 14.04lts, le serveur a gagné le serveur 2012 exécutant cygwin. J'utilisais 'ssh [email protected]' lorsque le répertoire du serveur 2012 dans cygwin était / home / Administrator. Donc, il a été sensible à la casse, lorsque j'ai essayé 'ssh [email protected]' (notez la majuscule A sur Administrator), cela a fonctionné correctement.

Un message d'erreur comme "utilisateur non trouvé" m'aurait conduit à la solution beaucoup plus rapidement que "Autorisation refusée (publickey, keyboard-interactive)".

    
réponse donnée Kent 12.07.2016 - 04:41
la source
0

Si tout échoue, vérifiez que votre utilisateur de connexion appartient au groupe ssh 'permisGroup. En d'autres termes, vos utilisateurs sont membres du groupe affiché à la ligne suivante dans /etc/ssh/sshd_config sur le serveur:

AllowGroups ssh #Here only users of 'ssh' group can login
    
réponse donnée biocyberman 17.10.2014 - 08:21
la source
0

Une autre cause possible pourrait être la configuration AllowedUsers dans /etc/ssh/sshd_conf . REMARQUE: la liste est délimitée par espace (non délimitée par des virgules) car j'ai appris à mes dépens.

AllowUsers user1 user2 user3
    
réponse donnée cmbind55 03.09.2015 - 19:07
la source
0

Dans mon cas, le problème a été causé par la copie d'un répertoire .ssh à partir d'un ancien ordinateur. Il s'avère que mon ancienne configuration SSH utilisait des clés DSA qui ont depuis été déconseillées . Passer à une nouvelle paire de clés, cette fois-ci basée sur RSA, a résolu le problème pour moi.

    
réponse donnée Glutanimate 01.10.2017 - 22:16
la source
0

La méthode suivante peut fonctionner si vous pouvez accéder à machineA et à machineB indépendamment (par exemple, de la machineC).

Si ssh-copy-id ne fonctionne pas, l'authentification par mot de passe peut être désactivée. Voici une solution de contournement .

Avoir la clé publique de la machineA dans les clés autorisées de la machine (c'est-à-dire ~ / .ssh / authorized_keys) vous permettra de ssh de la machineA. Cela vaut également pour scp.

Après avoir généré les paires de clés à l'aide de: ssh-keygen

Sur machineA , exécutez cat ~/.ssh/id_rsa.pub

Exemple de sortie:

  

ssh-rsa AAAAB3NzaSGMFZW7yB [email protected]

Copiez la clé imprimée ( ⌘ Commande + C , ou CRTL + C ) puis ajoutez-la à le fichier ~ / .ssh / authorized_keys sur machineB .

Par exemple, exécutez les opérations suivantes sur machineB :

  

echo 'ssh-rsa AAAAB3NzaSGMFZW7yB [email protected]' >> ~/.ssh/authorized_keys

    
réponse donnée anask 25.03.2018 - 07:11
la source
0

Fonctionne également sur Ubuntu 16.04.

Le problème se situe dans le fichier sshd_config

Voici la solution ULTIMATE:

Connectez-vous en tant que racine à votre serveur Ubuntu

vi /etc/ssh/sshd_config

Maintenant, allez tout en bas et changez la valeur de "non" à "oui".

Cela devrait ressembler à ceci:

Passez à non pour désactiver les mots de passe en texte clair tunnellisés

PasswordAuthentication yes
service sshd reload

pour prendre effet.

Maintenant, vous pouvez simplement une clé en utilisant la commande suivante de votre machine LOCAL (alias ordinateur portable, etc.)

Alors, ouvrez la nouvelle fenêtre du terminal et ne vous connectez PAS au serveur, mettez simplement cette commande:

ssh-copy-id john @ serverIPAddress

(Remplacez john par votre nom d'utilisateur).

vous devriez y aller

    
réponse donnée Galapagos 18.07.2018 - 22:22
la source

Lire d'autres questions sur les étiquettes