Bonjour,

J'ai mis en place une connexion ssh sans mot de passe (avec ssh-keygen) pour effectuer une sauvegarde tous les jours.
Cela fonctionne entre machines en F7 mais par contre, mon serveur à sauvegarder est en FC6 et il demande tout le temps le mot de passe bien que la clé publique du client lui ait été donnée.
J'ai supprimé ssh sur cette machine et je l'ai réinstallé, mais ça ne marche pas mieux. Qu'est-ce-qui peut bloquer à votre avis ? (ça a eu marché à une époque, avant que je bidouille le client de sauvegarde

sur mon serveur en FC6 :
openssh-server-4.3p2-19.fc6
openssh-clients-4.3p2-19.fc6
openssh-askpass-4.3p2-19.fc6
openssh-4.3p2-19.fc6

sur mon client F7 qui sauvegarde le serveur :
openssh-askpass-4.5p1-6.fc7
openssh-clients-4.5p1-6.fc7
openssh-4.5p1-6.fc7
openssh-server-4.5p1-6.fc7
Vérifies les permissions sur le dossier ~/.ssh et son contenu.
Oui, ssh n'est certainement pas en cause.

le repertoire .ssh doit avoir ses droits à 700
Le fichier authorized_keys qui contient ta clé doit etre à 600

ca sous entend qu'ils appartiennent au bon utilisateur :roll:

Ah .. j'allais oublier .... lance la première connexion ssh à la main, pas par ton script.
Peut etre n'a tu pas encore validé l'empreinte de la machine cible.
le repertoire .ssh doit avoir ses droits à 700
Le fichier authorized_keys qui contient ta clé doit etre à 600
Correction et precision
1. Le repertoire $HOME ne doit etre +w que pour son possesseur. (Sinon un autre utilisateur pourrait faire mv $HOME/.ssh $HOME/.ssh-foo ; mkdir $HOME/.ssh)
2. Le repertoire $HOME/.ssh ne doit etre +w que pour le possesseur du $HOME (Sinon un autre utilisateur pourrait faire rm $HOME/.ssh/authorized_keys ; cp /ma/propre/cle/publique $HOME/.ssh/authorized_keys)
3. Le fichier $HOME/.ssh/authorized_keys ne doit etre +w que pour le posesseur du repertoire auquel il appartient. (Sinon, quelqu'un d'autre pourrait modifier le contenu du fichier authorized_keys).

En revanche, ces fichiers et repertoires peuvent etre parfaitement lisibiles par n'importe qui. L'information qui s'y trouve n'est pas forcement secrete. Logique, n'est-il pas ?
Je vous conseille a tous la page "info coreutils 'Mode Structure'" pour apprendre le role de chaque type de permission UNIX.

Et comme tu l'as dit,
0. le $HOME doit appartenir a l'utilisateur dont tu essayes d'usurper l'identite.
J'ai bien regardé les droits, ça ne vient pas de là je pense, j'ai les droits suffisants pour que root ait accès aux clés.
j'ai les droits suffisants pour que root ait accès aux clés.
Root a acces a tout, quoi que tu fasses.
Je viens de faire un test : j'ai généré une clé rsa pour mon serveur en FC6 : je donne cette clé à une autre machine et j'essaie de me connecter depuis mon serveur FC6 vers cette machine : il me demande à chaque fois le mdp !!! je vois pas ce que j'ai pu bricoler sur le serveur, à part dans les fichier sshd_config et ssh_config, et j'ai tout remis à zéro en réinstallant ssh...
Lors de la création du couple de cles, a tu renseigné un mot de passe pour protéger celles ci ?
Et sinon, peut on consulter ton fichier sshd_config (celui de la machine qui va recevoir la connexion) stp
Non justement pas de passphrase pour eviter de compliquer le truc.
Un collègue me dit que c'est un problème de clés, mais j'ai regénéré des clés toutes neuves et ce plusieurs fois. j'ai refait la manip plusieurs fois en remettant tout bien en ordre.

Ce qui m'inquiete c'est que ce serveur ne peut pas non plus se connecter à une autre machine sans donner de mot de passe. Peut-il y avaoir une incompatibilité entre ssh de FC6 et ssh de F7 ?
Désolé ton message a croisé mon edit du post précédent,

Ton fichier sshd_config du serveur pourra nous en dire plus, je ne pense pas qu'il y ait de différence, ssh est standardisé.

