Le serveur continue à demander le mot de passe après avoir copié ma clé publique SSH sur allowed_keys


44

J'ai un serveur Ubuntu fonctionnant dans un nuage. J'ai créé un utilisateur ( git). Dans le dossier /home/git, j'ai créé le répertoire .ssh/et le authorized_keysfichier.

Mais lorsque je mets ma clé publique SSH dans le authorized_keysfichier, le serveur continue à me demander le mot de passe.

Qu'ai-je fait de mal?


Où mettez-vous ypur public? en utilisateur git ou en racine? comment y accédez-vous? comme ssh <vous> @ <serveur> o <git> @ <serveur> ou racine @ <serveur> .. vérifiez cela et ajoutez plus d'informations.
maniat1k

Réponses:


42

Du côté du serveur, le démon ssh enregistre les erreurs /var/log/auth.log. Consultez ce fichier pour voir ce qui est signalé.

Du côté client, lors de l’établissement de la connexion, vous pouvez ajouter l’ -vindicateur (ou -vvou -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_keysappartient git.
  • Assurez-vous d' /home/git/.ssh/authorized_keysavoir un mode de 600 ( -rw-------).

Vérifiez également le /etc/ssh/sshd_configfichier.

  • PubkeyAuthentication devrait être réglé sur yes
  • Il y a aussi la AuthorizedKeysFiledirective qui détermine le chemin où les clés autorisées doivent être localisées. Assurez-vous qu'il est commenté ou sur le défaut de %h/.ssh/authorized_keys.

Merci! Je vais essayer cette option et revenir plus tard aux commentaires!
Luis Dalmolin

Que faites-vous si vous ne voyez pas un /var/log/auth.logfichier? Y a-t-il un moyen de l'activer?
Steve Robbins

1
Les journaux peuvent se trouver dans / var / log / secure si vous n’avez pas de
fichier

Silly erreur, j'avais scp-ed le fichier .pub à juste dans le dossier .ssh sur le serveur que je voulais connecter. Assurez-vous de le déplacer dans le dossier allowed_keys.
CenterOrbit

J'ai également dû supprimer les autorisations d'écriture de groupe de mon répertoire personnel. Puis j'ai redémarré ssh avecsudo service ssh restart
Dylan Pierce

19

Assurez-vous également que votre répertoire personnel (dans votre cas, / home / git) est accessible en écriture pour vous. J'ai eu ce problème une fois parce que mon répertoire personnel était en écriture de groupe. /var/log/auth.log a déclaré: "Authentification refusée: mauvaise propriété ou modes pour le répertoire / home / chuck". (Cela permet de s’assurer qu’il n’utilise pas un fichier allowed_keys avec lequel un autre joueur s’est occupé de vous!)


Bien que cela soit certainement utile, je pense que ceci est davantage un ajout à la réponse de xeyes .
gertvdijk

1
Oh mon dieu, merci beaucoup!. Mes yeux brûlaient parce que toutes les recherches que j'ai faites sur Google. Enfin cela a fonctionné! Merci beaucoup.
GTRONICK

Man merci! J'ai passé des heures à chercher une solution ... et cela a résolu tous mes problèmes.
Afaria

Ouaip. c'était ça. content d'avoir décidé de lire la réponse suivante
Katushai

Vérifiez également dans / etc / passwd quel est le répertoire de base de l'utilisateur. Mon problème bizarre était qu'il n'y en avait pas un standard
drodsou

5

Il existe différentes façons de résoudre ce problème: vous pouvez configurer sshd(côté serveur) ou ssh(côté client) de ne pas utiliser l'authentification par mot de passe. La désactivation de l'authentification par mot de passe sur le serveur renforce la sécurité de votre serveur, mais vous aurez des problèmes si vous perdez votre clé.

Pour effectuer ssh(côté client) à l'aide de l'authentification par clé publique, ajoutez quelques options à la sshcommande:

ssh -o PubkeyAuthentication=yes -o PasswordAuthentication=no -X git@server

Si cela fonctionne, vous pouvez définir cette PasswordAuthentication=nooption de manière permanente dans le fichier de configuration du client ssh, spécifique au /etc/ssh/ssh_configsystème ou ~/.ssh/configspécifique à l'utilisateur (pour plus de détails, voir man ssh_config).


1
Par défaut, toutes les configurations de clients SSH ( /etc/ssh/ssh_config) sur les systèmes Debian / Ubuntu préfèrent déjà PubkeyAuthenticationet essaient d’abord, comme vous pourrez le constater lors de l’appel sshen mode détaillé.
gertvdijk

3

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


1

Une autre chose à vérifier est de savoir s'il y a des retours chariot supplémentaires dans votre clé publique. J'ai suivi le conseil ci-dessus pour consulter le fichier /var/log/auth.log et j'ai constaté une erreur lors de la lecture de la clé. La clé avait environ deux lignes au lieu de quatre. Il y avait des retours chariot supplémentaires intégré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é.


1
Je triple vérifié les autorisations et sshd_config. Je me suis cogné la tête contre le mur pendant une demi-heure. C'était ma faute! D'une manière ou d'une autre, j'ai pris l'habitude de mettre fin à tous les fichiers que je modifie à la main avec un saut de ligne supplémentaire. Même avec une clé et un retour chariot à la fin , il suffit de gâcher l'autorisation.
jrhorn424

Assurez-vous également que vous avez le bit ----- END RSA PRIVATE KEY -----.
tobych

1

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

ssh-add path/to/private/key

1

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

u@pc:~$ ssh-agent bash
u@pc:~$ 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)

0

Il se peut aussi que vous appeliez

sudo git clone gituser@domain:repo.git

où n'a pas été ajouté la clé de l'utilisateur root à authorized_keysdesgituser


0

Sur une machine fonctionnant sous Ubuntu 18.04.02 LTS, la suggestion de définir les autorisations ~/.sshsur 600 ne fonctionnait pas pour moi. J'ai dû définir les autorisations sur 700, puis tout a bien fonctionné.


0

J'avais les autorisations de fichiers .ssh / directory et allowed_keys correctes, mais j'ai rencontré ce problème de "demande de mot de passe" en raison d'un problème différent, provoqué par l'utilisateur

J'avais utilisé un surlignage et un copier / coller basés sur la souris pour copier les informations de mon id_rsa.pub local dans le fichier allowed_keys sur le serveur. Cela a réussi à copier les données en une seule ligne, mais il y avait des espaces indésirables à la fin des lignes visibles difficiles à voir lors de l'édition du fichier avec vi. Une fois que j'ai enlevé ces espaces non désirés, je pouvais entrer dans SSH.


0

Donc, ce qui m'est arrivé, c’est que j’ai accès à 2 ordinateurs virtuels à partir de mon ordinateur local (2 clés id_rsa.pub et id_rsa2.pub). Je me suis rendu compte que ma connexion ssh utilise id_rsa.pub par défaut pour toute connexion ssh utilisateur@xx.xx.xx.xx. J'ai résolu mon problème en ajoutant un fichier de configuration et en spécifiant l'identité à utiliser pour chaque hôte, comme suit:

vi ~/.ssh/config

Add both hostnames and their identity file as follows:

Host server1.nixcraft.com
  IdentityFile ~/Users/.ssh/id_rsa1
Host server2.nixcraft.com
  IdentityFile /backup/home/aymen/.ssh/id_rsa2
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.