[EDIT] la solution. Merci à tous pour votre aide et surtout Bigon, af_airone, syl94, IOky.
 
Pour se loger en ssh avec une clef :
 
la procédure indiquée un peu partout
1 Générer les clefs : ssh-keygen -t rsa
2 copier la clef sur le serveur avec ssh-copy-id
Normalement jusque là les permissions se mettent correctement par défaut.
 
Vérifier que :
 
1 le home sur la machine distante est sur 0700 pour les permissions.
2 dans sshd_config : l'utilisateur de la machine distante est autorisé à se loger en ssh.
3 sshd_config : PubkeyAuthentication est sur yes.
 
voilà, on pourrait rajouter plein de choses, mais normallement le reste des options sont correctes par défaut.
 
à consulter (parmi d'autres)
http://lea-linux.org/reseau/secu/ssh.html
http://lea-linux.org/trucs/item.168.html
http://www.jdmz.net/ssh/
http://www.europe.redhat.com/docum [...] ients.php3
http://www.linux-france.org/prj/ed [...] x2500.html
http://www.openssh.com/faq.html (où d'ailleurs ils disent bien ce que Bigon m'a dit sur les permissions).  
 
[premier message]
salut,
j'essaye de mettre en place un clef ssh pour acceder directement à mon serveur sans avoir à taper de mot de passe. J'ai trouvé plein de pages qui explique simplement comment faire.
 
J'ai généré une clef dont j'ai ensuite copiée la partie publique dans les authorized_keys du compte sur lequel je veux me connecter.
Mais cela ne marche pas, quand j'essaye de me logger en ssh le serveur me demande toujours le mot de passe.
je ne sais pas dans quelle direction chercher l'erreur car j'ai déjà vérifié que :
- il s'agit bien du fichier authorized_keys et non authorized_keys2.
- j'ai vérifié les permissions des clefs et de authorized_keys en tentant même rapidement des permissions totales.
- sshd autorise l'utilisation des clefs ssh.
 
si vous avez des idées.

est ce que tu utilises comme client putty?

t'as peut-être des versions trop différentes de ssh sur tes deux bécanes.

 
 
ui c est ce que je pensais voir pire un client ssh sous windows putty  

indiques tu quelque part la clé à utiliser quand tu te connectes sur ton serveur ?

Plus de précisions :
je me connecte à partir d'une console sous mandriva, donc j'utilise pas putty (ni windows donc) et le serveur est sous debian. openssh 3.9.
IOky > j'indique la clef à utiliser en tapant la commande et de toute façon il me semblait qu'il suffisait qu'elle soit dans les clefs autorisées sur le serveur. A quoi penses-tu ?

Pour les versions de ssh c'est étrange, j'utilise openssh sous mandriva mais il n'est pas installé sur le serveur et c'est étrange car quand je fais apt-get install openssh il ne trouve pas de paquet !
D'autant plus bizarre que je viens de revérifier les sources et tout est là... hum. Donc sur le serveur j'ai ssh 1.3 et openssh 3.9 sur mon PC

 
Sous debian, pour trouver un paquet :

Pour openssh, les paquets sont donc openssh-client et openssh-server mais ils ne sont disponibles que dans unstable :
http://packages.debian.org/cgi-bin [...] lla-search
 
Mais en fait, je pense pas que le problème vienne des versions différentes de ssh si le client et le serveur utilisent le même protocole (ssh 1 ou 2). Et le serveur ssh (ssh 1.3 de ton serveur) comme le client (openssh 3.9 de ta mandriva) peuvent utiliser les versions 1 et 2 du protocole. C'est la raison pour laquelle tu peux te connecter par mot de passe de ton pc à ton serveur (et inversemment à priori). Ton problème vient peut-être de la configuration du client ou du serveur (je sais, ça t'avance pas beaucoup....désolé)

commence par faire un ssh -v et regarde le debug au fur et a mesure, tu sera tt de suite fixé si c'est un probleme de version
 
Sinon, tu peux utiliser ssh-copy-id (ssh-copy-id -i ~/.ssh/id_rsa.pub user@machine)

 
je vais essayer ssh -v, mais tu peux expliquer ce que ça fait ssh-copy-id...

j'ai eu le meme truc, c'étais un problème de permissions... Les perm du dossier .ssh de la machine distante doivent etre 600 (read-write uniquement pour le owner)

 
précise stp : quel dossier ssh exactement ?

 
c'est ce que je me dis aussi merci quand même   pour les infos sur openssh

Les permission du dossier ou se trouve authorized_keys

ok merci et quelles permissions tu donnes au fichier lui-même, et aux clefs sur le PC (pas le serveur) ?

euh moi j'ai ca

ce truc commence à m'énerver...
 
Voilà exactement comment j'ai fais :
 
