vincentxavier a écrit :Heu ne serais tu pas en train de mélanger les clefs du serveurs et les clefs (éventuelles) des utilisateurs ?? Depuis le début, c'est l'impression que tu me donnes !
Il y'a plein d'échange de clef dans une session ssh, mais dans tous les cas, les clefs échangées sont des clefs publiques et ne compromettent ni le serveur, ni l'utilisateur.
Y-a du vrai
m'étais jusque là intéressé qu'aux clés client (privée/pub).
a- je créé ma petite clé
b- j'envois la version .pub sur le serveur & vérifie les droits (sur ~/.ssh, client & serveur) avec ssh-installkeys de wain par ex.
http://wiki.archlinux.fr/howto:reseau:ssh_sans_mdp
c- vérifie que la connexion se fait, et désactive l'identification par mot de passe & l'identification RSA (sshd_config):
Code : Tout sélectionner
RSAAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
vincentxavier a bon, je pensais que la clé échangée lors d'une connexion était celle créée en 1er (et uniquement celle-là). Faut dire que, contrairement à vincentxavier les guides que je consulte font l'impasse sur ces clés serveur (NDLR, ici aucun n'en parle, internet, mags ou manuel "Red Hat Fedora TCP/IP Services réseaux" de Mikaël Pirio).
Donc nouvelle étape pour éviter l'alerte SPOOFING:
d- OK j'ai juste édité le sshd_config sur les distros du portable et indiqué le nouvel emplacement des clés du serveur, et ça rulez
P.S. Perso, même si ca fait longtemps que j'ai eu envie de faire cette manipulation, je ne l'ai jamais faite par flemme Wink
j'utilise ssh depuis what time (lgtps) pour accèder et gérer mon routeur & le portable ; j'ai trop la flemme de configurer un serveur nfs, ftp ou autre, lance rsync pour synchroniser les 2 machines, l'écran du desktop est plus confortable, j'ai accès aux programmes et aux rép des machines distantes en console et en graphique