ssh-copy-id ne fonctionne pas

J'essaie de configurer une connexion SSH sans mot de passe sur CentOS 5.4:

1. J'ai généré la clé publique RSA sur le client.
2. ssh-copy-id du client au serveur.
3. ~ / .Ssh / authorized_keys vérifié contient la clé client.

Le client a toujours demandé un mot de passe. Qu'est-ce que j'ai raté?

Merci.

EDIT: vérifié ssh_config et les autorisations comme conseillé. Voici les informations de débogage du client:

debug2: key: /home/saguna/.ssh/identity ((nil))
debug2: key: /home/saguna/.ssh/id_rsa (0x2b31921be9a0)
debug2: key: /home/saguna/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug3: Trying to reverse map address 192.168.1.75.
debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/saguna/.ssh/identity
debug3: no such identity: /home/saguna/.ssh/identity
debug1: Offering public key: /home/saguna/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Trying private key: /home/saguna/.ssh/id_dsa
debug3: no such identity: /home/saguna/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
[email protected]'s password: 

9/10 fois c'est parce que ~ / .ssh / authorized_keys n'est pas au bon mode.

chmod 600 ~/.ssh/authorized_keys

Archivez / etc / ssh / sshd_config pour permettre l'authentification avec une clé. Vous devriez avoir quelque chose comme ça, et assurez-vous que les lignes ne sont pas commentées:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

PS: n'oubliez pas de redémarrer sshd après avoir modifié le fichier (/etc/init.d/sshd restart)

J'ai constaté qu'avec mon système, le problème était que le répertoire utilisateur (/ home / nom d'utilisateur) était équipé du mauvais ensemble d'autorisations. C'était drwxr-x-w-et cela devait être drwxr-xr-x(avec une autorisation d'écriture uniquement pour le propriétaire). La solution était d'utiliser chmod:

sudo chmod 0755 /home/username

Je ne suis pas un expert ici mais j'ai rencontré un tel problème aussi, voici mes deux cents en plus de toutes les autres suggestions.

Copie parfois ssh-copy-idla mauvaise clé sur le serveur distant (peut se produire si vous avez plusieurs clés et / ou utilisez des noms non par défaut pour les fichiers de clés) ou votre agent d'authentification est mal configuré.

Voici une citation tirée des pages de manuel :

Si l'option -i est donnée, le fichier d'identité (par défaut ~ / .ssh / id_rsa.pub) est utilisé, qu'il y ait ou non des clés dans votre agent ssh. Sinon, si ceci: ssh-add -L fournit une sortie, il l'utilise de préférence au fichier d'identité.

Donc, fondamentalement, vous voulez vérifier que:

• Votre agent d'authentification système (généralement ssh-agent) voit les clés que vous avez l'intention d'utiliser (vérifier la ssh-add -Lsortie)
  • Si vous ne voyez pas la clé souhaitée, ajoutez-la à l'aide de ssh-add
• Ils ont ssh-copy-idcopié la même clé sur la machine distante (connectez-vous simplement au serveur distant en utilisant un mot de passe et vérifiez le contenu de ~/.ssh/authorized_keys)
  • Si vous ne voyez pas la clé souhaitée sur le serveur distant, vous pouvez implicitement dire ssh-copy-idquelle clé copier:ssh-copy-id -i ~/.ssh/some_public_key

J'espère que cela pourra aider.

Le problème le plus courant est les autorisations non valides côté serveur. Vérifiez qu'aucun de votre répertoire personnel, ~/.sshet ~/.ssh/authorized_keyssont modifiables par tout le monde , mais vous (en particulier ils ne doivent pas être un groupe inscriptible).

Si ce n'est pas le problème, exécutez ssh -vvv serveret regardez la vue du client sur la conversation. Vérifiez notamment que le client essaie la clé avec le serveur.

En plus de tout ce qui précède, on peut toujours vérifier le fichier journal sshd:

/var/log/auth.log

J'ai essayé les autres correctifs mais j'ai constaté que je devais changer le répertoire personnel pour qu'il ne soit pas accessible en écriture pour les autres. Le répertoire personnel était 777. Je l'ai changé en 755 et cela a fonctionné.

dans mon cas / etc / ssh / sshd_config contenait le paramètre suivant:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys2

Mais ssh-copy-id a créé un fichier avec le nom authorized_keys, j'ai donc dû modifier l'entrée au nouveau nom. plus d'informations sur deprecated authorized_keys2

En complément de la réponse d'Omer Dagan pour le nouveau CentOS 7, utilisez:

journalctl -f -u sshd

pour regarder les journaux sshd sur le serveur.

Le problème était que j'avais RSAAuthentication désactivé dans / etc / ssh / ssh_config