Architecture et pile technique de SSH Everywhere

> Cet article explique de façon simple l'architecture globale de SSH Everywhere, les protocoles utilisés et sa pile technique. Il s'adresse aux lecteurs qui veulent comprendre « comment ça marche réellement » : aucune connaissance technique n'est nécessaire pour le suivre.

---

Comprendre tout le projet en une phrase

SSH Everywhere est un panneau de gestion à distance tout-en-un pour serveurs et appareils, comparable à 1Panel / BaoTa. Sa capacité centrale : où que se trouve votre appareil sur le réseau — avec une IP publique, sans IP publique (derrière un NAT), ou même un téléphone Android — vous pouvez le gérer depuis ce seul panneau, exactement comme avec SSH.

Le panneau lui-même est déployé sur un serveur doté d'une IP publique (à l'écoute sur 0.0.0.0:5501). Vous accédez au panneau depuis votre navigateur, et le panneau joint ensuite chaque appareil cible via différents « modes de connexion ».

---

Architecture globale (comprendre en une image)

┌─────────────────────────────────────────────────────────────┐
│  Frontend navigateur (application monopage, simule un OS de bureau) │
│  Fenêtres de bureau · Barre des tâches · Menu démarrer · Tableau de bord │
│  · Vrai terminal · Bibliothèque d'icônes · JS natif pur (sans framework) │
└──────────────────────────┬──────────────────────────────────┘
                           │ HTTP REST + SocketIO
┌──────────────────────────┴──────────────────────────────────┐
│  Backend du panneau (Flask + Flask-SocketIO, Python)        │
│  Programme principal · Serveur de tunnel inverse · Serveur SocketIO │
│  Transfert de fichiers · Protection anti-plantage · Gestion de sites web │
│  Sauvegarde · Base de données SQLite                        │
└───┬───────────────┬──────────────────┬──────────────────────┘
    │ SSH           │ Tunnel inverse   │ SocketIO
    │ direct/via tunnel │ (0.0.0.0:4433) │ (via HTTP)
    ▼                ▼                  ▼
┌────────┐    ┌──────────────┐    ┌─────────────────┐
│ Serveur│    │ Linux sans IP │    │ Téléphone Android │
│ IP pub.│    │ /NAS/Raspberry Pi │  │ (Termux)        │
└────────┘    └──────────────┘    └─────────────────┘

---

Quatre modes de connexion (protocoles)

SSH Everywhere utilise en interne 4 protocoles, chacun avec son rôle, pour différents types d'appareils :

1. SSH — le canal principal

Usage : gérer les fonctions essentielles de tous les « serveurs Linux ordinaires ».

Gestion du système (vue d'ensemble, processus, tâches planifiées, pare-feu, Docker, sites web, miroirs, protection anti-plantage)
Terminal (shell interactif)
Gestion de fichiers (envoi/téléchargement/modification/compression)
Contrôle de santé (CPU/mémoire/disque/température)
Exécution de commandes

Modes de connexion :

Avec IP publique : le panneau se connecte directement à host:port
Sans IP publique : le panneau crée d'abord un port proxy local via le tunnel inverse, puis se connecte en SSH

> Autrement dit, l'essence du tunnel inverse est de « livrer SSH aux appareils qui n'ont pas d'IP publique », SSH est donc le protocole qui aboutit en dernier ressort sur l'appareil.

2. Protocole de tunnel inverse — le canal de percement

Usage : permettre au panneau d'atteindre les « appareils sans IP publique ». L'appareil se « connecte vers l'extérieur » au panneau de façon active, établissant une longue connexion TCP inverse ; le panneau fait descendre les commandes et redirige les ports à travers ce tunnel.

Caractéristiques : longue connexion TCP + chiffrement (AES-256-GCM), le serveur écoute sur 0.0.0.0:4433.

Cas typiques :

Tunnel et maintenance SSH des serveurs Linux sans IP publique (SSH tourne à l'intérieur du tunnel)
Tunnel de ports : mapper le port d'un service de l'appareil (par ex. 8090) vers un port public du panneau

> Concepts faciles à confondre : redirection de ports vs tunnel de ports

> | | Redirection de ports | Tunnel de ports |

> |---|---|---|

> | Appareils concernés | serveurs avec IP publique | appareils à percer sans IP publique |

> | Mise en œuvre | DNAT du pare-feu système, réalisé sur le serveur cible lui-même | via le tunnel inverse |

> | Flux de données | visiteur → IP publique cible → port cible | visiteur → port public du panneau → tunnel inverse → port de l'appareil |

> | Dépend de l'appareil en ligne | non | oui (l'appareil doit garder l'Agent en ligne) |

> En une phrase : la « redirection » sert aux serveurs avec IP publique ; le « tunnel » sert aux appareils sans IP publique.

3. SocketIO — le canal dédié aux téléphones Android

Usage : gérer Termux sur les téléphones Android. Le NAT des réseaux mobiles change fréquemment et SSH y est instable, on utilise donc un canal stable en longue interrogation SocketIO (une solution éprouvée sur de vrais appareils).

L'Agent exécuté sur le téléphone fournit via SocketIO :

Gestion du système (vue d'ensemble/processus/tâches planifiées)
Terminal (pont PTY)
Gestion de fichiers
Supervision santé (rapport toutes les 30 secondes : charge/mémoire/disque/batterie/température)

> C'est le seul canal du projet qui « n'utilise pas SSH » — car les téléphones Android n'utilisent pas sshd, mais une longue connexion SocketIO.

4. HTTP REST — entre le frontend et le backend

Le frontend du navigateur appelle le backend du panneau via l'API REST, tout en utilisant SocketIO pour les communications bidirectionnelles en temps réel comme le terminal.

---

Aperçu des chemins d'accès aux trois types d'appareils

Type d'appareil	Mode de connexion	Protocole final	Remarques
Serveur Linux avec IP publique	connexion directe du panneau	SSH	le scénario le plus direct
Serveur Linux sans IP publique (NAS/Raspberry Pi, etc.)	tunnel inverse crée un proxy → SSH	SSH (transporté via le tunnel)	le tunnel est le « transporteur » de SSH
Téléphone Android (Termux)	longue interrogation SocketIO	SocketIO (le seul sans SSH)	canal stable dédié aux téléphones

---

Stockage des données

Base de données SQLite (data/ssheverywhere.db) : fiches de serveurs, redirections de ports, enregistrements de tunnel, utilisateurs, tâches, etc.
Système de fichiers : fichiers de sauvegarde, clés de tunnel, ressources statiques.

---

Forme de déploiement

Panneau : service systemd ssh-everywhere.service, à l'écoute sur 0.0.0.0:5501.
Tunnel inverse : à l'écoute sur 0.0.0.0:4433.
L'Agent côté appareil cible reste résident sous forme de service (systemd sous Linux / termux-services sous Termux).

---

À propos du nom du projet « SSH Everywhere »

Le projet s'appelle SSH Everywhere, ce qui signifie « gérable partout, comme avec SSH ». SSH est de loin le mode de connexion principal de tout le projet : hormis le sous-scénario des téléphones Android, toutes les autres fonctionnalités (gestion de serveurs Linux, tunnel et maintenance, transfert de fichiers, contrôle de santé) aboutissent finalement à SSH. Et l'essence du tunnel inverse est précisément de « livrer SSH partout ». Le nom « SSH Everywhere » exprime donc exactement la capacité centrale du projet.

Documentation