Avec une connexion ADSL Starlink ou 4G on n’a pas -comme traditionnellement- une Box internet dans laquelle on peut s’identifier et configurer une redirection NAT. Avec une BOX 4G, il est possible de prendre une adresse IP fixe, mais il y a un surcoût important: On passe à un abo. type pro; Airmob propose ça avec un offre de.. 50GO par mois pour 34€ HT (à ce jour 08/02/2022) Pourtant ils sont très compétitifs…

Il ne s’agit pas ici de simplement contrôler un terminal distant via SSH, mais de mettre en place un routage permanent qui permet d’accéder à n’importe quel service local (FTP, Web Server, Caméra, RDP, etc..) depuis l’extérieur, même vers un réseau local donc l’accès internet et en 4G/Starlink.

L’ accès Internet sur 4G/Starlink est de type CGnat: Face au manque d’adresses IP, les FAI sont contraints de partager la même @IP publique pour plusieurs abonnés, du coup plus de possibilité d’ouvrir des ports du WAN vers le LAN! Plus d’infos ici.

Reverse SSH utile sur une connexion internet classique?

Sur BOX 4G/Starlink on n’a pas le choix pour certaines services que de passer au Reverse SSH. Mais sur BOX « Classique »? Oui :

  • Stabilité: On ne craindra pas un reset ou changement de BOX qui casse la redirection NAT… Il n’y en pas! On peut se dire que -si on peut ouvrir un Terminal SSH en Reverse SSH- un port entrant est donc ouvert sur la BOX en NAT.. Mais non (J’ai testé). 
  • Facilité: On peut passer un pare-feu matériel en gardant des réglages très restrictifs sur ce pare-feu.
  • Sur une BOX gérée par un prestataire qui ne veut pas révéler les identifiants d’administration…
  • Sécurité: Pas de ports ouverts entrants sur la BOX.
  • Pas de solution type No-IP, Dyn DNS à mettre en place.

Environnement de travail

On suppose qu’Ubuntu a été installé sur PC dans le réseau local, et qu’un utilisateur de type Administrateur a été créé.
Cet article se base sur un PC sous Ubuntu mais un Raspberry sous Raspberry OS est préférable, cependant les manipulations seront les mêmes (peut-être quelques divergences mineures dans les commandes).

Dans cette article, l’utilisateur de Ubuntu local est nommé USER_SYSTEM_LOCAL; même principe pour d’autres notions comme l’adresse IP de l’instance OVH nommée @IP_INSTANCE_OVH. Donc dans les scripts tapez bien les vrais valeurs et pas les « alias ».

Sur le système en local (PC sous Ubuntu en réseau local)

Mise à jour de Ubuntu

Depuis le Terminal:
				
					sudo apt-get update
sudo apt-get upgrade
sudo reboot
				
			

Installer open-ssh

				
					sudo apt-get install openssh-server
				
			

Créer un jeu de clés privé/publique

Depuis un Terminal: Ne rien mettre en passphrase. La clef publique elle, est automatiquement créée dans le dossier /home/USER_SYSTEM_LOCAL/.ssh/ . Elle a pour nom id_rsa.pub par défaut.

				
					ssh-keygen -t rsa -b 4096

				
			

Copier la clef publique dans un fichier texte (pour plus tard) depuis le Terminal: On copie la clef publique dans un fichier sur le bureau de l’utilisateur du Système en local.

				
					cp /home/USER_SYSTEM_LOCAL/.ssh/id_rsa.pub /home/USER_SYSTEM_LOCAL/Bureau/id_rsa.txt
				
			

Sur Instance OVH

Création de l'instance OVH en ligne

S’identifier sur OVH puis onglet Public Cloud > Créer Instance (mais l’interface a pu changer entre temps) pour env. 5€ HT/mois avec le modèle le moins onéreux vu qu’il s’agit de ne traiter que du flux réseau. Image choisie Ubuntu, sans réseau privé ni disque additionnel. C’est ici: Créer instance OVH

Lors de la création de l’instance, une étape permet de renseigner la clef publique créée précédemment (notée dans le fichier texte id_rsa.txt): l’a renseigner. Si on a loupé cette étape, depuis son compte OVH aller dans « Project Managment > SSH Keys » depuis le panneau de gauche pour rajouter une clef.

