Se connecter en SSH en NAT sous Linux

Redirections de ports et/ou reverse tunneling

La configuration est la suivante:

• un ordinateur local host@192.168.1.30 qui host une machine virtuelle sous Debian en NAT

• Une machine virtuelle en NAT sous Virtualbox en guest@10.0.2.15

Paquets et composants nécessaires

SSHD service

• l'installation et l'activation de sshd (inclus dans l'installation de Debian)

vérifier l'activation avec la commande suivante sur la machine hôte et invitée

sudo systemctl start sshd
sudo systemctl enable sshd

Redirection de port

La configuration de Virtualbox doit être modifiée de la façon suivante:

choisissez machine>paramètres

Allez dans la section "Réseau" des paramètres de la machine (1) puis allez dans les paramètres avancés (2) et sélectionnez la redirection de port (3) . Dans la redirection de ports, vous allez pouvoir lier le port de l'invité (le 22 qui est disponible) avec celui de l'hôte qui sera le 22222, non attribué et donc disponible pour une connexion en NAT.

Sachez que les adresses IP peuvent être remplacées par 0.0.0.0 afin de permettre de faire cette redirection avec des invités ou hôtes avec une adresse IP dynamique.

Lancer une session avec redirection de port

A partir de ce point, vous pouvez essayer de lancer la session SSH dans votre poste hôte

ssh guest@10.0.2.15 -p 22222

Créer un Reverse tunnel SSH

Le tunnel SSH fonctionnera en NAT de la même façon qu'avec un hôte distant par la réciprocité des connexions qui génèreront un tunnel bilatéral. Certains aspects de la procédure sont contre-intuitifs mais fonctionnent sur le principe de la poignée de main.

Côté machine invitée

Il faut faire la vérification que le service sshd fonctionne et est installé (sinon le package openssh-server doit être installé). Il faut d'abord lancer une session SSH depuis l'invité vers l'hôte mais de manière inversée:

[guest@10.0.2.15]$ ssh -R 22222:localhost:22 host@192.168.1.30

Validez la connection puis validez la session en entrant le mot de passe de la session hôte. Désormais, vous devriez être identifié en tant qu'utilisateur de la session "invitée" pour votre tunnel SSH.

[host@machine_locale]$ 

Côté machine hôte

Ceci doit être fait avec la session SSH précédemment décrite active:

Il faut lancer l'autre part du tunnel en ouvrant une session locale sur le port local en écoute qui reconduira vers la machine distante sur le modèle suivant, la session guest dooit bien être précisée:

ssh guest@localhost -p 22222

Vous devez normalement être désormais connecté en SSH à votre machine virtuelle en NAT ou réseau NAT.

Connexion avec échange de clés RSA

Pour sécuriser le tunnel de connexion, vous pouvez privilégier l'échange de clés RSA plutôt que la connexion par mot de passe. On va renforcer la clé avec un chiffrement de 4096 bits.

ssh-keygen -t rsa -b 4096

Le script ssh-keygen demandera un nom de clé (comme ici laclef) puis une phrase de passe qui sera le moyen d'accéder à la session. Désormais, il faut ajouter la clé comme identité de l'utilisateur, après avoir vérifié que le service ssh-agent fonctionne bien:

eval `ssh-agent -s`

puis saisir:

ssh-add laclef

La phrase secrète au moment de la génération vous sera demandée à nouveau. L'identité sera ajoutée ensuite. Saisissez bien votre clé privée d'ordinateur hôte.

En cas de problème, il faudra modifier la gestion des droits du fichier suivant:

chmod 600 /home/host/.ssh/authorized_keys

appliquez également la même règle de droits sur votre clé publique, au besoin. La question de droits peut bloquer cette procédure sur différents points. Ceci en plus des autorisations liés au protocole ssh à configurer dans le fichier suivant:

sudo nano /etc/ssh/sshd_config

autorisez les paramètres suivants en décommentant et modifiant au besoin:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

Finalement, vous pourrez copier la clé publique sur la machine virtuelle par la commande suivante:

ssh-copy-id -i laclef.pub guest@10.0.2.15

ATTENTION !

Dans certains cas, le script de ssh-copy-id ne fonctionnera pas sur l'une des deux machines si elle n'utilise pas la forme particulère de bash de Debian mais une autre. Bour régler ces soucis de compatibilité, il faudra modifier le fichier de script:

sudo nano /usr/bin/ssh-copy-id 

Puis changer la première ligne depuis :

#!/bin/sh vers #!/bin/bash

Dernier Recours:

En cas de doute, un reboot de service peut parfois s'imposer:

sudo systemctl restart sshd