Excusez la naïveté de mes questions, mais je leur cherche en vain une
réponse sûre depuis une semaine avec l'aide de Google et des pages de
manuel de ssh et ce n'est pas clair du tout pour le débutant que je suis.
- Soit un pc A situé à Albi, doté de l'OS Linux Mandrake 10.1 et de
openssh 3.9p1, brut d'installation, c'est-à-dire avec sa configuration
par défaut. Un utilisateur Toto y est créé et y possède son home.
- Soit un pc B situé à Brive, doté de l'OS Windows XP et d'une version
récente du client Filezilla.
Depuis Brive, Toto parvient avec Filezilla à accéder à son répertoire
personnel du pc A et à y récupérer et déposer des documents. La seule
condition est qu'il s'identifie avec ses login et mot de passe après
avoir choisi le port 22 et le mode « sftp avec ssh2 » de Filezilla. Toto
ne possède à sa connaissance ni clef publique ni clef privée.
(Remarque : Ce succès n'est obtenu qu'à la 2ème tentative.)
Le mot de passe de connexion de Toto a-t-il circulé en clair sur le
réseau mondial à sa première tentative ?
Circule-t-il en clair lors de la seconde tentative et des suivantes ?
Les données utiles transmises sont elles chiffrées ? Dans les deux sens ?
Si oui, je serais infiniment heureux de savoir quel mécanisme permet ce
chiffrage.
Si quelqu'un peut consacrer quelques minutes à me donner des réponses
simples, je l'en remercie d'avance.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
ario
On 2005-01-26, geo cherchetout wrote: Bonjour,
Le mot de passe de connexion de Toto a-t-il circulé en clair sur le réseau mondial à sa première tentative ? non
Circule-t-il en clair lors de la seconde tentative et des suivantes ? non
Les données utiles transmises sont elles chiffrées ? Dans les deux sens ? Si oui, je serais infiniment heureux de savoir quel mécanisme permet ce chiffrage.
oui oui. A l'installation du serveur ssh, une paire de clés a ete generee. Ensuite lors de la tentative de connexion, le serveur envoit sa clé publique et son fingerprint. L'utilisateur doit alors verifier le fingerprint( ce que presque personne ne fait et c'est bien dommage car on peut faire une man in the middle attack) et ensuite s'authentifie aupres du serveur. Ensuite une une cle de session est etablie qui est utilisee dans RC4 pour chiffrer les données qui transitent.
Si quelqu'un peut consacrer quelques minutes à me donner des réponses simples, je l'en remercie d'avance. de rien
ario
On 2005-01-26, geo cherchetout <geo.cherchetoutsanspam@laposte.net.invalid>
wrote:
Bonjour,
Le mot de passe de connexion de Toto a-t-il circulé en clair sur le
réseau mondial à sa première tentative ?
non
Circule-t-il en clair lors de la seconde tentative et des suivantes ?
non
Les données utiles transmises sont elles chiffrées ? Dans les deux sens ?
Si oui, je serais infiniment heureux de savoir quel mécanisme permet ce
chiffrage.
oui oui.
A l'installation du serveur ssh, une paire de clés a ete generee.
Ensuite lors de la tentative de connexion, le serveur envoit sa clé
publique et son fingerprint. L'utilisateur doit alors verifier le
fingerprint( ce que presque personne ne fait et c'est bien dommage car
on peut faire une man in the middle attack) et ensuite s'authentifie
aupres du serveur. Ensuite une une cle de session est etablie qui est
utilisee dans RC4 pour chiffrer les données qui transitent.
Si quelqu'un peut consacrer quelques minutes à me donner des réponses
simples, je l'en remercie d'avance.
de rien
Le mot de passe de connexion de Toto a-t-il circulé en clair sur le réseau mondial à sa première tentative ? non
Circule-t-il en clair lors de la seconde tentative et des suivantes ? non
Les données utiles transmises sont elles chiffrées ? Dans les deux sens ? Si oui, je serais infiniment heureux de savoir quel mécanisme permet ce chiffrage.
oui oui. A l'installation du serveur ssh, une paire de clés a ete generee. Ensuite lors de la tentative de connexion, le serveur envoit sa clé publique et son fingerprint. L'utilisateur doit alors verifier le fingerprint( ce que presque personne ne fait et c'est bien dommage car on peut faire une man in the middle attack) et ensuite s'authentifie aupres du serveur. Ensuite une une cle de session est etablie qui est utilisee dans RC4 pour chiffrer les données qui transitent.
Si quelqu'un peut consacrer quelques minutes à me donner des réponses simples, je l'en remercie d'avance. de rien
ario
geo cherchetout
Le 27.01.2005 18:03, *ario* a écrit fort à propos :
A l'installation du serveur ssh, une paire de clés a ete generee.
Oui, côté serveur. Ça je le savais car en réalité le serveur est chez moi.
Ensuite lors de la tentative de connexion, le serveur envoit sa clé publique et son fingerprint. L'utilisateur doit alors verifier le fingerprint( ce que presque personne ne fait et c'est bien dommage car on peut faire une man in the middle attack) et ensuite s'authentifie aupres du serveur.
Le fingerprint a été vérifié. Il avait été transmis préalablement à l'utilisateur. Mais en quoi ce fingerprint prouve-t-il qu'il s'agit bien du bon serveur ? Est-il calculé à partir de sa clef privée ? Par quelle commande puis-je l'obtenir de nouveau ? Est-il inscrit dans un fichier ? Il n'est pas dans les fichiers de /etc/ssh/.
Ensuite une une cle de session est etablie qui est utilisee dans RC4 pour chiffrer les données qui transitent.
Voilà le hic. Cela signifie donc que Filezilla a généré une paire de clefs ? L'utilisateur n'a pourtant pas été invité à saisir une phrase de passe. Comme tu emploies le mot clé au singulier, je n'ai probablement pas encore compris ? Je pensais que chacun chiffrait les données à émettre avec la clef publique du récepteur et déchiffrait les données reçues avec sa propre clef privée, ce qui nécessite une paire de clefs à chaque bout...
Merci déjà pour ces explications pas trop compliquées. (Je me renseigne sur RC4 dont je viens de lire le nom pour la première fois. Il est toujours bon d'avoir une idée des principes mis en ½uvre, même si on peut se passer de retenir tous les détails.)
Le 27.01.2005 18:03, *ario* a écrit fort à propos :
A l'installation du serveur ssh, une paire de clés a ete generee.
Oui, côté serveur. Ça je le savais car en réalité le serveur est chez moi.
Ensuite lors de la tentative de connexion, le serveur envoit sa clé
publique et son fingerprint. L'utilisateur doit alors verifier le
fingerprint( ce que presque personne ne fait et c'est bien dommage car
on peut faire une man in the middle attack) et ensuite s'authentifie
aupres du serveur.
Le fingerprint a été vérifié. Il avait été transmis préalablement à
l'utilisateur. Mais en quoi ce fingerprint prouve-t-il qu'il s'agit bien
du bon serveur ? Est-il calculé à partir de sa clef privée ?
Par quelle commande puis-je l'obtenir de nouveau ? Est-il inscrit dans
un fichier ? Il n'est pas dans les fichiers de /etc/ssh/.
Ensuite une une cle de session est etablie qui est
utilisee dans RC4 pour chiffrer les données qui transitent.
Voilà le hic. Cela signifie donc que Filezilla a généré une paire de
clefs ? L'utilisateur n'a pourtant pas été invité à saisir une phrase de
passe. Comme tu emploies le mot clé au singulier, je n'ai probablement
pas encore compris ?
Je pensais que chacun chiffrait les données à émettre avec la clef
publique du récepteur et déchiffrait les données reçues avec sa propre
clef privée, ce qui nécessite une paire de clefs à chaque bout...
Merci déjà pour ces explications pas trop compliquées. (Je me renseigne
sur RC4 dont je viens de lire le nom pour la première fois. Il est
toujours bon d'avoir une idée des principes mis en ½uvre, même si on
peut se passer de retenir tous les détails.)
Le 27.01.2005 18:03, *ario* a écrit fort à propos :
A l'installation du serveur ssh, une paire de clés a ete generee.
Oui, côté serveur. Ça je le savais car en réalité le serveur est chez moi.
Ensuite lors de la tentative de connexion, le serveur envoit sa clé publique et son fingerprint. L'utilisateur doit alors verifier le fingerprint( ce que presque personne ne fait et c'est bien dommage car on peut faire une man in the middle attack) et ensuite s'authentifie aupres du serveur.
Le fingerprint a été vérifié. Il avait été transmis préalablement à l'utilisateur. Mais en quoi ce fingerprint prouve-t-il qu'il s'agit bien du bon serveur ? Est-il calculé à partir de sa clef privée ? Par quelle commande puis-je l'obtenir de nouveau ? Est-il inscrit dans un fichier ? Il n'est pas dans les fichiers de /etc/ssh/.
Ensuite une une cle de session est etablie qui est utilisee dans RC4 pour chiffrer les données qui transitent.
Voilà le hic. Cela signifie donc que Filezilla a généré une paire de clefs ? L'utilisateur n'a pourtant pas été invité à saisir une phrase de passe. Comme tu emploies le mot clé au singulier, je n'ai probablement pas encore compris ? Je pensais que chacun chiffrait les données à émettre avec la clef publique du récepteur et déchiffrait les données reçues avec sa propre clef privée, ce qui nécessite une paire de clefs à chaque bout...
Merci déjà pour ces explications pas trop compliquées. (Je me renseigne sur RC4 dont je viens de lire le nom pour la première fois. Il est toujours bon d'avoir une idée des principes mis en ½uvre, même si on peut se passer de retenir tous les détails.)
Erwann ABALEA
On Thu, 27 Jan 2005, geo cherchetout wrote:
Le 27.01.2005 18:03, *ario* a écrit fort à propos :
A l'installation du serveur ssh, une paire de clés a ete generee.
Oui, côté serveur. Ça je le savais car en réalité le serveur est chez moi.
Ensuite lors de la tentative de connexion, le serveur envoit sa clé publique et son fingerprint. L'utilisateur doit alors verifier le fingerprint( ce que presque personne ne fait et c'est bien dommage car on peut faire une man in the middle attack) et ensuite s'authentifie aupres du serveur.
Le fingerprint a été vérifié. Il avait été transmis préalablement à l'utilisateur. Mais en quoi ce fingerprint prouve-t-il qu'il s'agit bien du bon serveur ? Est-il calculé à partir de sa clef privée ?
Le fingerprint est une empreinte de la clé publique. L'algorithme mis en oeuvre (MD5) est en théorie conçu pour qu'il soit très difficile de trouver une deuxième clé publique qui donne la même empreinte. Donc si ton client a vérifié que l'empreinte indiquée par son logiciel est bien l'empreinte que tu lui as transmis (par un autre canal que l'Internet), alors ton client peut être certain que les données qu'il enverra ne seront déchiffrables que par la clé privée correspondante, qui est celle de ton serveur.
Par quelle commande puis-je l'obtenir de nouveau ? Est-il inscrit dans un fichier ? Il n'est pas dans les fichiers de /etc/ssh/.
ssh-keygen -l -f monfichier.pub Le choix du fichier 'monfichier.pub' dépend du client et du protocole négocié entre le client et le serveur (RSA protocole 1, RSA protocole 2, DSA protocole 2). Les clés de ton serveur sont dans /etc/ssh généralement.
Ensuite une une cle de session est etablie qui est utilisee dans RC4 pour chiffrer les données qui transitent.
Voilà le hic. Cela signifie donc que Filezilla a généré une paire de clefs ? L'utilisateur n'a pourtant pas été invité à saisir une phrase de
Non. FileZilla a utilisé son générateur de pseudo aléa de qualité cryptographique pour générer une clé jetable, et a transmis cette clé à ton serveur.
Je pensais que chacun chiffrait les données à émettre avec la clef publique du récepteur et déchiffrait les données reçues avec sa propre clef privée, ce qui nécessite une paire de clefs à chaque bout...
Pas toujours, pour plusieurs raisons: - il est beaucoup plus efficace de chiffrer des données avec un algo symétrique (DES, 3DES, IDEA, AES, RC4) qu'avec un algo asymétrique (RSA, DH). L'ordre de grandeur du chiffrement est de 1 pour 25 à 1 pour 300+ selon l'algo symétrique choisi par rapport au RSA1024, et un déchiffrement RSA1024 prend environ 20 fois plus de temps qu'un chiffrement RSA1024 (pour un algo symétrique, la différence est négligeable quand elle existe) - dans le cas présent, il faut une clé de session, il suffit donc que l'une des deux parties en génère une (au hasard), et la transmette à l'autre partie. Le serveur, on sait qu'il a une paire de clé, mais le client n'en a pas forcément une; c'est donc généralement au client de générer cette clé de session, et de la chiffrer à destination du serveur
Merci déjà pour ces explications pas trop compliquées. (Je me renseigne sur RC4 dont je viens de lire le nom pour la première fois. Il est
RC4 est un bon algo, quoi qu'on en dise. Il est simplement très difficile à utiliser correctement. Il a pour qualités sa grande simplicité et ses performances. 'openssl speed aes des rc4 idea rsa1024' te donnera plus de chiffres.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- T> il ne t'ai pas venu a l'idée que qu'il existait de nombreux gentils T> contributeurs qui en ont rien a faire de tes jérémiades si :o) mais à ce moment là il faut me plonker -+- BC in GNU-SE : Mais ou qu'il s'est plonké ce con là ? -+-
On Thu, 27 Jan 2005, geo cherchetout wrote:
Le 27.01.2005 18:03, *ario* a écrit fort à propos :
A l'installation du serveur ssh, une paire de clés a ete generee.
Oui, côté serveur. Ça je le savais car en réalité le serveur est chez moi.
Ensuite lors de la tentative de connexion, le serveur envoit sa clé
publique et son fingerprint. L'utilisateur doit alors verifier le
fingerprint( ce que presque personne ne fait et c'est bien dommage car
on peut faire une man in the middle attack) et ensuite s'authentifie
aupres du serveur.
Le fingerprint a été vérifié. Il avait été transmis préalablement à
l'utilisateur. Mais en quoi ce fingerprint prouve-t-il qu'il s'agit bien
du bon serveur ? Est-il calculé à partir de sa clef privée ?
Le fingerprint est une empreinte de la clé publique. L'algorithme mis en
oeuvre (MD5) est en théorie conçu pour qu'il soit très difficile de
trouver une deuxième clé publique qui donne la même empreinte. Donc si
ton client a vérifié que l'empreinte indiquée par son logiciel est bien
l'empreinte que tu lui as transmis (par un autre canal que l'Internet),
alors ton client peut être certain que les données qu'il enverra ne seront
déchiffrables que par la clé privée correspondante, qui est celle de ton
serveur.
Par quelle commande puis-je l'obtenir de nouveau ? Est-il inscrit dans
un fichier ? Il n'est pas dans les fichiers de /etc/ssh/.
ssh-keygen -l -f monfichier.pub
Le choix du fichier 'monfichier.pub' dépend du client et du protocole
négocié entre le client et le serveur (RSA protocole 1, RSA protocole 2,
DSA protocole 2). Les clés de ton serveur sont dans /etc/ssh généralement.
Ensuite une une cle de session est etablie qui est
utilisee dans RC4 pour chiffrer les données qui transitent.
Voilà le hic. Cela signifie donc que Filezilla a généré une paire de
clefs ? L'utilisateur n'a pourtant pas été invité à saisir une phrase de
Non. FileZilla a utilisé son générateur de pseudo aléa de qualité
cryptographique pour générer une clé jetable, et a transmis cette clé à
ton serveur.
Je pensais que chacun chiffrait les données à émettre avec la clef
publique du récepteur et déchiffrait les données reçues avec sa propre
clef privée, ce qui nécessite une paire de clefs à chaque bout...
Pas toujours, pour plusieurs raisons:
- il est beaucoup plus efficace de chiffrer des données avec un algo
symétrique (DES, 3DES, IDEA, AES, RC4) qu'avec un algo asymétrique
(RSA, DH). L'ordre de grandeur du chiffrement est de 1 pour 25 à 1 pour
300+ selon l'algo symétrique choisi par rapport au RSA1024, et un
déchiffrement RSA1024 prend environ 20 fois plus de temps qu'un
chiffrement RSA1024 (pour un algo symétrique, la différence est
négligeable quand elle existe)
- dans le cas présent, il faut une clé de session, il suffit donc que
l'une des deux parties en génère une (au hasard), et la transmette à
l'autre partie. Le serveur, on sait qu'il a une paire de clé, mais le
client n'en a pas forcément une; c'est donc généralement au client de
générer cette clé de session, et de la chiffrer à destination du
serveur
Merci déjà pour ces explications pas trop compliquées. (Je me renseigne
sur RC4 dont je viens de lire le nom pour la première fois. Il est
RC4 est un bon algo, quoi qu'on en dise. Il est simplement très difficile
à utiliser correctement. Il a pour qualités sa grande simplicité et ses
performances.
'openssl speed aes des rc4 idea rsa1024' te donnera plus de chiffres.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
T> il ne t'ai pas venu a l'idée que qu'il existait de nombreux gentils
T> contributeurs qui en ont rien a faire de tes jérémiades
si :o) mais à ce moment là il faut me plonker
-+- BC in GNU-SE : Mais ou qu'il s'est plonké ce con là ? -+-
Le 27.01.2005 18:03, *ario* a écrit fort à propos :
A l'installation du serveur ssh, une paire de clés a ete generee.
Oui, côté serveur. Ça je le savais car en réalité le serveur est chez moi.
Ensuite lors de la tentative de connexion, le serveur envoit sa clé publique et son fingerprint. L'utilisateur doit alors verifier le fingerprint( ce que presque personne ne fait et c'est bien dommage car on peut faire une man in the middle attack) et ensuite s'authentifie aupres du serveur.
Le fingerprint a été vérifié. Il avait été transmis préalablement à l'utilisateur. Mais en quoi ce fingerprint prouve-t-il qu'il s'agit bien du bon serveur ? Est-il calculé à partir de sa clef privée ?
Le fingerprint est une empreinte de la clé publique. L'algorithme mis en oeuvre (MD5) est en théorie conçu pour qu'il soit très difficile de trouver une deuxième clé publique qui donne la même empreinte. Donc si ton client a vérifié que l'empreinte indiquée par son logiciel est bien l'empreinte que tu lui as transmis (par un autre canal que l'Internet), alors ton client peut être certain que les données qu'il enverra ne seront déchiffrables que par la clé privée correspondante, qui est celle de ton serveur.
Par quelle commande puis-je l'obtenir de nouveau ? Est-il inscrit dans un fichier ? Il n'est pas dans les fichiers de /etc/ssh/.
ssh-keygen -l -f monfichier.pub Le choix du fichier 'monfichier.pub' dépend du client et du protocole négocié entre le client et le serveur (RSA protocole 1, RSA protocole 2, DSA protocole 2). Les clés de ton serveur sont dans /etc/ssh généralement.
Ensuite une une cle de session est etablie qui est utilisee dans RC4 pour chiffrer les données qui transitent.
Voilà le hic. Cela signifie donc que Filezilla a généré une paire de clefs ? L'utilisateur n'a pourtant pas été invité à saisir une phrase de
Non. FileZilla a utilisé son générateur de pseudo aléa de qualité cryptographique pour générer une clé jetable, et a transmis cette clé à ton serveur.
Je pensais que chacun chiffrait les données à émettre avec la clef publique du récepteur et déchiffrait les données reçues avec sa propre clef privée, ce qui nécessite une paire de clefs à chaque bout...
Pas toujours, pour plusieurs raisons: - il est beaucoup plus efficace de chiffrer des données avec un algo symétrique (DES, 3DES, IDEA, AES, RC4) qu'avec un algo asymétrique (RSA, DH). L'ordre de grandeur du chiffrement est de 1 pour 25 à 1 pour 300+ selon l'algo symétrique choisi par rapport au RSA1024, et un déchiffrement RSA1024 prend environ 20 fois plus de temps qu'un chiffrement RSA1024 (pour un algo symétrique, la différence est négligeable quand elle existe) - dans le cas présent, il faut une clé de session, il suffit donc que l'une des deux parties en génère une (au hasard), et la transmette à l'autre partie. Le serveur, on sait qu'il a une paire de clé, mais le client n'en a pas forcément une; c'est donc généralement au client de générer cette clé de session, et de la chiffrer à destination du serveur
Merci déjà pour ces explications pas trop compliquées. (Je me renseigne sur RC4 dont je viens de lire le nom pour la première fois. Il est
RC4 est un bon algo, quoi qu'on en dise. Il est simplement très difficile à utiliser correctement. Il a pour qualités sa grande simplicité et ses performances. 'openssl speed aes des rc4 idea rsa1024' te donnera plus de chiffres.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- T> il ne t'ai pas venu a l'idée que qu'il existait de nombreux gentils T> contributeurs qui en ont rien a faire de tes jérémiades si :o) mais à ce moment là il faut me plonker -+- BC in GNU-SE : Mais ou qu'il s'est plonké ce con là ? -+-
ario
On 2005-01-27, geo cherchetout wrote:
Le fingerprint a été vérifié. Il avait été transmis préalablement à l'utilisateur. Mais en quoi ce fingerprint prouve-t-il qu'il s'agit bien du bon serveur ? Est-il calculé à partir de sa clef privée ? Par quelle commande puis-je l'obtenir de nouveau ? Est-il inscrit dans un fichier ? Il n'est pas dans les fichiers de /etc/ssh/.
non le fingerprint est cree à partir de la clé publique (je crois que c'est juste un hash de celle ci, donc tant que la fonction de hachage est sans collisions). Si qqn essaie de faire une man in the middle attack, il va presenter une clé publique qui ne sera pas la bonne donc le fingerprint ne sera pas le bon. Un bon fingerprint signifie une bonne clé publique et donc une bonne clé privé. Il faut juste que le client verifie que la clé publique va bien avec le fingerprint et que l'utilisateur verifie le fingerprint. on le regenere comme ca : ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
perso je l'ai toujours sur moi juste pour etre sur que je cause bien avec mon serveur
Voilà le hic. Cela signifie donc que Filezilla a généré une paire de clefs ? L'utilisateur n'a pourtant pas été invité à saisir une phrase de passe. Comme tu emploies le mot clé au singulier, je n'ai probablement pas encore compris ? Je pensais que chacun chiffrait les données à émettre avec la clef publique du récepteur et déchiffrait les données reçues avec sa propre clef privée, ce qui nécessite une paire de clefs à chaque bout...
le probleme de RSA c'est que c'est lent!!!! Une fois que l'authentification a eu lieu, un protocole permet de creer une clé de session partagée par les 2 entités sans qu'elle transite sur le réseau (ou alors chifrée). Filezilla a donc créé une unique clé en accord avec le serveur. Cette clé de session est utilisée dans un algorithme symétrique, en l'occurance RC4, pour chiffrer le reste de la communication.
Merci déjà pour ces explications pas trop compliquées. de rien
ario
On 2005-01-27, geo cherchetout wrote:
Le fingerprint a été vérifié. Il avait été transmis préalablement à
l'utilisateur. Mais en quoi ce fingerprint prouve-t-il qu'il s'agit bien
du bon serveur ? Est-il calculé à partir de sa clef privée ?
Par quelle commande puis-je l'obtenir de nouveau ? Est-il inscrit dans
un fichier ? Il n'est pas dans les fichiers de /etc/ssh/.
non le fingerprint est cree à partir de la clé publique (je crois que
c'est juste un hash de celle ci, donc tant que la fonction de hachage
est sans collisions). Si qqn essaie de faire une man in the middle
attack, il va presenter une clé publique qui ne sera pas la bonne donc
le fingerprint ne sera pas le bon. Un bon fingerprint signifie une bonne
clé publique et donc une bonne clé privé. Il faut juste que le client
verifie que la clé publique va bien avec le fingerprint et que
l'utilisateur verifie le fingerprint.
on le regenere comme ca :
ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
perso je l'ai toujours sur moi juste pour etre sur que je cause bien
avec mon serveur
Voilà le hic. Cela signifie donc que Filezilla a généré une paire de
clefs ? L'utilisateur n'a pourtant pas été invité à saisir une phrase de
passe. Comme tu emploies le mot clé au singulier, je n'ai probablement
pas encore compris ?
Je pensais que chacun chiffrait les données à émettre avec la clef
publique du récepteur et déchiffrait les données reçues avec sa propre
clef privée, ce qui nécessite une paire de clefs à chaque bout...
le probleme de RSA c'est que c'est lent!!!! Une fois que
l'authentification a eu lieu, un protocole permet de creer une clé de
session partagée par les 2 entités sans qu'elle transite sur le réseau
(ou alors chifrée). Filezilla a donc créé une unique clé en accord avec
le serveur. Cette clé de session est utilisée dans un algorithme
symétrique, en l'occurance RC4, pour chiffrer le reste de la
communication.
Merci déjà pour ces explications pas trop compliquées.
de rien
Le fingerprint a été vérifié. Il avait été transmis préalablement à l'utilisateur. Mais en quoi ce fingerprint prouve-t-il qu'il s'agit bien du bon serveur ? Est-il calculé à partir de sa clef privée ? Par quelle commande puis-je l'obtenir de nouveau ? Est-il inscrit dans un fichier ? Il n'est pas dans les fichiers de /etc/ssh/.
non le fingerprint est cree à partir de la clé publique (je crois que c'est juste un hash de celle ci, donc tant que la fonction de hachage est sans collisions). Si qqn essaie de faire une man in the middle attack, il va presenter une clé publique qui ne sera pas la bonne donc le fingerprint ne sera pas le bon. Un bon fingerprint signifie une bonne clé publique et donc une bonne clé privé. Il faut juste que le client verifie que la clé publique va bien avec le fingerprint et que l'utilisateur verifie le fingerprint. on le regenere comme ca : ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
perso je l'ai toujours sur moi juste pour etre sur que je cause bien avec mon serveur
Voilà le hic. Cela signifie donc que Filezilla a généré une paire de clefs ? L'utilisateur n'a pourtant pas été invité à saisir une phrase de passe. Comme tu emploies le mot clé au singulier, je n'ai probablement pas encore compris ? Je pensais que chacun chiffrait les données à émettre avec la clef publique du récepteur et déchiffrait les données reçues avec sa propre clef privée, ce qui nécessite une paire de clefs à chaque bout...
le probleme de RSA c'est que c'est lent!!!! Une fois que l'authentification a eu lieu, un protocole permet de creer une clé de session partagée par les 2 entités sans qu'elle transite sur le réseau (ou alors chifrée). Filezilla a donc créé une unique clé en accord avec le serveur. Cette clé de session est utilisée dans un algorithme symétrique, en l'occurance RC4, pour chiffrer le reste de la communication.
Merci déjà pour ces explications pas trop compliquées. de rien
ario
T0t0
"geo cherchetout" wrote in message news:41f95643$0$2183$
Le fingerprint a été vérifié. Il avait été transmis préalablement à l'utilisateur. Mais en quoi ce fingerprint prouve-t-il qu'il s'agit bien du bon serveur ? Est-il calculé à partir de sa clef privée ?
Exactement !
Par quelle commande puis-je l'obtenir de nouveau ? Est-il inscrit dans un fichier ? Il n'est pas dans les fichiers de /etc/ssh/.
Nop, il est créé et envoyé à la volée. S'il était possible de rejouer un fingerprint, ça poserait un pb de sécurité :-)
Voilà le hic. Cela signifie donc que Filezilla a généré une paire de clefs ?
Non, je ne connais pas le fonctionnement de SSH en détail, mais il suffit que le client créé une clef de session et la chiffre avec la clef publique du serveur. Ainsi, seul le serveur pourra lire cette clef de session. Je ne suis pas sûr que ce soit ce mode de fonctionnement qui soit utilisé, mais c'est souvent ce type de modèle qui est choisi.
Je pensais que chacun chiffrait les données à émettre avec la clef publique du récepteur et déchiffrait les données reçues avec sa propre clef privée, ce qui nécessite une paire de clefs à chaque bout...
Ah bah non, ca serait beaucoup trop lent. Les algorithmes asymétriques (avec clefs pub/priv) offrent une bonne authentification, mais demandent beaucoup de ressources pour le chiffrement. C'est pour cela qu'on préfère mettre en oeuvre une clef de session dès que l'authentification est faite, pour ensuite utiliser un algorithme symétrique pour les échanges chiffrés, avec cette clef de session symétrique partagée.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"geo cherchetout" <geo.cherchetoutsanspam@laposte.net.invalid> wrote in
message news:41f95643$0$2183$8fcfb975@news.wanadoo.fr
Le fingerprint a été vérifié. Il avait été transmis préalablement à
l'utilisateur. Mais en quoi ce fingerprint prouve-t-il qu'il s'agit bien
du bon serveur ? Est-il calculé à partir de sa clef privée ?
Exactement !
Par quelle commande puis-je l'obtenir de nouveau ? Est-il inscrit dans
un fichier ? Il n'est pas dans les fichiers de /etc/ssh/.
Nop, il est créé et envoyé à la volée. S'il était possible de rejouer
un fingerprint, ça poserait un pb de sécurité :-)
Voilà le hic. Cela signifie donc que Filezilla a généré une paire de
clefs ?
Non, je ne connais pas le fonctionnement de SSH en détail, mais il
suffit que le client créé une clef de session et la chiffre avec la
clef publique du serveur. Ainsi, seul le serveur pourra lire cette
clef de session.
Je ne suis pas sûr que ce soit ce mode de fonctionnement qui soit
utilisé, mais c'est souvent ce type de modèle qui est choisi.
Je pensais que chacun chiffrait les données à émettre avec la clef
publique du récepteur et déchiffrait les données reçues avec sa propre
clef privée, ce qui nécessite une paire de clefs à chaque bout...
Ah bah non, ca serait beaucoup trop lent.
Les algorithmes asymétriques (avec clefs pub/priv) offrent une bonne
authentification, mais demandent beaucoup de ressources pour le
chiffrement. C'est pour cela qu'on préfère mettre en oeuvre une clef de
session dès que l'authentification est faite, pour ensuite utiliser un
algorithme symétrique pour les échanges chiffrés, avec cette clef de
session symétrique partagée.
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"geo cherchetout" wrote in message news:41f95643$0$2183$
Le fingerprint a été vérifié. Il avait été transmis préalablement à l'utilisateur. Mais en quoi ce fingerprint prouve-t-il qu'il s'agit bien du bon serveur ? Est-il calculé à partir de sa clef privée ?
Exactement !
Par quelle commande puis-je l'obtenir de nouveau ? Est-il inscrit dans un fichier ? Il n'est pas dans les fichiers de /etc/ssh/.
Nop, il est créé et envoyé à la volée. S'il était possible de rejouer un fingerprint, ça poserait un pb de sécurité :-)
Voilà le hic. Cela signifie donc que Filezilla a généré une paire de clefs ?
Non, je ne connais pas le fonctionnement de SSH en détail, mais il suffit que le client créé une clef de session et la chiffre avec la clef publique du serveur. Ainsi, seul le serveur pourra lire cette clef de session. Je ne suis pas sûr que ce soit ce mode de fonctionnement qui soit utilisé, mais c'est souvent ce type de modèle qui est choisi.
Je pensais que chacun chiffrait les données à émettre avec la clef publique du récepteur et déchiffrait les données reçues avec sa propre clef privée, ce qui nécessite une paire de clefs à chaque bout...
Ah bah non, ca serait beaucoup trop lent. Les algorithmes asymétriques (avec clefs pub/priv) offrent une bonne authentification, mais demandent beaucoup de ressources pour le chiffrement. C'est pour cela qu'on préfère mettre en oeuvre une clef de session dès que l'authentification est faite, pour ensuite utiliser un algorithme symétrique pour les échanges chiffrés, avec cette clef de session symétrique partagée.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
geo cherchetout
Mille mercis à tous. J'y vois à présent beaucoup plus clair car vos explications complètent à merveille ce que j'ai trouvé entre-temps ici : http://www.uqtr.ca/~delisle/Crypto/publics/ http://www.uqtr.ca/~delisle/Crypto/prives/flux_rc4.php Et il existe plein d'autres gisements. Bonne nuit, faites de beaux rêves.
Mille mercis à tous. J'y vois à présent beaucoup plus clair car vos
explications complètent à merveille ce que j'ai trouvé entre-temps ici :
http://www.uqtr.ca/~delisle/Crypto/publics/
http://www.uqtr.ca/~delisle/Crypto/prives/flux_rc4.php
Et il existe plein d'autres gisements.
Bonne nuit, faites de beaux rêves.
Mille mercis à tous. J'y vois à présent beaucoup plus clair car vos explications complètent à merveille ce que j'ai trouvé entre-temps ici : http://www.uqtr.ca/~delisle/Crypto/publics/ http://www.uqtr.ca/~delisle/Crypto/prives/flux_rc4.php Et il existe plein d'autres gisements. Bonne nuit, faites de beaux rêves.