On va pouvoir se connecter sans mot de passe sur l’instance OVH, depuis le « système en local ». On verra ça plus bas.

PS: Pour l’instant Ne pas configurer de Pare-Feu sur l’espace OVH (pour info c’est dans « Hosted Private Cloud » puis « IP » et clic sur 3 petits points en regard de l’@IP de l’instance OVH). Dans Ubuntu sur l’instance il n’y a pas par défaut de Firewall software configuré. L’onglet qui permet la connexion via VNC n’est pas à utiliser car elle demande un couple identifiant/mot de passe: La solution préférée ici est de s’identifier par clé publique.

NB: Cette configuration de l’instance OVH créé automatiquement un utilisateur administrateur nommé Ubuntu (c’est sans doute différent si on créé une instance Debian ou autre, pas testé).

Encore un possibilité pour renseigner la clef publique du SYSTEME_EN_LOCAL sur INSTANCE_OVH: La ligne de commande suivante

				
					ssh-copy-id USER_INSTANCE_OVH@IP_INSTANCE_OVH
				
			

Configurer l'instance OVH depuis le Système en local

Connexion SSH sans mot de passe à l'instance OVH depuis système en local

NB: Par défaut le nom de USER_INSTANCE_OVH est  ubuntu. De toute façon cette information est visible dans l’espace OVH en cliquant sur « Détails de l’instance ». Par défaut aussi, openssh-server est installé sur l’instance OVH, mais la leur politique change ou que vous utilisez un autre service, c’est pour rappel apt-get install openssh-server.

Un message dit d’accepter le « FingerPrint »: taper yes. Cette sécurité n’apparaît qu’une seule fois.

On est désormais connecté en SSH sur l’instance OVH: Les commandes ne s ‘exécutent plus sur le système en local mais sur l’instance OVH (tapez whoami (qui suis-je) vous verrez).

PS: C’est déroutant, mais à partir de là il faut penser comme si on était physiquement sur le Terminal de l’instance OVH, et faire abstraction du système en local.

De là même façon qu’on a créé un jeu de clef pour authentifier la connection du Système en local vers l’instance OVH, on va créer un autre jeu de clefs depuis l’instance OVH permettant l’authentification sur le système en local. Passez les étapes en réglages par défaut comme on a fait pour créer la clef dans le SYSTEME LOCAL.

				
					ssh-keygen -t rsa -b 4096

				
			

Là aussi ne rien mettre en Passphrase. Puis exit pour quitter le Terminal de l’instance OVH et repasser au contrôle du Système en local. On va se connecter à l’instance OVH, cette fois-ci avec à la commande SFTP.

Puis rapatrier la clef publique de l’instance OVH sur le bureau de l’utilisateur du Système en local:

bye pour fermer le tunnel SFTP (un peu plus sympa que exit pour fermer le tunnel SSH).

				
					sftp USER_INSTANCE_OVH@IP_INSTANCE_OVH
get .ssh/id_rsa.pub /home/USER_SYSTEM_LOCAL/Bureau/PubKeyInstance.txt
bye

				
			

Installer la clé publique de l'instance OVH sur le Système en local

En mode graphique

Un peu d’interface graphique enfin! On laisse le terminal de côté et on ouvre l’explorateur, clic sur « Afficher les fichiers cachés ». 

Puis on lance l’éditeur de texte et ouvre le fichier authorized_keys placé dans le dossier invisible  /home/USER_SYSTEM_LOCAL/.ssh/ on ouvre aussi le fichier PubKeyInstance.txt sur le bureau.
Il suffit de copier/coller le contenu de pubkeyinstance.txt dans le fichier authorized_keys (qui est en réalité un fichier texte sans extension) S’il y a déjà une clef de renseignée, faire d’abord un saut de ligne et après, coller.

Et pour ceux qui n’ont pas d’interface graphique sur le Système en local, voilà la marche à suivre. Grace à la commande SFTP du script précédent; le fichier pubkeyinstance.txt est sur le bureau de l’utilisateur du Système en local. 

La commande suivante MKDIR créé un dossier .ssh (s’il n’existe pas). option -p (Parent) pour dire de créer l’arborescence des dossiers. && pour dire de lancer une nouvelle commande à la suite c.-à-d. Créer avec TOUCH un fichier nommé authorized_keys dans le nouveau dossier .ssh

				
					sudo mkdir -p /home/USER_SYSTEM_LOCAL/.ssh/ && touch /home/USER_SYSTEM_LOCAL/.ssh/authorized_keys


				
			

