Dans cette dernière partie, nous allons finaliser notre mini-labo virtuel :
- Intégration des deux VM Debian (Core et GUI) dans le réseau interne virtuel LAN
- Connexion SSH sécurisée entre debian-gui (client) et debian-core (serveur)
- Fixation de l'IPv4 de debian-core sur
192.168.1.10/24.
Dans un premier temps il faut bien sûr veiller à ce que les trois machines soient démarrées.
Sur la console de la VM pfSense on voit que l’interface WAN a obtenu par DHCP une adresse IPv4, et que l’adresse IP sur la "patte" LAN est 192.168.1.1/24 :
La VM Debian GUI est connectée en NAT, son interface réseau a donc elle aussi obtenu par DHCP une adresse IPv4 depuis VirtualBox. On peut démarrer un terminal, et vérifier l’IP obtenue :
ip -c a
Cette commande nous donne (en couleur grâce à l’option -c) les adresses IP de chaque interface réseau du système.
Dans Terminator, avec la touche Ctrl et la molette de la souris, on ajuste la taille du texte dans le terminal.
¶ Connexion de DebianGUI au réseau LAN
Cette opération peut se faire "sous tension", comme on le ferait avec une machine réelle, en reconnectant le câble réseau. Depuis la configuration de la VM, on connecte l’interface réseau au LAN :
Il faut maintenant renouveler le bail DHCP de la VM GUI ; on peut par exemple redémarrer le service réseau :
sudo systemctl restart networking
ip -c a
Désormais notre Debian-GUI est sur le réseau LAN et a obtenu une IPv4 depuis pfSense.
¶ Connexion de Debian Core dans le LAN
Il faut également (re)démarrer la Debian Core, après l’avoir elle aussi reconnectée sur le réseau interne LAN :
¶ Vérification
Maintenant, les machines accèdent à internet via pfSense.
Debian-gui navigue sur le WEB :
Debian core accède elle aussi à Internet (ping d’un nom de domaine : résolu et joignable) :
ping -n -c 8 debian.org
On a également récupéré l’IP de la VM Debian Core avec la commande ip -c a ; par exemple ici 192.168.1.100. On peut constater qu’elle est joignable depuis la machine GUI :
ping -c 5 192.168.1.100
On voit que l’adresse IP de Debian-gui est 192.168.1.101 ; les ping vers 192.168.1.100 (debian-core) fonctionnent.
¶ Configuration SSH
Il est d'usage de ne pas intervenir directement sur la console d'un serveur, ou alors de façon exceptionnelle. On l'administre à distance, selon plusieurs techniques, une des plus courantes - dans le monde Unix - étant via une connexion SSH. Nous allons mettre en place une telle connexion entre le client (debian-gui) et le serveur (debian-core) de notre lab.
¶ Création d'un sudoer sur debian-core
Nous allons au préalable donner des droits de sudoer à l'utilisateur standard du serveur debian-core.
On se connecte en root sur debian-core, puis on installe le paquet sudo :
apt install sudo
Puis on ajoute l'utilisateur au groupe sudo (à adapter selon votre cas) :
adduser pascal sudo
¶ installation du serveur SSH
Toujours sur le serveur, on installe le paquet openSSH server :
apt install openssh-server
On ne modifie pas la configuration par défaut, qui prévoie notamment qu'on ne peut pas se connecter en SSH avec l'utilisateur root.
Pour information, ou rappel, le fichier de configuration du serveur ssh (ssh daemon) peut être modifié ainsi :
nano /etc/ssh/sshd_config
Ce qui peut être fait, par contre, c'est de sauvegarder une copie de ce fichier de configuration original :
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.original
Et on rend cette copie accessible en lecture seule (à tout le monde a on retire - le droit d'écriture w) :
chmod a-w /etc/ssh/sshd_config.original
¶ installation du client SSH
Désormais, on se positionne sur la VM cliente, debian-gui, pour installer le client SSH. Attention, sur le client, on est toujours connecté avec l'utilisateur standard, c'est pour cela qu'il faut sudo devant les commandes qui demandents des droits de super-utilisateur :
sudo apt install openssh-client
Ensuite, pour pouvoir réaliser des connexions ssh sans mot de passe, on va utiliser le mécanisme à base de clé publique / clé privée.
On génère une paire de clé RSA de 4096 bits :
ssh-keygen -t rsa -b 4096
NB : le processus va vous demander l'emplacement des clés et un mot de passe pour protéger la clé privée, vous pouvez ne rien saisir à chaque fois. (Les clés sont enregistrées par défaut dans le répertoire ~/.ssh/)
Il reste à transférer la clé publique sur le serveur, dont l'IP est ici 192.168.1.100 :
ssh-copy-id pascal@192.168.1.100
Le mot de passe de l'utilisateur sur debian-core vous sera demandé, juste cette fois. Il vous est aussi demandé d'accepter ce nouveau serveur comme "serveur connu", identifié par son empreinte unique. Ce qui signifie entre autres que si vous vous connectez ultérieurement à un autre serveur qui a la même IP ou le même nom, il y aura un refus de connexion, fondé sur une possible usurpation d'identité (Man In The Middle). Cette situation peut se produire en mode labo et une parade assez brutale (mais acceptable en test) est de supprimer le fichier des hôtes connus sur le client :
rm ~/.ssh/known_hosts
On peut maintenant se connecter sur le serveur sans mot de passe :
ssh pascal@192.168.1.100
Depuis le terminal on administre désormais le serveur debian-core (debian) et non plus la machine locale (debian-gui) :
¶ Fixation de l'IP de debian-core
Pour finir, on va fixer l’adresse IPv4 du serveur debian-core sur son interface unique (on est toujours connecté dessus en ssh) :
sudo nano /etc/network/interfaces
Habituellement, avec VirtualBox et la configuration par défaut du matériel réseau, l'interface réseau s'appelle
enp0s3; cependant, ceci peut varier, adaptez selon le nom de l'interface que vous trouverez dans le fichier.
Sur l'interface enp0s3 (lignes 11 et 12) : ip fixe 192.168.1.10/24 (ligne 13) et la passerelle 192.168.1.1 (ligne 14) :
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug enp0s3
iface enp0s3 inet static
address 192.168.1.10/24
gateway 192.168.1.1
On configure également les serveurs DNS utilisés :
sudo nano /etc/resolv.conf
avec les deux serveurs publics réputés de CloudFlare (par exemple) :
nameserver 1.1.1.1
nameserver 1.0.0.1
Et enfin on redémarre le serveur :
sudo reboot
Une fois le serveur relancé, on s'y reconnecte en ssh :
ssh pascal@192.168.1.10
Un message d'alerte devrait apparaître car l'adresse IP de ce serveur connu a changé, on peut répondre "yes" :
The authenticity of host '192.168.1.10 (192.168.1.10)' can't be established.
ED25519 key fingerprint is SHA256:Sxhqvm7aCr0RwVsXi0asgWUtJJekal7Zy19HT30/qVM.
This host key is known by the following other names/addresses:
~/.ssh/known_hosts:1: [hashed name]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
On lance une mise à jour (il n'y aura probablement rien de nouveau à ce stade, mais c'est une bonne pratique) :
sudo apt update && sudo apt upgrade
Pour se déconnecter (de la session ssh ou d'un terminal en général), on tape simplement CTRL+D ou bien :
exit
¶ Tout est en place !
Notre mini-labo est prêt pour ses premières expériences.
Je vous recommande de faire un cliché instantané (snapshot) de chacune des VM à ce stade. En effet, ceci permettra pour chaque TP de pouvoir repartir de ce point initial.