- je génère une clef : "ssh-keygen -t rsa" (j'ai essayé aussi avec une clef dsa et une clef pour rsync "ssh-keygen -t dsa -b 2048 -f /home/thisuser/cron/thishost-rsync-key"
 
- je n'ai pas mis de passphrase pour commencer pour voir si déjà comme cela ça marche. En théorie pas besoin de passphrase pour que la clef fonctionne.
 
- je la copie sur le serveur : scp /home/jeremie/.ssh/id_rsa.pub bibi@gandalf.tuxhome/jeremie/.ssh/
 
- j'inscris la clef dans les clefs autorisées : cat id-rsa.pub >> authorized_keys. J'ai vérifié dans sshd_config que c'était bien autorized_keys et non authorized_keys2.
 
- je chmod 0600 le répertoire .ssh sur le serveur, comme le propose bigon (j'ai aussi essayé en 0700).  
 
- les permissions sur mon PC sont réglées exactement comme celles qu'indique Bigon au-dessus.
 
- j'ai vérifié dans sshd_config que PubkeyAuthentication est sur yes.
 
- j'ai vérifié naturellement que j'ai le droit de me connecter en ssh sur ce serveur. Ok bon si c'était pas le cas je serais pas arrivé jusque là, mais ça fait toujours du bien de vérifier.
 
- j'ai regardé les tutos suivants : http://lea-linux.org/reseau/secu/ssh.html
http://lea-linux.org/trucs/item.168.html
http://www.jdmz.net/ssh/
http://www.europe.redhat.com/docum [...] ients.php3
http://www.linux-france.org/prj/ed [...] x2500.html
 
en sautant les étapes sur le ssh-agent, par exemple, pour commencer avec une gestion simple des clefs et compléter ensuite.
Si vous avez des idées de là où j'ai pu merder ou des paramètres que je n'ai pas réglé ou regarder, merci de m'en faire part.

Voilà le debug :  
 
[jeremie@localhost ~]$ ssh -v jeremie@xxx.org
OpenSSH_3.9p1, OpenSSL 0.9.7e 25 Oct 2004
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to xxx.org [xx.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/jeremie/.ssh/identity type -1
debug1: identity file /home/jeremie/.ssh/id_rsa type 1
debug1: identity file /home/jeremie/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.8.1p1 Debian-8.sarge.4
debug1: match: OpenSSH_3.8.1p1 Debian-8.sarge.4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'xxx.org' is known and matches the RSA host key.
debug1: Found key in /home/jeremie/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/jeremie/.ssh/identity
debug1: Offering public key: /home/jeremie/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Offering public key: /home/jeremie/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Password:
 
La clef est donc reconnue et semble même marcher, mais pourquoi continue t-il avec le password ?
mystère...

shaddy : t'as considéré ce que j'ai dit avant? A savoir d'uniformiser tes versions de ssh sur le serveur et sur le client?

 
ça fait quoi si on veut se connecter au server utilisant une clef à l'aide de puTTy ?
 
J'ai jamais testé avec putty, mais on sait jamais si je suis amene à le faire d'une station windows ça serait bien que je le sache.

 
oui, mais comme dit plus haut je ne suis pas sûr que cela soit si important. Regarde le debug,  
OpenSSH_3.9p1, OpenSSL 0.9.7e 25 Oct 2004
match: OpenSSH_3.8.1p1 Debian-8.sarge.4 pat OpenSSH*
 
les deux semblent bien utiliser le protocole 2 donc je vois pas le problème.
Et puis le serveur est sous sarge et je n'ai pas envie de le mettre sous unstable.
Qu'est-ce qui te fait dire qu'uniformiser les versions de ssh serait ici utile ?
 

fais une recherche sur le forum (dans OSA), j'ai vu pas mal de sujet sur putty et un serveur linux.

les clés générés par putty si tu l as copies par un scp  
ben ca lui rajoute des retour chariots docn au final  
ce que tu as copié dans authorized keys ne sera plus ta clé  
mais ta clé plus des retours chariots qui sera pas reconnu quand tu tenteras de te logger.
 
pour copier une clé putty faut  copier ta clé publique dans le presse papier
puis coller dans authorized_keys donc tu edites avec vi et hop tu copie le contenu du press papier
 
c est pas compliqué quand tu le sais

 
comme dit ci-dessus ("ssh-keygen -t rsa" ) : je n'ai pas généré ma clef par putty !!! je n'utilise pas putty !!!
Mon PC est sous mandriva et le serveur sous debian !!
scp est un programme qui est spécifiquement conçu pour copier des fichiers au travers d'un réseau en utilisant ssh de façon sécurisée ! Il me semble donc bien mieux indiqué qu'un copié collé.
 
 
 
 
 
 

même si je précise explicitement la clef à utiliser ça na marche pas.
Par exemple :  
 
[jeremie@localhost ~]$ rsync -avz -e "ssh -iv /home/jeremie/.ssh/id_rsa" jeremie@xxx.orghome/jeremie/ /home/jeremie/Documents
password :  
 
est-ce que quelqu'un sait exactement comment il faut configurer sshd_config pour que cela marche ?
En gros montrez moi, siouplé, votre sshd_config si vous faites marcher des clefs ssh.

 
extrait du man ssh-copy-id
 

 
Est ce que tu as essayé la commande ? Si tu utilise 2 distributions récentes, tu auras forcement SSH v2, ou alors, change de distrib (Debian!!!!   )

 
C'est vrai tu as raison j'avais oublié d'essayer cette commande. pour man ssh-copy-id en fait je l'avais fait...
Effectivement les 2 utilisent ssh v2.  
Mon serveur est déjà sous Debian
 
VOilà le résultat de la commande :
 
[jeremie@localhost ~]$ ssh-copy-id -i /home/jeremie/.ssh/id_rsa.pub eremie@xxx.org
29
Password:
bash: line 1: .ssh/authorized_keys: Permission denied
chmod: cannot access `.ssh/authorized_keys': Permission denied
Now try logging into the machine, with "ssh 'jeremie@xxx.org'", and check in:
 
  .ssh/authorized_keys
 
to make sure we haven't added extra keys that you weren't expecting.
 
c'est probablement dû au fait que le dossier /.ssh est en permissions 0600, permissions normallement requises. Je vzis modifier ça et le refaire.

le dossier .ssh doit etre en 700 faut bien pouvoir le traverser non
edit: les permissions qui vont bien

ouais je sais, c'est Bigon qui m'avait dit d'essayer en 0600.
De toute façon, c'est fait, j'ai modifié cela et utilisé ssh-copy-id.
Mais au final, c'est juste une commande plus rapide pour ajouter une clef. Et mon problème n'est toujours pas résolu.
Qu'est-ce que tu as toi dans ton sshd_config ?

euh   c'était 700 en effet...
 
 
 
Et si on recommence tout? (oui j'aime la manière radicale)
Tu efface les dossier .ssh sur les 2 machine tu regénères des clefs et tu utilises ssh-copy-id pour envoyer le tout...
 
Dans le fichier de config du server ssh sur le quel je me connecte j'ai ca

Ok pour la manière radicale, j'aime bien aussi parfois, ça aide à clarifier.
 
chez toi :
 
#AuthorizedKeysFile     %h/.ssh/authorized_keys
pourquoi cette ligne là est-elle commentée ? chez moi elle ne l'est pas.
 
sinon j'ai pareil. Mais pour la suite :
chez moi :
 
# rhosts authentication should not be used
#RhostsAuthentication yes
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no peut-être que cette ligne devrait être sur yes
# similar for protocol version 2
HostbasedAuthentication no peut-être que cette ligne devrait être sur yes
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

Je viens d'avoir un flash... c'est quoi les permission de ta home? essaye en la mettant à 700 (en tout cas pas en write pour le groupe et les autres)
 
edit: ta home sur la machine distante

 
chmod 0700 /home/jeremie/
 
 ou
 
chmod -R 0700 /home/jeremie/
 
qu'est-ce que ça peut changer ?

mouais, au pire tu renomme ton répertoire .ssh en .ssh_old par exemple et tu reesaye une connexion sans changer les droits sur tes fichiers

en fait je voulais dire : qu'est ce que ça peut changer de mettre les droits à 0700 sur mon home ?

le 1e chmod 0700 /home/jeremie/
 
 

 
Le truc c'est que si qq1 a les droit d'ecriture sur ta home il peut remplacer ton dossier .ssh et mettre sa clef dedant et il va alors pouvoir se logger
 
Je viens de tester si je met les perm de ma home a 777 il ne veut plus de la clef

J'avais le même problème que toi... et j'ai essayé ça :
 
http://forum.hardware.fr/hardwaref [...] 8691-1.htm
 
ça marche à présent ! En résumé, si le SSH est en protocole 2, alors il faut que ton fichier authorized_keys s'appelle authorized_keys2 :
 
/etc/ssh/sshd_config :
 

 
après, je n'ai pas touché aux droits du fichier... Si tu as d'autres questions sur ce que j'ai fait, n'hésite pas.

 
 
je répondais à vomegaz qui demandait quelle etait le problem avec putty dsl pour la confusion.
cordialement

 
En fait ça ne marche pas   ça marche pour root mais pas pour un utilisateur...
 
Pour info j'ai Fedora 4, si quelqu'un parvient à nous donner une solution...  

 
 
tout à fait d accord sur les anciennes version d openssh les clés rsa 2 se situaient dans authorized_keys2
donc ca coute rien dessayer.
en fait quand tu fais un ssh-keygen -t rsa par défaut ca te génère une paire de clé rsa2
et pas rsa1 comme on pourrait le penser
dans les nouvelles version d openssh  y a plus de problem on a plsu a dissocier dans authorized_keys ou authorized_keys2 mais avant c etait le cas
donc essaie pour voir dans authorized_keys2 en mettant les droits que nos camarades ont conseillé
et croise les doigts