Faites appel à PCsoleil informatique pour votre maintenance
Professionnel depuis dix ans dans le Centre-Var, basé à Brignoles
06.28.07.77.83 ou par E-mail
Sommaire
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, DynDNS à 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
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
Espace OVH, onglet Public Cloud> Créer Instance 4.99€ HT/mois. Image choisie Ubuntu, sans réseau privé ni disque additionnel. C’est ici: Public Cloud : Solutions Cloud et ressources à la demande – OVH (ovhcloud.com).
Renseigner la clef publique créée précédemment (notée dans le fichier texte id_rsa.txt par copier-coller: Ca y est, 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.
Par défaut: 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é).
Configurer l'instance OVH depuis le Système en local
Connexion SSH sans mot de passe à l'instance OVH depuis système en local
ssh USER_INSTANCE_OVH@IP_INSTANCE_OVH
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éé une connexion SSH avec clefs du Système en local vers l’instance OVH, on va créer une connexion authentifiée par clefs de l’instance OVH vers système en 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 rapatrier la clef publique sur le bureau de l’utilisateur du Système en local avec SFTP.
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.
Depuis le terminal
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
Avec 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. Sans rentrer dans les détails 700 ouvre tous ces droits à l’USER_SYSTEM_LOCAL seulement.
sudo chmod -R 700 /home/USER_SYSTEM_local/.ssh/
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
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
Ca lance l’éditeur de texte nano en ligne de commande (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; Ouvrir le terminal et taper: sudo passwd root
Renseignez le mot de passe de l’utilisateur courant, 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.
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 -o "ServerAliveInterval 10" -o "ServerAliveCountMax 3" -C -i /home/USER_SYSTEM_LOCAL/.ssh/id_rsa -N -R \*:22222:localhost:22 USER_INSTANCE_OVH@IP_INSTANCE_OVH
[Install]
WantedBy=multi-user.target
Explications:
- User= L’exécution de autossh est faite sous le compte USER_SYSTEM_LOCAL.
- 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.logpermettra de consulter ce log avec un défilement automatique. - 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.
- ServerAliveInterval 10= Toutes les 10 secondes, le Système en local envoie un signal (paquet nul) à l’instance OVH pour maintenir le tunnel SSH.
- ServerAliveCountMax 3= Si au bout de 3 tentatives infructueuses l’instance OVH ne répond pas, le service SSH est relancé pour tenter de rétablir le tunnel.
- -C= Les données sont compressées (Pas utile ici mais en cas de sites Web hébergé sur le Système en local oui).
- -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.
- -N= Dit à autossh de ne faire que rediriger les ports (ici 22222 vers 22).
- -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.
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). - 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.
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).
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.
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 -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 prend 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 et 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, re-cliquer 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 -N -R \*:8080:localhost:80 -p 22275 USER_INSTANCE_OVH@IP_INSTANCE_OVH
[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 -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).
