SSH Everywhere Architektur & Technologie-Stack

> Dieser Artikel erklärt die Gesamtarchitektur von SSH Everywhere sowie die verwendeten Protokolle und den Technologie-Stack in verständlicher Sprache. Er richtet sich an Leser, die wissen möchten, „wie es tatsächlich funktioniert“ – technisches Vorwissen ist nicht nötig.

---

Das gesamte Projekt in einem Satz verstanden

SSH Everywhere ist ein einheitliches Panel für die Fernwartung von Servern und Geräten, vergleichbar mit 1Panel / aaPanel. Seine Kernfähigkeit: Egal, wo dein Gerät im Netzwerk steht – ob mit öffentlicher IP, ohne öffentliche IP (hinter NAT) oder als Android-Handy – du kannst es aus diesem einen Panel heraus wie über SSH verwalten.

Das Panel selbst läuft auf einem Server mit öffentlicher IP (lauscht auf 0.0.0.0:5501). Du greifst über den Browser auf das Panel zu, und das Panel erreicht über verschiedene „Verbindungsarten“ jedes Zielgerät.

---

Gesamtarchitektur (auf einen Blick)

┌─────────────────────────────────────────────────────────────┐
│  Browser-Frontend (Single-Page-App, simuliert ein Desktop-OS)│
│  Desktop-Fenster · Taskleiste · Startmenü · Karten-Dashboard │
│  · Echtes Terminal · Icon-Bibliothek · reines Vanilla-JS (kein Framework) │
└──────────────────────────┬──────────────────────────────────┘
                           │ HTTP REST + SocketIO
┌──────────────────────────┴──────────────────────────────────┐
│  Panel-Backend (Flask + Flask-SocketIO, Python)             │
│  Hauptprogramm · Reverse-Tunnel-Server · SocketIO-Server · Dateitransfer │
│  Absturzschutz · Website-Verwaltung · Backup · SQLite-Datenbank │
└───┬───────────────┬──────────────────┬──────────────────────┘
    │ SSH           │ Reverse-Tunnel   │ SocketIO
    │ direkt/über   │ (0.0.0.0:4433)   │ (über HTTP)
    │ den Tunnel    │                  │
    ▼                ▼                  ▼
┌──────────────┐  ┌──────────────────┐  ┌─────────────────┐
│ Server mit   │  │ Linux/NAS/       │  │ Android-Handy   │
│ öffentlicher │  │ Raspberry Pi     │  │ (Termux)        │
│ IP           │  │ ohne öffentl. IP │  │                 │
└──────────────┘  └──────────────────┘  └─────────────────┘

---

Vier Verbindungsarten (Protokolle)

SSH Everywhere verwendet intern 4 Protokolle, jedes mit eigener Aufgabe, für unterschiedliche Gerätetypen:

1. SSH – der Hauptkanal

Zweck: die Kernfunktionen zur Verwaltung aller „normalen Linux-Server“.

Systemverwaltung (Übersicht, Prozesse, Geplante Aufgaben, Firewall, Docker, Website-Verwaltung, Image-Quellen, Absturzschutz)
Terminal (interaktive Shell)
Dateiverwaltung (hochladen/herunterladen/bearbeiten/komprimieren)
Zustandsprüfung (CPU/Arbeitsspeicher/Festplatte/Temperatur)
Befehlsausführung

Verbindungsarten:

Mit öffentlicher IP: Das Panel verbindet sich direkt mit host:port
Ohne öffentliche IP: Das Panel baut zuerst über den Reverse-Tunnel einen lokalen Proxy-Port auf und verbindet sich dann per SSH

> Anders gesagt: Der Kern des Reverse-Tunnels ist es, „SSH zu Geräten ohne öffentliche IP zu bringen“ – SSH ist also das Protokoll, das am Ende auf dem Gerät landet.

2. Reverse-Tunnel-Protokoll – der Tunnelkanal

Zweck: „Geräte ohne öffentliche IP“ für das Panel erreichbar machen. Die Geräteseite verbindet sich aktiv „nach außen“ zum Panel und baut eine langlebige Reverse-TCP-Verbindung auf; das Panel übermittelt über diesen Tunnel Befehle und leitet Ports weiter.

