web-dev-qa-db-fra.com

L'authentification par clé publique SSH ne fonctionne pas

Je ne parviens pas à configurer l'authentification par clé publique pour un serveur SSH sur Ubuntu Server 12.04 (A) pour l'authentification à partir d'un serveur Ubuntu 13.04 (B).

Ce que je fais maintenant (j'essaie de suivre les instructions ici ):

  • Sur B: Créez une nouvelle clé avec ssh-keygen -C "", n'utilisez pas de phrase de passe, écrivez dans /.ssh/id_rsa - je ne reçois aucune erreur.
  • Sur B: Exécutez ssh-copy-id -i /.ssh/id_rsa user@Host-a - également, un message de réussite
  • Sur B: ssh -i /.ssh/id_rsa user@Host-a - Je dois encore entrer mon mot de passe pour user@Host-a

Sur A, j’ai vérifié si le /.ssh/authorized_keys était modifié après l’exécution de ssh-copy-id, et c’est le cas. De plus, sur les deux appareils, j'ai ajouté ceci à /etc/ssh/sshd_config:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile /.ssh/authorized_keys

Est-ce que quelqu'un sait ce qui pourrait être le problème ici?

Voici la queue de mon /var/log/auth.log sur la machine A:

Jun 13 22:17:56 laptop-camil sshd[12344]: Server listening on 0.0.0.0 port 22.
Jun 13 22:17:56 laptop-camil sshd[12344]: Server listening on :: port 22.
Jun 13 22:18:27 laptop-camil sshd[12345]: Authentication refused: bad ownership or modes for directory /.ssh
Jun 13 22:18:30 laptop-camil sshd[12345]: Accepted password for camilstaps from 164.138.27.37 port 48407 ssh2
Jun 13 22:18:30 laptop-camil sshd[12345]: pam_unix(sshd:session): session opened for user camilstaps by (uid=0)
Jun 13 22:18:35 laptop-camil sshd[12464]: Received disconnect from 164.138.27.37: 11: disconnected by user
Jun 13 22:18:35 laptop-camil sshd[12345]: pam_unix(sshd:session): session closed for user camilstaps
Jun 13 22:18:42 laptop-camil sshd[12516]: Authentication refused: bad ownership or modes for directory /.ssh
Jun 13 22:18:44 laptop-camil sshd[12516]: Connection closed by <Host-b> [preauth]
12.04serversshsecuritysshd
10
Keelan

Quelque chose dans les fichiers journaux, en particulier /var/log/auth.log? Vous pouvez également vérifier les autorisations sur le répertoire .ssh et les fichiers.

Je n'ai pas eu à modifier sshd_config pour ce type d'accès, moi-même. Je me demande si votre modification a cassé des choses, en particulier la ligne AuthorizedKeysFile. En règle générale, vous souhaitez placer les authorised_keys sous $USER/.ssh.

Voici la permission d'un utilisateur sur l'un de mes serveurs:

:~/.ssh$ ls -ld .
drwx------ 2 rrd rrd 4096 May 28 17:57 .

:~/.ssh$ ll
total 280
-rw-r----- 1 rrd rrd   4351 May 22 16:20 authorized_keys
-rw------- 1 rrd rrd   1679 Apr 27  2012 id_rsa
-rw-r--r-- 1 rrd rrd    399 Apr 27  2012 id_rsa.pub
-rw-r--r-- 1 rrd rrd 266138 Jun 13 00:18 known_hosts

Assurez-vous que les fichiers individuels sont au moins limités.

Comme le fait remarquer Guntbert, vérifiez également que le répertoire et les fichiers vous appartiennent. Les autorisations n'auront aucun sens (ou ne fonctionneront pas) autrement.

À qui appartiennent les clés de allowed_keys sur B? (Le bit qui dit utilisateur @ hôte après la clé.) S'agit-il de racine @ A?

C'est-à-dire qu'en regardant ~/.ssh/authorized_keys, quel est l'équivalent de bert@etherbert pour votre configuration:

ssh-rsa AAAA...ffsII8dSaDF33 bert@etherbet

Je voudrais simplement éditer manuellement les clés .ssh/allowed distantes à des fins de test, en insérant le contenu de id_rsa.pub de l'utilisateur avec lequel vous établissez la connexion.

Assurez-vous que vous venez de l'utilisateur qui a la clé dans le fichier allowed_keys à distance.

7
belacqua

Le répertoire ~/.ssh DOIT être la propriété de l'utilisateur et non de la racine. Alors changez cela et cela fonctionnera.

Pour éviter de devoir taper la phrase secrète de votre clé privée chaque fois que vous utilisez ssh-agent. ssh-add .ssh/id_rsa ajoutera la clé à l'agent, puis l'agent fournira la clé à ssh.

4
guntbert

Outre tous les autres gars qui ont fourni les solutions, ma suggestion supplémentaire est de commencer par vérifier le fichier de journalisation: /var/log/secure, où sshd insère les journaux. Si quelque chose ne va pas, vérifier ce que sshd s'est plaint dans /var/log/secure va rapidement réduire les possibilités problèmes.

2
Meow

C'est une vieille question à laquelle on a déjà répondu, mais si l'utilisateur a le répertoire personnel crypté (à l'aide de ecryptfs ou d'une autre méthode), le démon ssh ne pourra pas voir le fichier ~/.ssh/allowed_keys. Si tel est le cas, suivez la solution indiquée ici .

Cette solution recommande de modifier la configuration de sshd (/ etc/ssh/sshd_config) et de remplacer le fichier AuthorizedKeysFile par /etc/ssh/%u/authorized_keys, puis de copier votre fichier authorised_keys dans/etc/ssh/username/authorised_keys (ainsi que les droits de propriété appropriés pour/etc/ssh/username et requis par sshd).

2
journeyer

Rien n'a fonctionné pour moi. Je ne sais pas pourquoi? J'ai essayé chaque solution.

Premier

ssh-copy-id: n'a pas copié id_rsa & id_rsa.pub

Deuxième

ssh-agent $ Shell

ssh-add -L

ssh-add

ssh-copy-id -i hôte distant

Les deux n'ont pas fonctionné. Je suppose que je suis malchanceux. Quelqu'un disait de changer l'autorisation du dossier .ssh à partir de la racine. Je pensais que ce ne serait pas une meilleure option. Ce que je faisais quand mon cas ci-dessus a échoué. J'ai créé une nouvelle clé sur le serveur et enregistrez cette clé sur github/gitlab. Ce n'est pas non plus une façon cool. Ici, j'ai essayé un remplaçant, j'espère que cela pourra aider quelqu'un.

Tout d'abord, je crée un dossier sur un serveur distant avec l'autorisation de l'utilisateur, qui peut y écrire. Ensuite, je suis les étapes ci-dessous sur ma machine locale

cd ~/.ssh

scp -r * [email protected]. **: path_to_writable_folder_on_remote_server

Et puis je me suis connecté sur le serveur distant, puis

cd path_to_that_folder_where_I_copied_keys

& Ensuite

mv * ~/.ssh

(ouf) Enfin, cela a fonctionné.

0
Vineet