Enfin on copie le contenu de pubkeyinstance.txt dans le fichier nouvellement créé authorized_keys avec la commande CAT. l’option >> permet d’ajouter du contenu sans effacer une éventuelle clé publique déjà existante et placer le contenu à la suite, sur une nouvelle ligne.

				
					sudo cat /home/USER_SYSTEM_LOCAL/Bureau/PubKeyInstance.txt >> /home/USER_SYSTEM_LOCAL/.ssh/authorized_keys

				
			

Avec la commande CHMOD, on rend l’USER_SYSTEM_LOCAL propriétaire du dossier .ssh et de tout ce qu’il y a dedans grâce à l’option -R (récursive). Il pourra donc ouvrir, lire, modifier, supprimer le dossier .ssh et tout son contenu.

Le fichier authorized_keys est lui aussi paramétré pour que l’USER_SYSTEM_LOCAL puisse lire et écrire ce fichier.

				
					sudo chmod -R 700 /home/USER_SYSTEM_LOCAL/.ssh/
sudo chmod 600 home/USER_SYSTEM_LOCAL/.ssh/authorized_keys


				
			

Configurer le serveur SSH sur l'Instance OVH

Du coup il faut se reconnecter en SSH à l’instance OVH pour l’a contrôler:

				
					ssh USER_INSTANCE_OVH@IP_INSTANCE_OVH
				
			

PS: Normalement openssh server est installé sur l’instance. Le cas contraire lancer en Terminal:
sudo apt install openssh-server

				
					sudo nano /etc/ssh/sshd_config
				
			

Cela lance l’éditeur de texte en ligne de commande  nano (PS: là aussi le fichier sshd_config est au bout du compte un fichier texte). Se déplacer dans le texte avec les touches fléchées. Modifier les informations ainsi:

  • GatewayPorts yes (autorise la liaison d’un port à une adresse IP ou DNS).
  • AllowTCPForwarding yes (permet la redirection un port vers un autre).
 
Pour sauvegarder avec nano: Clic en même temps sur CTRL+X puis clic sur touche y (ou o si nano est en Français), puis touche entrée. Exit pour sortir du Terminal contrôlant l’instance OVH.

S'identifier en tant que super utilisateur ROOT sur le Système local

Cela a va être nécessaire pour créer un service à démarrage automatique. Après s’être déconnecté de la session SSH de l’instance OVH en tapant exit; Ouvrir le terminal et taper: sudo passwd root
Renseignez le mot de passe de USER_SYSTEM_LOCAL, puis créez celui de l’utilisateur Root.
Taper su (pour changer de session sous le terminal et passer sur terminal Root) et renseignez le mot de passe que vous avez choisi pour ce dernier.

				
					sudo passwd root
# Rentrer password utilisateur courant (USER_SYSTEM_LOCAL)
# Créez le password de Root (super Admin sous Linux)
# su pour agir en tant que Root
su
# Demande du password de Root: tapez celui choisit précédemment
				
			

Installer autossh sur le Système en local et le configurer

				
					apt install autossh
nano /etc/systemd/system/autossh.service

				
			
Remplir le nouveau fichier créé par nano ainsi:
				
					[Unit]
Description=Tunnel permanent SSH
After=network.target
		
[Service]
User=USER_SYSTEM_LOCAL
Environment="AUTOSSH_LOGFILE=/home/USER_SYSTEM_LOCAL/Bureau/autossh.log"
Environment="AUTOSSH_GATETIME=0"
ExecStart=/usr/bin/autossh -M 20000 -i /home/USER_SYSTEM_LOCAL/.ssh/id_rsa -N -R \\*:22222:localhost:22 USER_INSTANCE_OVH@IP_INSTANCE_OVH -o "ServerAliveInterval 10" -o "ServerAliveCountMax 3"
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target
				
			

