Je crois qu'il va falloir nous décrire exactement ce que tu fais avec ce que tu tapes et dans quel fichier tu copies quoi. Un compte rendu complet et exhaustif car nous allons être à cour d'idée... dsl
Arf ! j'ai même essayé en mettant la même version de ssh sur le client... pareil, il demande le mdp, il refuse de prendre en compte ma clé.

Ce que je fais :

sur le client (qui doit récupérer des données à sauvegarder) je génère une clé rsa (ssh-keygen -t rsa)
je copie cette clé en faisant depuis le client : cat /root/.ssh/id_rsa.pub | ssh root@serveur 'cat >> .ssh/authorized_keys'
je donne le mdp du serveur et ca copie bien la clé dans le authorized_keys
je tente de me connecter depuis le client au serveur : ssh root@serveur --> et il me demande le mdp à chaque coup !!

j'ai essayé de changer des trucs dans sshd_config sur le serveur, mais rien n'y fait...
Faut rien changer dans la config du serveur ssh, ça marche out-of-the-box

Donne la sortie de la commande "ll -a ~/ssh", ce genre de problème est dans la plus part des cas un soucis de permission.

Sur le serveur fait un tail -f /var/log/secure pour voir ce qui pose problème ou tu sais démarrer le serveur ssh en mode debug pour voir plus finement ce qui pose problème.

/sbin/service sshd stop
/usr/sbin/sshd -d

Edit: décidément, mes doigts et mon cerveau n'était pas bien en forme hier 😉
Salut,

perso j'ai plusieurs serveurs qui fonctionnent sur ce principe certains acceptent le MDP ou la clé et certains seulement la clé.
Je vous donne la configuration du sshd_config d'un serveur qui ne prends QUE les clés : 
Port 22
Protocol 2
ListenAddress 0.0.0.0
HostKey /etc/ssh/ssh_host_rsa_key
SyslogFacility AUTH
LogLevel INFO
PermitRootLogin no
AuthorizedKeysFile %h/.ssh/authorized_keys
IgnoreRhosts yes
RhostsRSAAuthentication no
HostBasedAuthentication no
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
X11Forwarding yes
Compression yes
Subsystem sftp /usr/libexec/openssh/sftp-server
Ce serveur tourne actuellement sous FC6 mais je pense pas qu'il y ai une grosse différence ....

Esperons qu'une comparaison avec le tiens t'aide un peu ...

Pour les accès des clients depuis linux en général les clés sont dans $HOME/.ssh/id_rsa
Et pour les clients windows vive le putty-agent 😃
salut,
s'il te plait, au risque d'insister :roll:

ls -la /root/.ssh
ls -la /root/.ssh
total 60
drwx------ 2 root root 4096 jui 19 10:15 .
drwxrwxrwt 18 root root 4096 jui 19 10:16 ..
-rw------- 1 root root 809 jui 19 15:17 authorized_keys
-rw------- 1 root root 404 jui 19 10:16 authorized_keys2
-rw------- 1 root root 1675 jui 19 16:45 id_rsa
-rw------- 1 root root 401 jui 19 16:45 id_rsa.pub
-rw------- 1 root root 1634 jui 20 09:14 known_hosts
-rw------- 1 root root 24829 jui 17 16:12 secure_old

On a refait un test avec rsync en envoi de données depuis le serveur en FC6 vers les serveurs de sauvegarde, ça marche sans demander de password. Donc finalement on va faire l'inverse de ce qu'on voulait faire, c'est le serveur qui va balancer les données aux sauvegardes.

Merci pour votre aide, je vais partir en vacances serein !
J'oubliais tu sais aussi lancer le client ssh avec le parametre -vv... un truc du genre ssh -vv root@tonserver, de cette façon tu devrais savoir identifier ton soucis... sshd en mode debug et le client en "super verbose".

Bonne vacance
Bonne idée, je n'avais pas vu cette option.

ça me donne : Unspecified GSS failure Minor code may provide more information. No credentials cache found.

Comme ça bugue, il essaie une autre méthode, par mot de passe.

