Discussion :

[Noizet]

Bonjour,

J'ai génère une paire de clé afin de ne plus devoir rentrer le mot de passe à chaque fois que je me connecte sur le serveur.

J'ai suivie l'exemple montré sur : http://lipforge.ens-lyon.fr/www/weba...e/cle-ssh.html

Le problème est que le serveur me met l'erreur suivant que je veux me connecter pour la première fois :the authenticity of host 'monServeur.ch' can't be established. RSA key fingerprint is.....

Et ensuite, il me redemande à chaque fois le password, qqun aurait une idée de la source du problème ?

merci de votre aide!

[dtrosset]

Bonjour,

Alors l'erreur "the authenticity of host 'monServeur.ch' can't be established." je ne vois pas trop.

Par contre, il faut aussi bien mettre les bonnes permissions aux repertoires et fichiers afin que le login soit automatique : ~/.ssh doit être drwx------ et ~/.ssh/authorized_keys doit être -rw-------.

Didier

[Noizet]

Ils ont ces droits, mais ça ne fonctionne toujours pas :-(

[jmelyn]

Bonjour,

C'est un peu compliqué à tout expliquer comme ça. En gros, l'authentification SSH se fait en deux étapes: D'abord il faut que la machine cliente soit reconnue et ensuite que l'utilisateur soit reconnu.

Pour la première étape, il est nécessaire de prendre la clé de la machine cliente et de la donner au serveur. Il y a 3 types de clés: RSA1, RSA et DSA. À voir le message, il faut prendre la clé publique RSA: /etc/ssh/ssh_host_rsa_key.pub et la mettre à la fin du fichier /etc/ssh/ssh_known_hosts du serveur.

Pour la seconde étape, il faut faire la même chose mais avec la clé publique de l'utilisateur: clé sur la machine cliente: ~/.ssh/id_rsa.pub si on prend la clé RSA et la copier dans le répertoire utilisateur (ça peut être un utilisateur différent) de la machine serveur: ~/.ssh/authorized_keys.

Si ça ne marche toujours pas, il faudra vérifier les configs du client et du serveur...

PS: le répertoire ~/.ssh doit avoir les droits: rwx------ et le bon owner: l'utilisateur. Par contre, authorized_keys comme toutes les clés publiques peuvent être lisibles par tous. Ce sont les clés privées (sans le .pub) qui doivent être rwx------.

[mess-mate]

Jmelyn a très bien expliqué le fonctionnement.
Mais j'ajouterai:
- il faut toujours donner le mot de passe, allons c'est une connexion sécurisée.
- la première fois que tu te connecte il y a en effet un message venant de ta machine qui t'avertis et demande si tu veux continuer; tu répond tout simplement oui ou yes.

Regarde maintenant dans ta ./ssh, tu y trouve:know_hosts et tes cléfs *rsa et *rsa.pub.

Tu as peut-être déjà fait des manips qu'il ne fallait pas. Le plus simple dans ton cas est de supprimer toutes les lignes se trouvant dans ta ./ss/know_hosts.

Tu te reconnecte maintenant à ton autre machine et tu répond oui et ensuite tu entre ton mot de passe lorsqu'il te le demandera.

Si ça marche pas c'est tu as fait trop de choses qu'il ne fallait pas.
Seul moyen rapide dans ce cas est de déinstaller et purger openssh et réinstaller openssh. Il te demandera ce qu'il faut et tu répond oui.
N'oublis pas non plus de supprimer ta ./ssh avant la réinstall.
Voilà

[jmelyn]

@ mess-mate:

- il faut toujours donner le mot de passe, allons c'est une connexion sécurisée.

Heureusement que non! SSH peut fonctionner avec mot de passe ou clés, c'est dans la config que l'on décide (/etc/ssh/ssh_config et /etc/ssh/sshd_config). Comme exemple personnel au boulot, lorsque je suis connecté avec mon user sur une machine, je peux me connecter sur n'importe quelle autre machine comme user root sans mot de passe .

- la première fois que tu te connecte il y a en effet un message venant de ta machine qui t'avertis et demande si tu veux continuer; tu répond tout simplement oui ou yes.

C'est pareil: heureusement que non! Ce cas survient si le fichier /etc/ssh/ssh_known_hosts n'est pas à jour.

Enfin, il est possible de regénérer les clés de façon propre (man ssh-keygen). C'est faisable, j'ai régulièrement testé pour le partage de clés.

[Noizet]

Merci de vos réponses !
Alors, j'ai utilisé ssh-keygen pour générer mes clés et j'ai également répondu yes au message qui apparait quand je me connecte la première fois! Mais ça ne fonctionne toujours pas, je dois quand même à chaque fois remettre le mot de passe.

Pour refaire fonctionner, je dois déinstaller et purger openssh sur le serveur ou la machine locale ? Que veux-tu dire par purger ?

Encore une question, mes clés sur la machine local sont enregistré dans le dossier admin (dossier choisi par ssh-keygen) est-ce que c'est normal ou est-ce que je dois les mettre dans un dossier particulier

[jmelyn]

Comme cela a été écrit, les clés user doivent être dans le répertoire ~/.ssh. Si c'est une clé RSA (créée par la commande: ssh-keygen -t rsa), les deux fichiers doivent s'appeler id_rsa et id_rsa.pub. Si les fichiers ne sont pas bien placés, ça ne marchera pas! Et pareil du côté serveur: faire clé_client.pub >> ~/.ssh/authorized_keys, en supposant que cle_client est la clé publique générée sur le client puis transférée sur le serveur.

Pour voir le problème lors de la connexion ssh, tu peux faire: ssh -vvv serveur. Et tu postes la sortie ici.

[mess-mate]

@ mess-mate:

- il faut toujours donner le mot de passe, allons c'est une connexion sécurisée.

Heureusement que non! SSH peut fonctionner avec mot de passe ou clés, c'est dans la config que l'on décide (/etc/ssh/ssh_config et /etc/ssh/sshd_config). Comme exemple personnel au boulot, lorsque je suis connecté avec mon user sur une machine, je peux me connecter sur n'importe quelle autre machine comme user root sans mot de passe .

Se connecter en tant que root ???
Se serait pas chez moi en tout cas.
Bonjour la sécurité !!

On se logge en tant que user et si on a les droits sur cette machine en tant que root, ensuite on fait un 'su' et on est parti en tant que root.

Pour les clefs:
comme déjà dit et jemelyn il y a 2 clefs générés lors de l'installation de openssh, la privé et la pub.
Maintenant, quand on se logge à une machine distante une clef ( je l'appelle comme ça) est généré également lorsque tu l'as autorisé. Cette dernière se trouve dans ./ssh/know_hosts. Le mot le dit par lui-même, host connu.

Il faudra donc de cette façon toujours donner son mot de passe vu que tu y a un compte.
Maintenant ceux qui ne veulent pas c'est leur/votre affaire.

[jmelyn]

Se connecter en tant que root ???
Se serait pas chez moi en tout cas.
Bonjour la sécurité !!

Ma clé publique RSA se trouve sur toutes les machines (plus de 400) dans le répertoire /root/.ssh/authorized_keys. De ce côté-là, aucun problème de sécurité. Ma clé privée se trouve sur un serveur AFS dont la sécurité est gérée par Kerberos 5. De ce côté-là, pas de problème non plus. Il reste que je ne dois pas rester logué lorsque je quitte un ordi. C'est ce que je fais. Donc niveau sécurité, y'a pas de blème. De ma console, il me suffit de taper "ssh root@machine" pour me retrouver une fraction de seconde plus tard root sur ladite machine. Comme c'est une grosse partie de mon travail, ça m'évite de taper le mot de passe root toutes les minutes. Cool...

Pour ce qui est des clés ordi, je ne me fie pas à ce qu'il y a dans ~/.ssh/known_hosts: En fait, je vire régulierement ce fichier. Par contre, c'est dans /etc/ssh/ssh_known_hosts que je tiens à jour la liste des clés ordi. Pourquoi? Parce que de cette manière, tous les utilisateurs profiteront des clés; autrement dit, plus personne n'aura de problème chaque fois qu'on ré-installe une machine (il faut alors lancer la commande ssh-keygen -R machine pour supprimer la clé périmée, puis taper 'yes' au premier ssh). Et surtout certains programmes utilisent directement ssh mais ne sont pas capables de lire la question et de répondre. Faut que ça marche du premier coup!

[mess-mate]

On a des divergences de vue là.
Je maintiens ce que j'ai dit et à chacun ses opinions.
On oublie très souvent ce qui se ballade sur le fil.
Mais j'ai l'impression qu'on dépasse un peu le cadre de cette discussion = la question de Noizet à laquelle tu as répondu et où j'ai fait une mise en garde.

[jmelyn]

C'est vrai que ça dépasse le sujet initial. Mais lorsque les arguments sont clairs et que cela permet d'apporter des lumières aux autres lecteurs, inutile de se priver, n'est-ce pas?

En ce qui concerne les arguments pour les clés SSH, voici ce que je peux dire:
* La clé publique ne risque pas grand-chose puisqu'elle est publique.
* La clé privée est particulièrement sensible et ne doit jamais être divulguée. Si la home-dir est sur NFS (sauf NFSv4), la sécurité n'est pas assurée. Kerberos, qui permet d'authentifier de manière sure les utilisateurs, est utilisé dans NFSv4 et AFS. Si la home-dir est locale, il faut voir qui sont les admins (qui a le mot de passe root, qui est sudoer). L'accès à la home-dir peut aussi se faire directement, à midi ou la nuit si l'utilisateur ne se délogue pas!
* Il vaut mieux utiliser la version 2 de SSH, qui est normalement plus sure. À régler dans /etc/ssh/ssh_config (réglage du client), le serveur étant capable de répondre aux deux protocoles.
* Il n'y a aucun problème si le réseau est non sûr (typiquement Internet): par SSH tout est crypté, mot de passe compris. Par exemple, si je copie un fichier mp3 ou avi par SCP (basé sur SSH), impossible de savoir ce qui est transféré en écoutant le réseau.

Finalement je maintiens, en argumentant, que l'utilisation de clés pour SSH est sure, même pour root. En évitant les quelques pièges décrits ci-dessus.

[mess-mate]

Bon, je vais terminer la discussion avec ceci:
http://www.linux.com/feature/61061
A lire d'urgence.

[Noizet]

Hello,
Merci de vos réponses, mais je dois toujours entré le mot de passe et je ne comprend pas ce que je fais de faux !

Certaine chose on changé, je ne peux plus rien mettre sur le serveur (clé)

On m'a donné trois clés publiques (ssh_host_rsa_key , ssh_host_key, ssh_host_dsa_key)

Voilà ce que j'ai fait en essayant de suivre vos conseils

1° J'ai mis la clé ssh_host_dsa_key dans le dossier home/.ssh (machine locale) et je l'ai renommé en authorized_keys.pub

2° J'ai mis la clé ssh_host_rsa_key dans le dossier home/.ssh (machine locale) et je l'ai renommé en known_hosts

3° Je me suis connecter depuis la console en mode ssh sur le serveur, il m'a mis un message, j'ai mis yes et j'ai entré le mot de passe.

Voilà, et depuis, je dois toujours rentré le mot de passe

Est-ce que vous pouvez m'expliquer ce que je fais de faux !

Merci beaucoup !

[jmelyn]

Bonjour,

Si tu as lu ce qu'il y a d'écrit dans ce fil, tu n'as pas dû comprendre grand-chose. Si tu veux comprendre, relis et demande si ça coince.

Tu parles de trois fichiers que l'on t'a passés. J'espère que ce sont bien les clés publiques. Pour vérifier, tape les commandes grep PRIVATE ssh_host_key, puis grep PRIVATE ssh_host_rsa_key, et enfin grep PRIVATE ssh_host_dsa_key. Normalement, ça ne devrait rien sortir.

Tu remarqueras que ces trois fichiers (ssh_host_key, ssh_host_rsa_key, ssh_host_dsa_key) comportent le mot host. Ce sont trois clés ordi qui t'éviteront de répondre à la question:
The authenticity of host 'XXXXX (123.456.789.012)' can't be established.
RSA key fingerprint is ..........
Are you sure you want to continue connecting (yes/no)?
Il faut que tu mettes ces trois clés dans le fichier ~/.ssh/known_hosts de la machine cliente. Pour ce faire, tape les commandes (depuis la machine cliente):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
cat ssh_host_key > ~/.ssh/known_hosts
cat ssh_host_rsa_key >> ~/.ssh/known_hosts
cat ssh_host_dsa_key >> ~/.ssh/known_hosts

Maintenant, il faut transmettre ta clé publique d'utilisateur au serveur. Je ne sais pas comment tu peux la tranmettre (e-mail, répertoire commun, NFS ou autre), à toi de voir. Le ou les fichiers que tu dois transmettre se trouvent sur la machine cliente dans ton répertoire ~/.ssh: Tous ceux qui se terminent par ".pub" doivent être copiés vers le serveur. Si tu ne trouves aucun fichier ".pub" dis-le, il y a une manip supplémentaire à faire. Il peut y avoir 3 fichiers max: identity.pub, id_rsa.pub, id_dsa.pub. Une fois ces trois fichiers copiés, tu te connectes sur le serveur avec le bon user et tu ajoutes les trois fichiers à ~/.ssh/authorized_keys. Voici comment faire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
cat identity.pub > ~/.ssh/authorized_keys
cat id_rsa.pub >> ~/.ssh/authorized_keys
cat id_dsa.pub >> ~/.ssh/authorized_keys

J'espère que tu liras correctement ce post pour faire les manips.

[Noizet]

Merci de ta réponse, désolé je n'ai jamais utiliser ssh auparavant !

Je n'ai aucun .pub dans le fichier .ssh, quelle est la manipulation à faire ?

Je sais comment générer la clé dsa et rsa, mais pas la dernière

[jmelyn]

.ssh n'est pas un fichier mais un sous-répertoire de ~ (c'est-à-dire $HOME). Pour créer les clés, il faut le faire avec la commande ssh-keygen:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
ssh-keygen -t rsa1
Generating public/private rsa1 key pair.
Enter file in which to save the key (/home/user/.ssh/identity):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in identity.
Your public key has been saved in identity.pub.
The key fingerprint is:
xx:yy:.... user@machine.domaine

Il suffit de juste taper "Enter" aux trois questions. Idem pour les autres clés: ssh-keygen -t rsa et ssh-keygen -t dsa. Maintenant, il devrait y avoir six fichiers supplémentaires dans le répertoire .ssh.

[Noizet]

Rebonjour,

J'ai suivi à la lettre les manips que tu as décrites.

- J'ai mis les trois clés publiques du serveur dans le fichier ~/.ssh/known_hosts de la machine locale
- J'ai générer les clés identity, rsa et dsa, j'ai mis les publiques sur le serveur (~/.ssh/autorized_keys)

Ca ne fonctionne toujours pas. Pourtant, il me semble que les sous-répertoires .ssh sont à la bonne place, car quand j'exectue la commande ~/.ssh, il arrive directement dans .ssh

[jmelyn]

Bon, cela devient clair et précis, les actions que tu as effectuées vont dans le bon sens. Il reste encore des points flous comme les users et home-dirs des comptes sur les machines cliente et serveur: Est-ce le même compte? Est-ce un home-dir commun?

Il faudra s'attaquer aux configurations des machines cliente et serveur. Mais pour l'instant, afin d'affiner le diagnostic, il faudrait lancer la commande suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

[user_client@machine_cliente] ~ $ ssh -vvv user_server@machine_serveur

La partie en gras est le prompt (donc pas à taper) pour indiquer où tu es et avec quel user. La sortie sera assez verbeuse, mais il faudrait tout mettre ici, entre balises [ CODE ] et [ /CODE ].

Edit: Il faudra être plus précis dans les constatations. "Ça ne fonctionne pas" n'est pas suffisant, les détails sont les bienvenus. De plus, j'imagine que tu parles de la commande ssh-keygen, pas ~/.ssh.

[Noizet]

Alors, ce qui fonctionne pas, c'est que je dois remettre le mot de passe à chaque fois que je me connecte.

la comande ssh-keygen, fonctionne sans problème!

Non ce n'est pas les même users entre la machine cliente et le serveur.

Par contre, comment je fais pour copier ce qu'il m'a écrit dans le dos ? Je ne peux pas sélectionner..