voilou, j'aimerais ne plus tapé de mot de passe sur mon ssh client pour me faire des script.
 
Pour cela sur mon client, j'ai généré un couple de clé privé/public dans le fichier toto
 
ssh-keygen -t dsa -f toto
 
génération de la clé privé : toto  
et public :toto.pub  
 
la clé privé, je la garde bien au chaud et la clé public je dois la copié sur le serveur pour qu'il genere sa propre clé privé  
 
mais seulement voila on me dit rajouté la clé public dans le fichier $HOME/.ssh/authorized_keys en faisant cat toto.pub >> authorized_keys  
 
mais je n'ai pas de fichiers authorized_keys, je n'ai que le fichier root/.ssh/authorized_keys/ssh_known_hosts
 
Je pense que c'est sensiblement la meme chose. Que dois je faire apres la generations des clés privé/public.  
 
et sinon dans le home de mon user normal :

 
Que dois je faire ?
Ou dois je copié ma clé public ?
ce n'est pas grave si authorized_keys n'existe pas, je fais quand meme : at toto.pub >> authorized_keys ?
 
 
 

le plus simple est de te servir de ssh-copy-id .

je n'ai pas cette commande magic.  
lorsque je regarde dans le man ssh il n'en parle pas du tout
je suis sous fedora core 2

hum étrange elle doit etre normalement fourni avec ssh .
enfin elle l'est sous debian/mandrake .
tu as bien installé le client ssh ?
sinon pour répondre a ta question tu mets effectivement le toto.pub dans le fichier .ssh/authorized_keys

oui j'ai bien installe le ssh, je suis meme en train de faire du vnc over ssh
 
 
j'ai compris le systeme, y a meme un super tuto :-)
http://polywww.in2p3.fr/grpinfo/doc/ssf/ssf-rsa.html

lorsque l'on utilise le systeme de clé public/privé, faut il absolument que le login distant soit identique au local.
 
Je m'explique. J'ai un user toto sur la machine distante et sur la machine locale, cette utilisateur n'existe pas. Est ce que je dois le creer ?  
 
 
 
Je pense que non mais par contre une fois les clé privé/public généré avec l'utilisateur titi et une fois que la clé public est copié dans /home/titi/.ssh/authorized_keys, je ne pourrais me connecter qu'avec titi mais pas avec les autres users de mon poste local (à moins de copié la clé privé de titi sur les home des autres users)
 
 
Donc ma questions faut il que ce soit le meme user local et distant ?
Si ce n'est pas obligé, seul l'utilisateur qui a executé ssh-keygen peut se connecter sur sshd ?

Ce n'est pas obligé, tu peux être logger en weed sur ta machine local et te connecter sous un autre login sur une machine distante à partir du moment où tu as les droits pour t'y connecter.
Voir ssh -l $LOGIN $MACHINE
Configurable dans $HOME/.ssh/config (Host $MACHINE user $LOGIN)
 
Pour ne plus avoir à taper sa clé/passphrase, il faut utiliser ssh-agent.

Ca c'est ok, sois sûr de ne pas taper de passphrase à cette étape.
 

1 - Pas d'auth sans password pour root, c'est mal(c) : fais ça avec un login user normal.
2 - authorized_keys est normalement un fichier, efface donc ce répertoire et fais un cat de ta clé publique vers ~/.ssh/authorized_keys
 
http://ernest.cheska.net/index.php [...] loadastuce pour plus d'infos.

 
arf j'ai fais exactement ce que j'ai dis precedemment mais cela ne prend pas en compte ma clé, on me demande toujours le pass et non pas le passphrase.
 
Je n'ai pas mi le fichier config. Je n'ai pas très bien compris ce fichier de conf. Faut il que je le mette sur le serveur ?  ou sur la machine cliente ?
 
Par exemple, mon client  
nom d'hote : perso
login : weed
 
mon serveur :
nom d'hoste : firewall
login : toto
 
