J'essaie de me connecter à un Linode (exécutant Ubuntu 12.04 LTS) à partir de mon ordinateur local (exécutant également Ubuntu 12.04 LTS).

J'ai créé une clé privée et publique sur mon ordinateur local et copié ma clé publique dans le fichier allowed_keys de mon Linode. Cependant, chaque fois que j'essaie de ssh sur mon Linode, je reçois le message d'erreur Permission denied (publickey).

Ce n'est pas un problème avec la façon dont ssh est configuré sur mon Linode car je peux y accéder depuis ma machine Windows en utilisant l'authentification par clé.

Dans mon .sshrépertoire sur ma machine Ubuntu locale, j'ai mes fichiers id_rsaet id_rsa.pub. Dois-je créer un fichier allowed_keys sur ma machine locale?

EDIT: Voici ce que je reçois quand je cours 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).

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 l' é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

Vous pouvez effectuer des ajouts IdentitiesOnly yespour vous assurer que vous utilisez sshle IdentityFileet aucun autre fichier de clés lors de l'authentification, ce qui peut entraîner des problèmes et n'est pas une bonne pratique.

Dépannage

1. utilisez l'option "-vvv"
2. Assurez-vous que le serveur dispose de votre clé PUBLIC (.pub).
3. Assurez-vous que votre IdentiyFile pointe sur votre clé privée.
4. Assurez-vous que votre répertoire .ssh contient 700 et vos fichiers 700 autorisations (rwx ------).
5. tail -f /var/log/auth.log (sur le serveur) et surveillez les erreurs lorsque vous essayez de vous connecter
6. Si vous avez plusieurs fichiers de clé, essayez IdentitiesOnly yesde limiter l'authentification pour utiliser la clé unique spécifiée.

Parfois, le problème provient des autorisations et de la propriété. Par exemple, si vous voulez vous connecter en tant que root, /root, .sshet authorized_keysdevez appartenir à la racine. Sinon, sshd ne pourra pas les lire et ne pourra donc pas dire si l'utilisateur est autorisé à se connecter.

Dans votre répertoire personnel:

chown -R your_user:your_user .ssh

Quant aux droits, aller avec 700 pour .sshet 600 pourauthorized_keys

chmod 700 .ssh
chmod 600 .ssh/authorized_keys

Vous n'avez pas besoin authorized_keysde 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 fonctionne, vous pouvez ajouter la clé à ssh-agentavec 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)

Vérifiez également la valeur de PasswordAuthenticationin /etc/ssh/sshd_configet si cela nochange en yes. N'oubliez pas de redémarrer le service ssh après cela.

Le problème que j'ai eu était qu'il utilisait les mauvaises clés sur le client. J'avais renommé id_rsa et id_rsa.pub en quelque chose d'autre. Vous pouvez les renommer à nouveau par défaut ou les utiliser comme ceci lorsque vous exécutez la commande ssh.

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

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

Aurait du être:

sudo chown username:username /home/username;

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

Je conserve généralement une liste de clés autorisées sur tous mes serveurs ~/.ssh/authorized_keys2. De mon expérience, sshdcherchera ~/.ssh/authorized_keysou ~/.ssh/authorized_keys2par défaut.

Dans le cas de mon serveur web, le /etc/ssh/sshd_configavait 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 à l'aide de ma clé publique.

Une autre cause possible pourrait être la AllowedUsersconfiguration dans /etc/ssh/sshd_conf. NOTE: la liste est délimitée par des espaces (pas par des virgules) comme j'ai appris à la dure.

AllowUsers user1 user2 user3

Si tout échoue, vérifiez que votre utilisateur de connexion appartient au groupe Allowed de ssh. Autrement dit, vos utilisateurs sont membres du groupe indiqué à la ligne suivante /etc/ssh/sshd_configdu serveur:

AllowGroups ssh #Here only users of 'ssh' group can login

J'ai mon cas, le client est Ubuntu 14.04lts, le serveur a été gagnant 2012 serveur exécutant Cygwin. J'utilisais 'administrateur ssh @ xxxx', lorsque le répertoire du serveur 2012 dans cygwin était / home / Administrator. C'était donc sensible à la casse, quand j'ai essayé 'ssh Administrator @ xxxx' (notez le majuscule A sur Administrateur), puis cela a bien fonctionné.

Un message d'erreur du type "utilisateur non trouvé" m'aurait conduit à la solution beaucoup plus rapidement que "autorisation refusée (publickey, clavier interactif)".

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

Voir aussi les réponses ici et ici

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

Pour les utilisateurs de Putty comme moi qui sont venus sur ce fil de discussion, vous risquez également d'obtenir cette erreur si vous avez oublié d'ajouter l'utilisateur utilisateur @ 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 user@1.1.1.1 -i /path/to/.pem file 

C’est ce qui a fonctionné pour moi, la solution ne m’appartient pas, mais je préférerais la noter ici au cas où une autre personne aurait le même problème.

L'auteur d'origine 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 ça

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

J'ai eu le même problème que décrit dans la question. Le résultat de l'exécution ssh -vvv -i id_rsa [youruser]@[yourLinode]sur la machine 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.pubsur le serveur ~username/.ssh/authorized_keys, j'avais accidentellement omis le mot ssh-rsadepuis le début. L'ajouter a résolu le problème.

Fonctionne également sur Ubuntu 16.04.

Le problème est dans le sshd_configfichier

Voici la solution ULTIMATE:

Connectez-vous en tant que root sur votre serveur Ubuntu

vi /etc/ssh/sshd_config

Allez maintenant tout en bas et changez la valeur de "non" à "oui".

Ça devrait ressembler à ça:

Passez à non pour désactiver les mots de passe en clair en tunnel

PasswordAuthentication yes
service sshd reload

prendre effet.

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

Donc, ouvrez une nouvelle fenêtre de terminal et ne vous connectez PAS au serveur, entrez simplement cette commande:

ssh-copy-id john @ serverIPAddress

(Remplacez john par votre nom d'utilisateur).

vous devriez être aller aller

Certaines personnes qui se demandent ont peut-être configuré l'accès ssh de manière à ce qu'il ne soit la clé que sur le compte root, puis a créé un nouvel utilisateur et ne s'est pas rendu compte qu'il en fallait

ssh root@your-ip-address

rsync --archive --chown=[user]:[user] ~/.ssh /home/[user]

logout

Puis réessaye. Remplacez [utilisateur] par votre nouveau compte utilisateur.

Ceci est courant lorsque vous configurez un nouveau serveur sur DigitalOcean lorsque vous avez utilisé les touches ssh lors de la configuration.

https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-18-04

Dans mon cas, le problème était dû à la copie d'un .sshrépertoire à partir d'un ancien ordinateur. Il s'avère que mon ancienne configuration SSH utilisait des clés DSA qui sont depuis déconseillées . Le passage à une nouvelle paire de clés, cette fois basée sur RSA, a résolu le problème pour moi.

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

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

Le fait d'avoir la clé publique de machineA dans les clés autorisées de machineB (c'est-à-dire ~ / .ssh / allowed_keys) vous permettra de passer en SSH depuis la machineA. Cela vaut également pour scp.

Après avoir généré les paires de clés en utilisant: ssh-keygen

Sur machineA , exécutezcat ~/.ssh/id_rsa.pub

Exemple de sortie:

ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA

Copiez la clé imprimée ( ⌘ Command+ C, ou CRTL+ C) puis ajoutez-la au fichier ~ / .ssh / registered_keys sur la machineB .

Par exemple, exécutez ce qui suit sur machineB :

echo 'ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA' >> ~/.ssh/authorized_keys