Explications:

  1. User= L’exécution de autossh est faite sous le compte USER_SYSTEM_LOCAL.
  2. AUTOSSH_LOGFILE= Un log d’autossh est créé sur le bureau pour vérifier s’il fonctionne. PS: La commande
    tail -f /home/USER_SYSTEM_LOCAL/Bureau/autossh.log permettra de consulter ce log avec un défilement automatique.
  3. AUTOSSH_GATETIME 0= Permet d’ignorer la première erreur ssh: Utile ici vu que autossh s’exécute au démarrage de l’instance OVH et que SSH n’a pas le temps de se lancer si tôt.
  4. -M 20000 = autossh envoie un signal loopback (à lui-même) en créant un 2eme tunnel SSH local composé d’octets nuls pour vérifier si autossh est capable d’ouvrir un tunnel, à la fréquence définie par les options ServerAlivexxx. Bien que cela ne vérifie pas la connectivité avec l’instance OVH, cette fonction vérifie si autossh est viable notamment lorsque le tunnel principal n’est pas fréquemment lancé: Si un problème local survient, autossh est redémarré. Le port 20000 est traditionnellement utilisé pour ceci avec autossh, et le signaux sont envoyés vers le port d’écoute 20000+1 (donc ici 20001) du Système en local.
  5. ServerAliveInterval et ServerAliveCountMax = Autossh vérifie si le tunnel est ouvert en envoyant un signal toutes les 10 secondes (Cf option -M). Si le tunnel ne répond pas, il essaie encore deux fois (donc 3 tentatives au total) par interval de 10 secondes. Si , au bout des ces 3 essais séparé par 10 secondes d’attente les signaux ne reviennent pas, autossh reboot le tunnel. Du côté de l’instance OVH nul besoin d’intaller autossh; le protocole SSH de l’instance comprend ces signaux par défaut.
  6. -i= Pour indiquer le chemin vers la clef publique. Normalement la clef publique utilisée par défaut est celle de l’utilisateur indiqué en ligne « User », mais je laisse par précaution.
  7. -N= Dit à autossh de ne faire que rediriger les ports (ici 22222 vers 22).
  8. -R= Configuration de la redirection en reverse-ssh pour créer un tunnel « distant » (à contrario d’un tunnel local sur le même réseau). NB: Ici le reverse-ssh est configuré pour cibler le Système en local, mais si on a sur le réseau local un autre PC qui fait tourner un service qu’on souhaite accessible depuis l’extérieur rien n’empêche de le faire. Ex: -R \*:22222:192.168.1.25:22 où 192.168.1.25 est l’@IP de cet autre PC.
  9. Le signe * est échappé par deux \\ pour ne pas être considéré comme faisant partie de la commande.
  10. localhost: en terme simple localhost veut dire « l’adresse IP de cet ordinateur ». J’aurais pu rentrer l’@IP du système en local mais utiliser l’alias localhost me permettra si besoin de changer l’@IP du système en local sans retoucher le script.
    En indiquant \\* comme interface réseau, on met en écoute le port 22222 sur toutes les interfaces réseau de l’instance OVH (précaution au cas où ce dernier aurait plusieurs interfaces réseau -virtuelles ou pas).
  11. USER_INSTANCE_OVH@IP_INSTANCE_OVH= C’est les paramètres de connexion SSH pour se connecter à l’instance OVH depuis le Système en local.
  12. Les options Restart servent à la résilience du service autossh.service: Si pour une raison quelconque (processus tué, bug passager) autossh.service est arrêté, ce service est relancé, et encore relancé indéfiniment toutes les 10 s si les tentatives précédentes ont échouées.

Après ceci nous redémarrons à distance l’instance OVH pour être certain qu tous les paramètres sont acitfs

				
					ssh USER_INSTANCE_OVH@IP_INSTANCE_OVH
sudo reboot
				
			

Pseudo-Faq

 Pourquoi on installe le serveur SSH (openssh-server) sur le système en local? parce qu’il est non joignable de l’extérieur en temps normal: C’est donc lui qui doit faire tourner le serveur SSH + autossh et envoyer automatiquement et régulièrement à l’instance OVH la config. du tunnel pour ne pas que le tunnel se ferme.

Pourquoi pas de pare-feu ni de fail2ban? La configuration est assez difficile comme ça; On verra à la suite comment faire pour le Pare-feu de l’instance OVH. Concernant l’outil Fail2ban il n’est utile que pour les attaques brute force avec identifiants… Comme la connexion SSH ne pourra (voir suite article) se faire qu’avec clefs SSH il est inutile.