Merkmale: langlebige TCP-Verbindung + Verschlüsselung (AES-256-GCM), Server lauscht auf 0.0.0.0:4433.

Typische Szenarien:

SSH-Betrieb über Tunnel für Linux-Server ohne öffentliche IP (SSH läuft im Tunnel)
Port-Tunneling: einen Dienstport auf dem Gerät (z. B. 8090) auf einen öffentlichen Port des Panels abbilden

> Leicht zu verwechseln: Port-Weiterleitung vs. Port-Tunneling

> | | Port-Weiterleitung | Port-Tunneling |

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

> | Geeignetes Gerät | Server mit öffentlicher IP | Tunnel-Geräte ohne öffentliche IP |

> | Umsetzung | DNAT der System-Firewall, direkt auf dem Zielserver | über den Reverse-Tunnel |

> | Datenfluss | Besucher → öffentliche IP des Ziels → Zielport | Besucher → öffentlicher Panel-Port → Reverse-Tunnel → Geräteport |

> | Erfordert Gerät online | nein | ja (das Gerät muss den Agent online halten) |

> In einem Satz: „Weiterleitung“ ist für Server mit öffentlicher IP; „Tunneling“ ist für Geräte ohne öffentliche IP.

3. SocketIO – der Kanal speziell für Android-Handys

Zweck: Termux auf Android-Handys verwalten. Das NAT des Mobilfunknetzes wechselt häufig und SSH ist instabil, daher wird ein stabiler SocketIO-Long-Polling-Kanal verwendet (eine ausgereifte, in der Praxis erprobte Lösung).

Der Agent auf dem Handy bietet über SocketIO:

Systemverwaltung (Übersicht/Prozesse/Geplante Aufgaben)
Terminal (PTY-Brücke)
Dateiverwaltung
Zustandsüberwachung (meldet alle 30 Sekunden: Last/Arbeitsspeicher/Festplatte/Akku/Temperatur)

> Dies ist der einzige Kanal im Projekt, der „nicht über SSH läuft“ – denn Android-Handys nutzen kein sshd, sondern eine langlebige SocketIO-Verbindung.

4. HTTP REST – zwischen Frontend und Backend

Das Browser-Frontend ruft das Panel-Backend über die REST-API auf und nutzt zugleich SocketIO für die Echtzeit-Kommunikation in beide Richtungen, etwa im Terminal.

---

Wie die drei Gerätetypen erreicht werden

Gerätetyp	Verbindungsart	Letztes Protokoll auf dem Gerät	Hinweis
Linux-Server mit öffentlicher IP	direkte Panel-Verbindung	SSH	das direkteste Szenario
Linux-Server ohne öffentliche IP (NAS/Raspberry Pi usw.)	Reverse-Tunnel-Proxy → SSH	SSH (über den Tunnel transportiert)	der Tunnel ist der „Transporteur“ für SSH
Android-Handy (Termux)	SocketIO-Long-Polling	SocketIO (der einzige ohne SSH)	stabiler Kanal speziell für Handys

---

Datenspeicherung

SQLite-Datenbank (data/ssheverywhere.db): Serverkarten, Port-Weiterleitungen, Tunnel-Einträge, Benutzer, Aufgaben usw.
Dateisystem: Backup-Dateien, Tunnel-Schlüssel, statische Ressourcen.

---

Deployment-Form

Panel: systemd-Dienst ssh-everywhere.service, lauscht auf 0.0.0.0:5501.
Reverse-Tunnel: lauscht auf 0.0.0.0:4433.
Der Agent auf dem Zielgerät läuft dauerhaft als Dienst (systemd unter Linux / termux-services unter Termux).

---

Zum Projektnamen „SSH Everywhere“

Der Projektname SSH Everywhere bedeutet „überall verwaltbar, genau wie SSH“. SSH ist die mit Abstand wichtigste Verbindungsart des gesamten Projekts: Außer dem Teilbereich Android-Handy landen letztlich alle anderen Funktionen (Linux-Serververwaltung, Betrieb über Tunnel, Dateitransfer, Zustandsprüfung) bei SSH. Und der Kern des Reverse-Tunnels ist genau „SSH überallhin zu bringen“. Deshalb drückt der Name „SSH Everywhere“ die Kernfähigkeit des Projekts treffend aus.

Dokumentation