Edit : en mettant sur no ce qui concerne GSS, le message d'erreur n'y est plus, mais ca ne marche toujours pas.
pour la copie de cle, voyez le script ssh-copy-id. Pour les permissions, j'me suis deja attarde la dessus.
Pour le adress already in use, ca veut simplement dire qu'il tourne deja.
Unspecified GSS failure Minor code may provide more information. No credentials cache found.
C'est pas un soucis, ssh essayer différent type d'autentification dans un ordre bien défini (c'est expliqué dans la man page)

Par contre après il devrait tester l'auth par clef public, voilà ce que ça donne ici du coté client:
debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found

debug1: Next authentication method: publickey
debug1: Trying private key: /home/xxx/.ssh/identity
debug1: Offering public key: /home/xxx/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '/home/xxx/.ssh/id_rsa':
Et du coté server:
Jul 20 16:19:08 xxxx sshd[25944]: Postponed publickey for xxxx from xxxxxx port 51455 ssh2
salut ...

bon , ca fait plus de 15 posts qu'on te le dit ... probleme de permissions, les logs on meme dit ou

ton ls -la :
s -la /root/.ssh
total 60
drwx------ 2 root root 4096 jui 19 10:15 .
drwxrwxrwt 18 root root 4096 jui 19 10:16 ..
Tu joues avec le compte root la.
Le $HOME de root est donc /root
Enlève les droits d'ecriture : chmod 755 /root

Et bonnes vacances
Pour peaufiner ,
Il est préférable d'empecher le compte root de se connecter directement ... meme en SSH

sshd_config :
PermitRootLogin no

Refais le travail pour un simple utilisateur et fais des su - ou des sudo pour passer root si c'est vital.

S'il te reste du courage remet un mdp a ta clé privée et essaye avec ssh-agent sur le client 😉
J'avoue volontiers que je ne le fais pas, mais on est jamais à l'abris de se faire piquer sa clef privée ...comme moi au taff avec des comptes root partagés par quelques personnes sur les machines, ca s'appelle une équipe, après ..c'est une histoire de confiance (une autre sorte de clef) :-?
Je suis assez d'accord avec Fanf même si je ne l'applique pas toujours les seules connections ssh que j'utilise pour root sont des connections entre différents serveurs pour des services ou il est difficille de faire autrement ( genre backup de /home ) sinon aucun utilisateur n'a les clés pour se logger en root et je te conseille de faire comme ça

Sinon je pense aussi que c'est un problème de permissions ssh est assez chiant à ce niveau là et quand il sent la moindre faille sur une clé il ne l'utilise pas chmod 755 /root ou carrément chmod 700 /root ( permissions d'un rep home normal )
J'ai voulu etre gentil en lui enlevant juste les droits d'ecriture pour groupe et autre, ca permettra à ssh de fonctionner sans mdp.

Mais tu a raison bien sur Adadov chmod 700 $HOME

Personnellement, je ne donne pas les clefs de ma maison a mon groupe d'amis et encore moins aux inconnus.
Meme s'ils n'auront le droit que de regarder, ouvrir un tiroir ..regarder dedans ... ouvrir mes photos de vacances , et les regarder ...
Tout ca meme sans deplacer quoi que ce soit, écrire sur mon tableau de courses a faire, ou encore casser mes vases

Euhhh, j'ai des vases moi ? <s'égare> ------>[] :roll:
2 mois plus tard
Ca y est ça recommence...
J'ai installé mon nouveau serveur en Fedora7 il y a une semaine environ, j'ai créé une clé ssh que j'ai diffusée à mes serveurs de sauvegarde, j'ai écrit mes commandes dans crontab pour faire du rsync tous les soirs. Ca a marché jusqu'à hier soir où les données ne se sont pas répliquées sur mon serveur de sauvegarde, alors que je n'ai rien touché à la conf...
maintenant je tente la commande à la main et ça me redemande le mdp à chaque coup.

ma commande : rsync -acuHDv --del /home/* serveur-save:/sav1/home

Je viens de recréer un jeude clés ssh, j'ai refait la manip d'install des clé sur les serveurs de sauvegarde, mais ca me redemande toujours le mdp...ca me saoule !!