C’est quoi ce port 22222 dans le script autossh.service? Le script autossh.service ordonne à l’instance OVH la chose suivante: Si un PC « externe » envoie une requête sur le port 22222 de l’@IP de l’instance OVH, elle doit être redirigée sur le port 22 de localhost; comme le script est lancé par le « système en local », localhost correspond à l’@IP du système en local: la requête en port 22222 abouti au port entrant 22 du système en local. On comprend alors qu’il est très possible de ne pas rediriger ce flux vers le Système en local mais vers l’@IP + Port d’un autre appareil du réseau local dont fait partie le Système en local.

Oui mais l’instance OVH ne connait pas les @IP du réseau locale? D’accord mais le Système en local oui.. Il fera le nécessaire.

Activer le service autossh au démarrage, et débogage au cas où

Sous le terminal du système en local, on tape su pour se logger en tant que Root puis:

				
					systemctl --now enable autossh.service

				
			

Pour connaitre l’état du tunnel SSH (ou plutôt reverse tunnel ssh) on peut utiliser tail sous terminal. Cela ouvre un terminal avec le log de autossh avec défilement automatique (option -f pour défilement auto).

NB: Si tail ne se lance pas, il faut installer en ligne de commande les utilitaires Ubuntu: apt-get install coreutils

				
					tail -f /home/USER_SYSTEM_LOCAL/Bureau/autossh.log


				
			

En cas de soucis de connexion, revoir la config. du script autossh.service avec l’éditeur nano; Mais d’abord en arrêtant le service autossh:

				
					systemctl stop autossh.service

				
			

Redémarrer le script:

				
					systemctl daemon-reload
systemctl start autossh.service

				
			

Se connecter via autossh au Système en local:

Du coup si, depuis un PC « client » je tape dans un Terminal:

				
					ssh -p 22222 USER_SYSTEM_LOCAL@IP_INSTANCE_OVH

				
			

Je vais contrôler en SSH le Système en local. Et non je ne me suis pas trompé en tapant USER_SYSTEM_LOCAL : Autossh exécuté sur le système en local a autorisé l’instance OVH à « utiliser » le compte exécutant Autossh. Par contre le mot de passe de USER_SYSTEM_LOCAL sera demandé à chaque fois qu’on voudra établir la connection via le tunnel reverse ssh.

 

Sécuriser la connexion sur l'instance OVH

Changer le port d'écoute SSH de l'instance

L’instance OVH est le point faible de cette installation vu qu’elle est directement exposée au WEB. On modifie le port SSH d’écoute de l’instance. Depuis un Terminal sur le Système en local:

				
					ssh USER_INSTANCE_OVH@IP_INSTANCE_OVH
sudo nano /etc/ssh/sshd_config

				
			

Le fichier sshd_config s’ouvre et on décommente la ligne port 22 en retirant le signe #, puis on remplace 22 par 22275 (ou ce que vous voulez du moment que ce n’est pas un port déjà utilisé ou standard). (Cf. https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml ).

Du coup il faut modifier le fichier autossh.service: Taper exit pour sortir de la session SSH sur l’instance, puis sudo systemctl stop autossh.service pour arrêter le service autossh . La ligne du script avec ExecStart est à modifier ainsi (attention de redémarrer le script après; Cf Chap. « Activer le service autossh au démarrage, et débogage au cas où »).

				
					sudo nano /etc/systemd/system/autossh.service
ExecStart=/usr/bin/autossh -o "ServerAliveInterval 10" -o "ServerAliveCountMax 3" -C -i /home/USER_SYSTEM_LOCAL/.ssh/id_rsa -M 20000 -N -R \*:22222:localhost:22 -p 22275 USER_INSTANCE_OVH@IP_INSTANCE_OVH

				
			

Interdire la connexion par identifiants

Là par contre il faut faire attention; En effet si on perd la clé SSH, ou qu’Ubuntu casse quelque chose lors d’une mise à jour, vous n’aurez plus accès à l’instance OVH même par identifiants. A cogiter si ce qu’on veut mettre en place ne demande pas une sécurité trop élevée. Ici je prends le contrôle en SSH de l’instance OVH (avec du coup le nouveau port 22275); Je modifie le fichier de config. sshd_config pour interdire le login via identifiants, et la connexion via SSH Root.

				
					ssh -p 22275 USER_INSTANCE_OVH@IP_INSTANCE_OVH
