Le serveur continue de demander un mot de passe après avoir copié ma clé publique SSH sur authorized_keys

Côté serveur, le démon ssh enregistre les erreurs dans /var/log/auth.log , alors vérifiez ce fichier pour voir ce qui est signalé.

Du côté du client, lors de l'établissement de la connexion, vous pouvez ajouter l'indicateur -v (ou -vv ou -vvv ) pour augmenter la verbosité. Vous pourrez peut-être identifier votre problème de cette façon.

Voici d'autres choses à vérifier.

• Assurez-vous que /home/git/.ssh/authorized_keys appartient à git .
• Assurez-vous que /home/git/.ssh/authorized_keys a un mode de 600 ( -rw------- ).

Vérifiez également le fichier /etc/ssh/sshd_config .

• PubkeyAuthentication doit être défini sur yes
• Il y a aussi la directive AuthorizedKeysFile qui détermine la chemin où les clés autorisées doivent être localisées. Assurez-vous que c'est commenté ou sur la valeur par défaut de %h/.ssh/authorized_keys .

Assurez-vous également que votre répertoire utilisateur (dans votre cas, / home / git) est uniquement accessible en écriture. J'ai eu ce problème une fois parce que mon répertoire personnel était inscriptible par groupe. /var/log/auth.log y a déclaré: "Authentification refusée: propriété incorrecte ou modes pour répertoire / home / chuck". (ceci pour s'assurer qu'il n'utilise pas un fichier authorized_keys avec lequel quelqu'un d'autre a joué avec vous!)

Il existe différentes manières de résoudre ce problème: vous pouvez configurer sshd (côté serveur) ou ssh (côté client) pour ne pas utiliser l'authentification par mot de passe. La désactivation de l'authentification par mot de passe sur le serveur améliore la sécurité de votre serveur, mais vous risquez de perdre votre clé.

Pour que ssh (côté client) utilise l’authentification de la pubkey, ajoutez des options à la commande ssh :

ssh -o PubkeyAuthentication=yes -o PasswordAuthentication=no -X [email protected]

Si cela fonctionne, vous pouvez définir l'option PasswordAuthentication=no de manière permanente dans le fichier de configuration du client ssh /etc/ssh/ssh_config pour l'ensemble du système ou ~/.ssh/config pour l'utilisateur (pour plus de détails, voir man ssh_config ).

Utilisez-vous ~ / .ssh / config sur votre ordinateur local? J'ai rencontré ce problème lorsque j'utilise la directive IdentityFile dans le fichier de configuration et que je pointe vers la clé publique. Par exemple:

Host Cloud
    Hostname cloud.theclouds.com
    User git
    IdentityFile ~/.ssh/config/mykey # This is correct

    # IdentityFile ~/.ssh/config/mykey.pub # This is incorrect

Si votre dossier de base est chiffré, votre fichier authorized_keys n'est pas lisible avant la connexion. Vous devez le déplacer à l'extérieur de votre maison.

Cette section explique comment procéder: lien

Une autre chose à vérifier est la présence de retours chariot supplémentaires dans votre clé publique. J'ai suivi les conseils ci-dessus pour examiner le fichier /var/log/auth.log et j'ai constaté une erreur lors de la lecture de la clé. La clé était d'environ deux lignes de long au lieu de quatre. Il y avait des retours chariot supplémentaires incorporés dans la clé.

Lorsque vous utilisez l'éditeur vi, utilisez shift-j pour joindre les lignes et effacer l'espace supplémentaire dans la chaîne de clé.

Si vous avez plusieurs clés privées, utilisez le commutateur -v de votre commande de connexion ssh pour vérifier si vos autres clés primaires sont utilisées pour essayer de vous connecter. Si ce n'est pas le cas, demandez au client ssh de les utiliser avec la commande suivante:

ssh-add path/to/private/key

Vous pouvez également ajouter votre clé à l'agent SSH:

[email protected]:~$ ssh-agent bash
[email protected]:~$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/u/.ssh/id_rsa: # ENTER YOUR PASSWORD
Identity added: /home/u/.ssh/id_rsa (/home/u/.ssh/id_rsa)

Il se pourrait aussi que vous appeliez

sudo git clone [email protected]:repo.git

où la clé ssh des utilisateurs root n'a pas été ajoutée à authorized_keys of gituser