Dans mon exemple, que faudrait il que je mette ? (le nom de fichier de la clé privé c'est id_rsa et la clé public id_rsa.pub)

sisisi, on peut taper un passphrase, et apres on fais tourner user-agent et on ajoute ces clé avec user-add.
 
 

Pourquoi dis tu ca ? tu me dis ca a propos de mon serveur et ou de mon client ?
 

yep, c'est fait

tu as correctement configuré le serveur aussi j'espere ?
les droits sont corrects au niveau du fichier authorized_keys ?

yep, j'ai créé a partir de l'utilisateur normal sur le serveur :
-rw-r--r--  1 trant trant 600 Feb 20 12:15 authorized_keys
 
pour info voici mon /etc/ssh/sshd_config :

ON NE SE LOGUE PAS EN ROOOOOOOOOOOOOOOOOOOOOOOOOOOOTTTT !!!!!

je sais pas ou tu as vu ca. Toujours est il que tu as raison, je me logué sur la machine distante mais maintenant ce n'est plus le cas. Enfin bon cela resoud pas mon problème.
 
J'attends la reponse de Glor pour ce qui est du fichier config. C'est peut etre pour ca que les clés ne sont prise en compte.
 

Non, la clé machin@machinelocale peut servir à se loguer en tant que toto@machinedistante. Si tu veux que plusieurs locaux puissent le faire, il suffit de mettre plusieurs clés dans le .ssh/authorized_keys de toto@machinedistante.

Décommentes RSAAuthentification, ça devrait marcher pour ta passphrase.
 
Pour le $/.ssh/config, ce sont tes options personnelles. C'est le côté pratique qui est pas mal, pour toi:
 
cat ~/.ssh/config
Host perso
  User weed
Host firewall
  User toto
 
Ca permettra de faire des ssh firewall et ssh perso de façon transparente au niveau de l'utilisateur.
Beaucoup d'options sont disponibles pour te faciliter la vie

Bon je vais de verifier id_dsa.pub sur le client = authorized_keys
 
[weed@perso weed]$ cat .ssh/id_dsa.pub = [toto@firewall toto]$ cat .ssh/authorized_keys
 
dans mon sshd_config de mon client ssh et de mon serveur sshd, j'ai decommenter la ligne  
RSAAuthentication yes
 
mais malgré cela, on me propose toujours d'échangé la clé public :  

 
J'ai decommenté les lignes dans sshd_config :

car elle me semblait en rapport au clé public/privé.
 
Pourquoi mon client ne me propose t'il pas de taper la passphrase au lieu du mot de passe habituel ?  
 
J'ai loupé quelques chose ?
 
PS : Je n'ai pas encore fais le fichier config car selon glor il est optionnel
PS2 : je redemarre bien sur sshd pour prendre en compte les parametres

Question bête: Tu as bien fais ça sur toutes les machines sur lesquels tu te connectes?

euhh je ne te sais pas la. Tu parles pour quel fichier sinon mon fichier ssh_config de mon ordi pers (client)
 

[quote=639364,0,13,23108]ON NE SE LOGUE PAS EN ROOOOOOOOOOOOOOOOOOOOOOOOOOOOTTTT !!!!![/quote]
 
Et pourquoi donc ?
Le principal intérêt que je vois à restreindre les logins root (distants ou non) est de pouvoir savoir quel utilisateur a fait un su (et à quel moment), mais à part ça cela ne pose aucun problème de sécurité particulier.
 
Même à l'époque de telnet cet argument ne tenait pas debout, puisqu'un login en utilisateur + un su par la suite n'est de toutes façons pas plus sécurisé qu'un login root direct via une liaison non chiffrée.

et voici mon nouveau sshd du firewall :
 

Tu peux en profiter pour mettre ListenAddress sur celle qui est affectée à ton interface interne.

humm ouia pas mal du fait que l'on se connecte sur le firewall que du LAN ou du net et non pas de la DMZ, je pourrais specifier en effet

sshd_config:
PasswordAuthentication no
RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication yes
StrictModes yes
SyslogFacility AUTH
 
ssh_config:
Host *
PasswordAuthentication no
RhostsAuthentication no
RhostsRSAAuthentication  yes
RSAAuthentication yes
 
Ce sont les seules choses un peu particulière que je vois.
 
Pour le login root, généralement, on le déconseille plus par principe, en gros, éviter d'utiliser une machine en root si on en a pas besoin. (Il peut y avoir des raisons de DOS ou de brute force..)