sudo nano /etc/ssh/sshd_config


				
			

sshd_config ouvert, on modifie et décommente le cas échéant les réglages ainsi:

  • PermitRootLogin no
  • PasswordAuthentification no
Comme toujours CTRL+X pour sortir, Y ou O pour sauvegarder le fichier, puis Entrée, enfin relancer SSH:
				
					systemctl daemon-reload
systemctl reload ssh.service
				
			

Configurer le pare-feu sur l'espace en ligne OVH

Oui c’est bien dans l’espace en ligne OVH que ça se passe, et pas en ligne de commande sur l’O.S. Ubuntu de l’instance OVH (on pourrai mais je trouve l’interface OVH plus sympa).

Comme l’authentification SSH n’est désormais possible que par clefs, on ne risque pas grand-chose. Cela dit, restreindre l’accès aux ports (ici 22275, 22222) reste intéressant pour limiter la conso de bande passante des attaques (qui n’aboutirons pas)… Et si on veut consulter les logs SSH, ils seront moins pollués, du coup plus lisibles.

Aller sur https://www.ovh.com/manager/dedicated/#/ip . Clic sur les 3 petits points à droite de l’@IP de l’instance OVH et « Créer Firewall », puis Configurer:

  • Paramètres= Priorité 0 ou autres
  • Action= Autoriser
  • Port source et de destination= 22275
  • IP d’origine= Ne pas renseigner si vous voulez vous connecter depuis n’importe quel PC, IoT, NAS…
  • Fragments et Drapeau= Laisser tel quel

Faire pareil pour le port 22222 (le port ouvert par un « PC externe » vers l’instance OVH) en mettant une autre priorité (sinon la règle est refusée).

Ensuite retour à la page précédente, recliquer sur les 3 petits points et sur « Activer le Firewall ».

Rajouter un service

Configurer un accès ssh pour contrôler le Système en local depuis l’extérieur c’est bien, mais on peut très bien monter un serveur Web; serveur de fichier ou synchro; de backup… Que sais-je? Ici exemple avec un serveur Web Apache. Installer un serveur apache2 sur le Système en local (tuto ici) https://www.digitalocean.com/community/tutorials/how-to-install-the-apache-web-server-on-ubuntu-20-04-fr.

Créer un nouveau fichier de configuration nommé autossh_apache.service en le copiant d’après le modèle précédent (par commodité) et le modifier:

				
					su
cp /etc/systemd/system/autossh.service /etc/systemd/system/autossh_apache.service
nano /etc/systemd/system/autossh_apache.service
				
			

On retrouve ce qui était précédemment sur le fichier de config « autossh.config » puis on modifie la partie redirection de port. Apache tourne par défaut sur le port 80 du Système en local. On décide que le port d’écoute sur l’instance OVH est 8080. Voilà à quoi le fichier doit ressembler:

				
					[Unit]
Description=Tunnel reverse SSH accès Apache
After=network.target
		
[Service]
User=USER_SYSTEM_LOCAL
Environment="AUTOSSH_LOGFILE=/home/USER_SYSTEM_LOCAL/Bureau/autossh_apache.log"
Environment="AUTOSSH_GATETIME=0"
ExecStart=/usr/bin/autossh -o "ServerAliveInterval 10" -o "ServerAliveCountMax 3" -C -i /home/USER_SYSTEM_LOCAL/.ssh/id_rsa -M 20002 -N -R \*:8080:localhost:80 -p 22275 USER_INSTANCE_OVH@IP_INSTANCE_OVH
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target
				
			

Pour rappel: CTRL + X pour sortir; Y ou O pour sauvegarder le fichier autossh_apache.service, ensuite on relance les services modifiés. Enfin, avec la commande exit on quitte le mode Root.

				
					systemctl daemon-reload
systemctl --now enable autossh_apache.service
exit
				
			

Attention qu’il faut revenir à l’espace en ligne de l’instance OVH pour mettre à jour le Firewall en ouvrant le port 8080.

Après coup le serveur Web sur le Système en local sera disponible en tapant dans un navigateur: @IP_INSTANCE_OVH:8080. La nouvelle redirection inscrite dans le script va se charger de rediriger la requête sur le port 8080 de l’instance OVH vers le port 80 (port d’écoute pas défaut de Apache) de l’@IP du système en local.

