Bonjour,
J’ai 2 cartes réseau sur mon serveur et une ne fonctionne plus.
Si je change la carte usagée, est ce que la debian va se paramétrer automatiquement ?
Si non quelles sont les manips à effectuer ?
lspci?
Il y a essentiellement le fichier /etc/udev/rules.d/70-net-persistent.rules (ou qque chose de ce type= pour le nom de l’interface, c’est tout je pense.
Plus précisément, udev génére ce fichier pour que eth0 et eth1 ne risquent pas d’être intervertis à chaque boot. Udev va voir arriver une nouvelle carte, dans le fichier il va générer une règle pour eth2.
Dans ton /etc/network/interfaces il n’y a pas d’interface eth2 configurée donc ton interface ne montera pas au 1er boot. Tu pourrais faire un ifconfig eth2 à la main, pour vérifier que la carte fonctionne bien. Si tu ne vois pas d’eth2 ou d’eth3 (“ifconfig -a”), il te manque un module, mais plus probablement un firmware. Si tu es sous Squeeze, un truc du style “apt-get firmware-realtek” après avoir rajouté “non-free” dans les sources de Apt (vois /etc/apt/) doit régler ce cas.
Ensuite, si on considère que c’est eth1 qui a passé l’arme à gauche:
- virer l’entrée nommée eth1 dans le fichier 70-net-persistent.rules,
- remplacer “eth2” par “eth1” dans le fichier,
- rebooter
Et ta config réseau doit être revenue sans problème.
Evidemment, nouvelle carte = nouvelle adresse MAC, tu peux avoir des ajustements à faire dans ta config réseau (bridging, firewall ?), ou bien tu verra SSH se plaindre un peu au début. Si tu as un soucis de WOL, vois ce que dit ethtool sur la nouvelle carte.
J’ai cherché la petite bête mais globalement ça doit être une opération sans soucis.
Même si elles ne sont pas chères je ne suis pas fanatique des cartes à base de chip Realtek. Salade de firmwares avec Broadcom. Jamais déçu par les Intel filaires.
Ça dépend de ce que tu entends par “se paramétrer automatiquement”.
Ça dépend de ce que tu souhaites obtenir.
Non, pas forcément. Par exemple, sur station Sun, il y a une adresse MAC “globale” propre à la machine qui s’impose à chaque interface ethernet. (Je ne vous dis pas comment udev est paumé face à deux interfaces dans ce cas de figure !)
Se plaindre de quoi au juste ? SSH ne s’occupe pas de l’adresse MAC.
Merci pour vos réponses.
Plus qu’à faire 
Mais si mais si.
Si tu te reconnectes à une machine déjà connue, que sont nom résoud pareil qu’avant, son IP n’a pas changé, mais la MAC address a changé, alors le client SSH braille sur le thème d’une attaque MiM (sorry, je ne connais pas le nom en français!).
A ce moment-là, moi je vais bricoler dans ~/.ssh/known_hosts pour enlever l’ancienne ligne. Et hop, je peux me jeter dans les bras de l’usurpateur.
Pourtant ssh et putty n’ont pas braillé après que j’ai migré mon routeur Debian sur une nouvelle machine, avec une adresse MAC différente. Et je ne vois pas commment le client SSH pourrait avoir accès à l’adresse MAC du serveur. D’une part ce que tu écris n’a aucun sens car SSH fonctionne sur la couche TCP/IP, pas ethernet, et d’autre part l’adresse MAC des paquets reçus est celle du dernier noeud qui les a retransmis. Autrement dit, si le client et le serveur ne sont pas sur le même réseau ethernet, tout ce que voit le client c’est l’adresse MAC de son routeur, pas celel du serveur.
c’est un peu hors sujet, mais c’est une discution intéressante.
J’ai constaté que si je réinstalle entièrement une debian sur une machine, avec exactement les même paramètres, ssh ne veut plus se connecter dessus si je ne supprime pas la ligne dans le fichier des host connus.
Et je ne comprends pas pourquoi.
[quote=“piratebab”]J’ai constaté que si je réinstalle entièrement une debian sur une machine, avec exactement les même paramètres, ssh ne veut plus se connecter dessus si je ne supprime pas la ligne dans le fichier des host connus.
Et je ne comprends pas pourquoi.[/quote]
À l’installation le serveur SSH génère une paire de clés correspondant à la machine (/etc/ssh/ssh_host_*_key).
Le client SSH associe la clé publique du serveur à son adresse IP pour vérifier que le serveur n’a pas été compromis.
Quand tu réinstalles SSH (donc également quand tu réinstalles Debian) la paire de clés du serveur change et le client SSH croit que le serveur a été compromis, d’où le refus de se connecter.
Pourtant ssh et putty n’ont pas braillé après que j’ai migré mon routeur Debian sur une nouvelle machine, avec une adresse MAC différente. Et je ne vois pas commment le client SSH pourrait avoir accès à l’adresse MAC du serveur. D’une part ce que tu écris n’a aucun sens car SSH fonctionne sur la couche TCP/IP, pas ethernet, et d’autre part l’adresse MAC des paquets reçus est celle du dernier noeud qui les a retransmis. Autrement dit, si le client et le serveur ne sont pas sur le même réseau ethernet, tout ce que voit le client c’est l’adresse MAC de son routeur, pas celel du serveur.[/quote]
Bonne réponse de Syam.
Je pensais qu’un changement de cartes influait sur les clés locales au serveur. Mais je viens justement de faire la manoeuvre (carte PCI->carte intégrée, reboot), et mon client SSH ne s’est pas plaint. Donc j’ai dit une bêtise, on dirait.
Ces clefs sont dans /etc/ssh, il suffit de les récupérer et de les mettre dans la nouvelle machine. Comme le dit Pascal, l’adresse MAC n’a rien à voir.