Je me souviens avoir fait quelques modifications, je ne me rappelle plus pour FC6 mais j'ai une FC5 sous la main encore ... peut etre une version différente du protocole ssh... ca m'etonne quand meme.

Que racontent les logs de tentative de connexion sur le serveur ? /var/log/secure
ce que j'ai dans /var/log/secure sur le serveur en FC6 :

Server listening on :: port 22.
error: Bind to port 22 on 0.0.0.0 failed: Address already in use.
Authentication refused: bad ownership or modes for directory /root
Authentication refused: bad ownership or modes for directory /root
Accepted password for root from 192.168.174.224 port 47158 ssh2
pam_unix(sshd:session): session opened for user root by (uid=0)
pam_unix(sshd:session): session closed for user root
Pour établir une connexion ssh par clef privée suivre le protocol ci dessous:
1) générer les clefs privée/publique pour l'utilisateur concerné sur la machine locale
(ex: ssh-keygen -b 1024 -t rsa) 2 fichiers vont être écrit (une clef publique et une clef privée)
et placés dans le repertoire ~/.ssh de l'utilisateur de la machine locale.
2) éditer le fichier dans le répertoire de l'utlilsateur concerné sur la machine distante: ~/.ssh/authorized_keys
y copier le contenu du fichier clef publique généré sur la machine locale.
3) éditer (en root) le fichier /etc/ssh/sshd_config sur la machine distante:
modifier les lignes concernées pour faire apparaitre les infos suivantes (décommenter le cas échéant):
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
4) relancer le serveur sshd sur la machien distante (en root toujours)
cd /etc/init.d
./sshd restart

Et voilà 🙂

Si le PasswordAuthentication reste sur yes le password sera toujours demandé (en plus de l'id par clef de cryptage)
pour permettre les deux type de loggin.

Je vous invite à parcourir se topic plus ancien
http://forums.fedora-fr.org/viewtopic.php?id=8410&words=
Bon .. les logs ont parlé 😉
Il y a un problème avec des droits trop permissifs. Refais un tour de controle user/permissions depuis le repertoire /root
Authentication refused: bad ownership or modes for directory /root
Apres quelques tests .. le "homedir" permet la connexion jusqu'aux droits 755.
Si sshd trouve des droits d'ecriture pour le groupe ou autre .. il n'enclenche pas son processus par clef et demande le mdp.
Ton /root n'a pas été trafiqué un peu ? :-?


Sinon , euhh Slookeur merci mais , je crois qu'il a bien compris la méthode (puisqu'il l'utilise deja) :roll:
Si je peux me permettre de corriger un peu ...

Dans le fichier sshd_config , les parametres commentés sont aussi les parametres par defaut.
Il ne sert a rien d'enlever les commentaires si c'est pour les laisser inchangés.

Quand au parametre "PasswordAuthentication", il n'a aucun effet sur la connexion par clef.
Il stipule simplement si sshd continuera a accepter ou pas les connexions ordinaires sans clef avec mot de passe.
Authentication refused: bad ownership or modes for directory /root
J'ai bien regardé les droits,
Anvil wrote:
Authentication refused: bad ownership or modes for directory /root
J'ai bien regardé les droits,
J'en étais sur aussi... c'est pas bien de ce moquer 😉
Merci pour vos conseils. J'avais à tout hasard changé les droits sur /root/.ssh et les fichiers qu'il contient... mais ce n'était pas très très bien en fait. J'ai mis tout en 600 mais ça ne marche pas mieux...

et ça ? ca ne pourrait pas poser problème ? error: Bind to port 22 on 0.0.0.0 failed: Address already in use

Dans le sshd_config il y a une ligne pour ipv4 qui autorise tous les réseaux et une pour ipv6 qui autorise tous les reseaux, il ne peut pas y avoir conflit ?
comment as-tu fait la copie de la clé publique sur le authorized_keys de la machine distante?
Le mieux est un scp puis un cat clepub >> authorized_keys,
sinon elle est copiée avec des retours à la ligne et ne fonctionne pas.
J'ai copié la clé avec un cat, comme stipulé dans les tutos, j'ai vérifié, pas de terour à la ligne.
pikaraph wrote:et ça ? ca ne pourrait pas poser problème ? error: Bind to port 22 on 0.0.0.0 failed: Address already in use
C'est certainement du au fait que sshd est déjà démarré. -> ps ax | grep ssh
Oui effectivement j'avais essayé pour voir et killé le process qui bloquait... mais ca ne change rien à mon problème.