Bureau à distance Windows 10 RDP avec Reverse SSH et autossh

J’ai montré comment accéder à des services sur le « Système en local ». Mais il est possible d’accéder depuis l’extérieur à d’autres services hébergés sur d’autres machines du réseau local (réseau local dans lequel fonctionne le Système en local bien sûr). Exemple ici avec un PC sous Windows 10 (ou 11) auquel on souhaite accéder en Remote Desktop Protocole.

On active sous Windows 10 le bureau à distance en laissant le port par défaut 3389: Paramètres Windows 10> Système> Bureau à distance. On note son @IP locale (ici je vais utiliser l’alias @IP_WIN10, à remplacer dans les scripts par la vrai @IP). Normalement, une règle de pare-feu Windows 10 autorisant les connexions entrantes sur le port 3389 est automatiquement créée; Attention si vous avez une solution de sécurité autres que Windows Defender qu’elle prenne bien en compte l’autorisation.

On recréé un fichier de config: autossh_rdp.service (en copiant le modèle comme précédemment).

				
					su
cp /etc/systemd/system/autossh.service /etc/systemd/system/autossh_rdp.service
nano /etc/systemd/system/autossh_rdp.service
				
			

Et là aussi on modifie la redirection (option -R) MAIS on va y renseigner l’adresse IP du Windows 10 au lieu de « localhost »!

				
					[Unit]
Description=Tunnel reverse SSH accès RDP
After=network.target
		
[Service]
User=USER_SYSTEM_LOCAL
Environment="AUTOSSH_LOGFILE=/home/USER_SYSTEM_LOCAL/Bureau/autossh_rdp.log"
Environment="AUTOSSH_GATETIME=0"
ExecStart=/usr/bin/autossh -o "ServerAliveInterval 10" -o "ServerAliveCountMax 3" -C -i /home/USER_SYSTEM_LOCAL/.ssh/id_rsa -M 20004 -N -R \*:22216:@IP_WIN10:3389 -p 22275 USER_INSTANCE_OVH@IP_INSTANCE_OVH
		
[Install]
WantedBy=multi-user.target
				
			

Je me répète= CTRL + X pour sortir; Y ou O pour sauvegarder le fichier autossh_rdp.service.
Et ensuite relance des services.

				
					systemctl daemon-reload
systemctl --now enable autossh_rdp.service
exit
				
			

Bis Repetita pour la configuration du pare-feu sur l’espace en ligne OVH.

Depuis un autre PC sous Windows 10, hors réseau local: Je cherche « Connexion bureau à distance ». L’appli apparait et j’y renseigne les infos suivantes (l’@IP de l’instance OVH est cachée par confidentialité). En se connectant, accepter le certificat (il n’est pas validé par une autorité de confiance).

Enième PS: J’aurais pu rentrer les différentes redirections dans un seul fichier autossh.service, mais j’ai trouvé plus claire de créer pour chaque service que l’on veut rendre accessible sur le Net, un peu comme cet extrait de code:

				
									ExecStart=/usr/bin/autossh -M 0 -i /home/USER_SYSTEM_LOCAL/.ssh/id_rsa -N -R \\*:2201:localhost:22 -R \\*:8080:localhost:80 USER_INSTANCE@IP_INSTANCE -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3"

				
			

Bréviaire

