[ssh] Éviter l'alerte SPOOFING avec +sieurs ditros [RÉSOLU]

[kozaki]

soit une machine distante avec qlqs OS dessus : mon portable (dessus y-a Arch, Debian, Mandriva)
À la maison j'y accède le + souvent par ssh depuis le desktop

- généré la clé dsa sur le desktop ;
- copié cette clé (~/.ssh/id_dsa.pub) vers chaque OS sur le pc_portable (~/.ssh/authorized_keys)

Les options du /etc/ssh/sshd_config sur chaque OS du portable :

Code : Tout sélectionner

RSAAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

C'est insuffisant puisqu'il y a une alerte SPOOFING à chaque connexion :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The RSA host key for [pc_portable] has changed,
and the key for the according IP address 192.168.x.xx
is unchanged. (...)

Y-a-t'y un moyen pour que sshd ai la même ID quelque soit la distro ?

[vincentxavier]

Il faut créer une unique clef DSA pour tous les serveurs sshd de toutes les distros et configurer tous les démons ssh pour utiliser cette même clef (sshd_config(5))

[kozaki]

vincentxavier c'est ce que j'ai cru faire en faisant ça :
- généré une clé dsa (sur le desktop) ;
- copié cette clé (~/.ssh/id_dsa.pub) vers chaque OS sur le pc_portable (~/.ssh/authorized_keys)
et en configurant sshd_config :

Code : Tout sélectionner

RSAAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys
UsePAM no

Peut-être j'ai oublié ou mal fait une manip en amont. Tiens sur la machine distante, j'ai uniquement $HOME/.ssh/{authorized_keys,known_hosts}
et sur le client, $HOME/.ssh/{id_dsa,id_dsa.pub,known_hosts}

[vincentxavier]

Non, il s'agit de

Code : Tout sélectionner

# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

ces directives qui sont au début du fichier de configuration de sshd.

[kozaki]

merci vincentxavier
L'alerte persiste après que j'ai nettoyé le ~/.ssh/known_hosts, copié ma clé dsa dans le rép /etc/ssh/ssh_host_dsa_key de chaque distro sur la machine distante, & relancé sshd.
/me

[vincentxavier]

Heu c'est pas encore ça. En fait, pour faire simple, quand tu te connectes à un serveur ssh, il commence par envoyer sa clef dsa au client. Le client compare la clef dsa qu'il vient de recevoir à celle qu'il a (éventuellement déjà) reçue pour vérifier que l'ip correspond bien.
L'idée est donc que toutes les distros utilisent la même clef. Donc il faut placer la clef dans un répertoire lisible par toutes les distros (mais que en root ou l'user qui lance sshd) et que cette clef serve tous les serveurs. En supposant que /mnt/share soit la partition accessible depuis toutes les distros, on aurait

Code : Tout sélectionner

user@machine:$ ls -lh /mnt/share/sshd
-rw------- 1 root root  668 jui 28  2007 ssh_host_dsa_key
-rw------- 1 root root  603 jui 28  2007 ssh_host_dsa_key.pub
-rw------- 1 root root  528 jui 28  2007 ssh_host_key
-rw------- 1 root root  332 jui 28  2007 ssh_host_key.pub
-rw------- 1 root root 1,7K jui 28  2007 ssh_host_rsa_key
-rw------- 1 root root  395 jui 28  2007 ssh_host_rsa_key.pub

et

Code : Tout sélectionner

# HostKeys for protocol version 2
HostKey /mnt/share/ssh/ssh_host_rsa_key
HostKey /mnt/share/ssh/ssh_host_dsa_key

dans tous les sshd_config de toutes les distros.

Ainsi quelque soit la distro qui tourne, le serveur ssh s'identifiera de la même façon !!!

[kozaki]

ah ok très clair vincentxavier
Mais un des principes de ssh n'est-il pas que la clé privée soit uniquement sur son poste client, et de passer la clé publique au serveur ?
Dans ce cas de figure là (à cause des distros variées sur leportable) l'original est créé et demeure sur le serveur ?

[vincentxavier]

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.

Je suis de moins en moins sur de comprendre ton souci aussi je vais essayer de le récapituler.

Tu possèdes un ordinateur (appellons le serveur_ssh_<distroname>) qui possède plusieurs distros. Lorsque tu te connectes à serveur_ssh_mandriva, il te dit "Warning: Permanently added 'serveur_ssh_mandriva' (RSA) to the list of known hosts.". Puis tu es pris de remord et tu veux une vraie distro, donc tu reboote sous ArchLinux et là lorsque tu te connectes à serveur_ssh_archlinux, il te dit Warning SPOOFING blah blah blah …

En fait, quand tu inities ta connexion ssh le serveur envoie sa clef publique au client pour que le client soit sur que c'est le bon serveur. Et si la clef qui est envoyé par le serveur ne correspond pas à celle qui est enregistrée, y'a un warning SPOOFING. Sauf que dans ton cas, c'est pas du spoofing, c'est des serveurs ssh que tu controles. C'est donc pour cela qu'il faut qu'ils aient les même clefs RSA et DSA pour que la clef d'authentification ne dépende pas du fait que tu es sur serveur_ssh_archlinux ou sur serveur_ssh_mandriva

J'espère que j'ai été clair et que tu as compris ce qui se passe.

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

[kozaki]

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

[vincentxavier]

Je te conseille la lecture de http://lea-linux.org/cached/index/Reseau-secu-ssh.html#

[kozaki]

l'article de lea-linux est bon (comme d'hab), mais soit j'ai du pâté dans les yeyux soit il précise pas le rôle des clés serveur ssh

Invalidité des clefs d'un hôte connu :
(...)
* La dernière et néanmoins plus plausible des solution nécessite que l'administrateur du serveur distant ait changé les clefs.

bah vi mais lesquelles ?? Parce-que tant qu'ils précisent pas on peu lire n fois sans piger qu'il s'agit des "ssh_host_{dsa,rsa}_key"
Même topo sur les articles SSH mentionés sur mon blog

[vincentxavier]

Heu, ca semble plutot logique !!
Il n'est pas obligatoire d'avoir une clef pour un utilisateur, en revanche tout serveur à une clef !!