Discussion :

[troumad]

Bonjour

J'ai un problème que je n'arrive pas à analyser...
En TP avec des étudiants, ils me génèrent un couple de clefs privée / publique.
Ils renomment leur clef publique authorized_keys dans leur répertoire ~/.ssh .
Je récupère leur clef privée ( id_rsa ) par scp, je la mets dans mon ~/.ssh et je n'arrive pas à me connecter sans mot de passe sur leur machine !!! Enfin, il y en a qu'un seul avec qui ça marche. Le premier avec lequel j'ai testé. Après avoir planté avec les autres, j'ai réessayé avec lui et ça marchait encore...
Sachant que tous les PC sont installé de la même manière :
mini cd de mdv 2008 + " wget http://troumad.org/debut.sh" + exécution de debut.sh + mise à jour du système...

[hmhm12]

j ai deja vu ce probleme, c est pas evident, supprime tous les .ssh,
si ca marche pas reinstalle ssh.

[troumad]

tous ? serveur - client ?

[ripat]

Il me semble que tu utilises le système à l'envers. Si tu veux établir une connexion de A vers B:

Sur A
ssh-keygen produit id_rsa (clé privée de A) et id_rsa.pub (clé publique de A)

Sur B
ajouter dans le fichier authorized_keys la clé publique de A ainsi que toutes les clés publiques qui doivent avoir accès à B.

Lors de la connexion ssh (ou scp ou rsync etc...) le protocole ssh fait une tentative de matching de clés (la clé publique contenue dans l'authorized_keys de B correspond t'elle à la clé privée qui veut entrer?) si oui --> connexion réussie.

Si tu veux que la connexion se fasse dans les deux sens, tu refais la même procédure sur B (keygen) et tu rajoutes la clé publique (de B) dans l'authorized_keys de A.

Dans ton cas, si tu veux accéder depuis ta machine à toutes les bécanes des étudiants, c'est toi qui doit créer ton couple de clés et installer ta clé publique dans l'authorized_keys de chacune des machines de tes élèves.

Non?

[troumad]

Il me semble que tu utilises le système à l'envers. Si tu veux établir une connexion de A vers B:

Sur A
ssh-keygen produit id_rsa (clé privée de A) et id_rsa.pub (clé publique de A)

Sur B
[...]
Dans ton cas, si tu veux accéder depuis ta machine à toutes les bécanes des étudiants, c'est toi qui doit créer ton couple de clés et installer ta clé publique dans l'authorized_keys de chacune des machines de tes élèves.

Non?

Je ne peux pas faire générer la clef par les étudiants, rapatrier leur clef privé pour me connecter chez eux ?
La manip est certes inversée : c'est le serveur qui crée la clef, mais est-ce un problème ?

[hmhm12]

tous ? serveur - client ?

oui

ou travail avec les cles dsa:
#ssh-keygen -t dsa

[troumad]

ou travail avec les cles dsa:
#ssh-keygen -t dsa

Pourquoi conseilles-tu les clefs dsa ?

[ripat]

Je ne peux pas faire générer la clef par les étudiants, rapatrier leur clef privé pour me connecter chez eux ?

Non. Pas dans ce sens.

Pour communiquer avec eux tu dois déposer sur leur machines ta clé publique. Pas l'inverse.

[troumad]

Et pourquoi ça ne marche pas si je récupère leur clef privée ? On a toujours la paire privé/publique !
Je récupère une clef, fais le test avec puis j'en récupère une autre et refais le test.

[hmhm12]

Non. Pas dans ce sens.

Pour communiquer avec eux tu dois déposer sur leur machines ta clé publique. Pas l'inverse.

la cle prive est tj sur le serveur, et sur le client la cle public(le fichier authorized_keys peut contenir plusieurs cle public prevenant de plusieurs serveurs)
donc le client peut contacter plusieurs serveurs.

[troumad]

Je crois qu'on s'est encore fait avoir avec notre configuration 1 client 14 serveurs !
On va tester demain !

[ripat]

la cle prive est tj sur le serveur, et sur le client la cle public(le fichier authorized_keys peut contenir plusieurs cle public prevenant de plusieurs serveurs)
donc le client peut contacter plusieurs serveurs.

Non plus. Dans une configuration où plusieurs clients doivent contacter un serveur, celui-ci doit avoir les clés publiques de chacun des clients.

Si tu veux simplifier le travail pour ce type de cette configuration, une solution, boiteuse au niveau sécurité, serait de générer un seul couple clés privée/publique. De mettre la clé privée sur les clients et la publique dans l'authorized_keys du serveur.

Mais, il ne sera pas possible pour le serveur de contacter les clients. Du moins par échange de clés.

Pour résumer:

A (id_rsa de A) ----> B (id_rsa.pub de A ds authorized_keys de B)

Le mieux est d'essayer entre deux machines pour bien comprendre dans quel sens ce protocole d'établissement de connexion marche.

[troumad]

Non. Pas dans ce sens.

Pour communiquer avec eux tu dois déposer sur leur machines ta clé publique. Pas l'inverse.

Si tu veux simplifier le travail pour ce type de cette configuration, une solution, boiteuse au niveau sécurité, serait de générer un seul couple clés privée/publique. De mettre la clé privée sur les clients et la publique dans l'authorized_keys du serveur.

Dans ton premier courrier, tu dis que je ne peux pas récupérer la clef privée du serveur comme si la clef privée devait rester où elle a été générée.
Dans le second tu parles d'un couple de clef publique/privé, de mettre la clef publique chez les serveurs et la clef privée chez les clients. Ce qui ne correspond pas !

Donc je repose clairement et autrement ma question :
J'ai un couple de clefs privée/publique. Je mets la clef publique dans l'authorized_key d'un serveur et la privée sur un client.
Est-ce bon ?

[ripat]

Tout dépend du contexte. Si tu veux qu'une machine puisse se connecter à plusieurs autres, exemple ta machine vers celles des étudiants, tu gardes ta clé privée sur ta machine et tu mets ta clé publique sur les PC des étudiants.

Si tu veux que les étudiants puissent contacter un serveur par ssh, par échange de clé, c'est l'inverse. La clé privée des étudiants chez eux et leur clés publiques sur le serveur.

Tout dépend de ce que tu veux faire.

[troumad]

Je souhaite que les étudiants créent un paire de clef et que je puisse la tester.
Ceci dit, après une semaine de pose (les PC ayant une semaine sous Windows ), des paires ne marchants pas la semaine dernières ont marché cette semaine.
Je ne comprends pas pourquoi ça ne marchait pas la première fois !
Je but de la manip est uniquement de montrer les possibilités d'un serveur sous Linux.