Voici un résumé des manipulations

				
					ETAPES:

	DEPUIS SYSTEM_EN_LOCAL ET INSTANCE_OVH
	
		# Installer au cas où il ne l'est pas openssh-server (ceci le met à jour en cas de besoin et si déjà installé)
			sudo apt install openssh-server				


	DEPUIS SYSTEM_EN_LOCAL:		
		
		# AUTHENTIFIER EN SSH SYSTEM_EN_LOCAL SUR INSTANCE_OVH
		
			# Créer jeu de cle SSH, ne rien mettre en passphrase, emplacement cle par defaut
				ssh-keygen -t rsa -b 4096
		
			# Créer une instance OVH et au moment de rentrer la clef publi, copier coller le contenu de id_rsa.pub 
			# placé dans /home/USER_SYSTEM_LOCAL/.ssh/ de SYSTEM_EN_LOCAL dans l'étape de l'installation de 
			# l'instance OVH le demandant
			# Accepter Fingerprint
				ssh INSTANCE_OVH@IP_INSTANCE

			# Quitter connexion SSH vers IP_INSTANCE
				exit
		
		
		# AUTHENTIFIER EN SSH INSTANCE_OVH SUR SYSTEM_EN_LOCAL 
		
			# Créer Clefs SSH sur INSTANCE_OVH en ouvrant une session SSH dessus
				ssh INSTANCE_OVH@IP_INSTANCE
				ssh-keygen -t rsa -b 4096
				exit
			
		
			# Connexion SFTP sur INSTANCE_OVH et copie clef publique INSTANCE_OVH sur Bureau SYSTEM_EN_LOCAL
				sftp INSTANCE_OVH@IP_INSTANCE
				get .ssh/id_rsa.pub /home/USER_SYSTEM_LOCAL/Bureau/PubKeyInstance.txt
			
			# Quitter SFTP
				bye
			
			# Copier le contenu de pubkeyinstance.txt dans /home/USER_SYSTEM_LOCAL/.ssh/authorized_keys en mode graphique
			# créer le fichier nommé autorized_keys s'il n'existe pas
			# S'il existe déjà une clef, Placer le contenu à la suite après un saut de ligne
			
			# Par prudence éditer les droits d'accès sur les dossiers et fichier de clefs
				sudo chmod -R 700 /home/USER_SYSTEM_LOCAL/.ssh/
				sudo chmod 600 /home/USER_SYSTEM_LOCAL/.ssh/authorized_keys
				
		
		# CONFIGURER SSHD_CONFIG SUR INSTANCE_OVH	

			# Se Reconnecter en SSH sur INSTANCE_OVH
				ssh INSTANCE_OVH@IP_INSTANCE

			# Editer en mode Admin le fichier sshd_config 
				sudo nano /etc/ssh/sshd_config
		
			# rajouter, modifier ou décommenter les lignes suivantes:
				AllowTcpForwarding yes
				GatewayPorts yes
				
			# Redemarrer SSH et SSHD (normalement que SSH est nécessairemais par sécurité...)
				sudo systemtcl restart ssh sshd

			# Quitter session SSH sur INSTANCE_OVH
				exit
			
		
		# INSTALLER ET CONFIGURER AUTOSSH SUR SYSTEM_EN_LOCAL
		
			# Installer autossh
				sudo apt install autossh
		
			# Configurer l'admin Root, rentrez le password choisi, et configurer autossh en mode root
				sudo passwd root
				su
				nano /etc/systemd/system/autossh.service
				
			# Remplir le fichier autossh.service. Le double \\ devant * est voulu pour échapper le caractère * 
			# pour qu'il soit compris littéralement et non pas comme faisant partie de la commande
			
				[Unit]
				Description=Tunnel permanent SSH
				After=network.target

				[Service]
				User=USER_EN_LOCAL
				Environment="AUTOSSH_LOGFILE=/home/USER_EN_LOCAL/Bureau/autossh.log"
				Environment="AUTOSSH_GATETIME=0"				
				ExecStart=/usr/bin/autossh -M 20000 -i /home/USER_EN_LOCAL/.ssh/id_rsa -N -R \\*:2201:localhost:22 USER_INSTANCE@IP_INSTANCE -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3"
				Restart=always
				RestartSec=10


				[Install]

				WantedBy=multi-user.target
				
			# Quitter et enregistrer autossh.service
				CTRL + X et choisir O ou Y pour Oui
				
			# Quitter la session terminal root pour revenir à la session Terminal USER_SYSTEM_LOCAL
				exit
			
			# Relire et recharger les services dans systemd
				sudo systemctl daemon-reload
				
			# Activer le service autossh.service
				sudo systemctl --now enable autossh.service
				
			# Rebooter INSTANCE_OVH
				ssh USER_INSTANCE@IP_INSTANCE
				sudo reboot
				
	
	DEPUIS PC VISITEUR
	
		# Imaginons qu'on est sur un PC dans un tout autre réseau local que les SYSTEME_EN_LOCAL et INSTANCE_OVH
		 Lacommande ci-dessous pert d'ouvrir une session SSH sur le SYSTEM_EN_LOCAL via le tunnel de INSTANCE_OVH
			ssh -p 2201 USER_SYSTEM_LOCAL@IP_INSTANCE