SSH Everywhere Architecture & Tech Stack

> This article explains the overall architecture, protocols, and tech stack of SSH Everywhere in plain language. It is written for readers who want to understand "how it actually works" — no technical background required.

---

Understanding the Whole Project in One Sentence

SSH Everywhere is an all-in-one remote server/device management panel, comparable to 1Panel / BaoTa. Its core capability is: no matter where your device sits on the network — with a public IP, without a public IP (behind NAT), or even an Android phone — you can manage it from this single panel just like using SSH.

The panel itself is deployed on a server with a public IP (listening on 0.0.0.0:5501). You access the panel through a browser, and the panel then reaches each target device through different "connection methods".

---

Overall Architecture (at a Glance)

┌─────────────────────────────────────────────────────────────┐
│  Browser frontend (single-page app, simulated desktop OS)    │
│  Desktop windows · Taskbar · Start menu · Card dashboard     │
│  · Real terminal · Icon library · Pure vanilla JS (no framework) │
└──────────────────────────┬──────────────────────────────────┘
                           │ HTTP REST + SocketIO
┌──────────────────────────┴──────────────────────────────────┐
│  Panel backend (Flask + Flask-SocketIO, Python)             │
│  Main program · Reverse tunnel server · SocketIO server · File transfer │
│  Crash Prevention · Website Management · Backup · SQLite database │
└───┬───────────────┬──────────────────┬──────────────────────┘
    │ SSH           │ Reverse tunnel   │ SocketIO
    │ direct/via tunnel │ (0.0.0.0:4433) │ (over HTTP)
    ▼                ▼                  ▼
┌────────┐    ┌──────────────┐    ┌─────────────────┐
│ Public-IP │    │ No-public-IP Linux │    │ Android phone   │
│ server   │    │ /NAS/Raspberry Pi  │    │ (Termux)        │
└────────┘    └──────────────┘    └─────────────────┘

---

Four Connection Methods (Protocols)

SSH Everywhere internally uses 4 protocols, each with its own role, targeting different types of devices:

1. SSH — the Primary Channel

Purpose: the core feature for managing all "ordinary Linux servers".

System management (overview, processes, Cron Jobs, Firewall, Docker, Website Management, mirror sources, Crash Prevention)
Terminal (interactive shell)
File management (upload/download/edit/compress)
Health checks (CPU/memory/disk/temperature)
Command execution

Connection methods:

With a public IP: the panel connects directly to host:port
Without a public IP: the panel first creates a local proxy port via the reverse tunnel, then connects over SSH

> In other words, the essence of the reverse tunnel is "delivering SSH to a device without a public IP", so SSH is the protocol that ultimately lands on the device.

2. Reverse Tunnel Protocol — the Tunneling Channel

Purpose: lets "devices without a public IP" be reached by the panel. The device side actively "connects out" to the panel, establishing a reverse TCP long-lived connection; the panel delivers commands and forwards ports over this tunnel.

Characteristics: TCP long-lived connection + encryption (AES-256-GCM), server listens on 0.0.0.0:4433.

Typical scenarios:

Tunneling for SSH management of no-public-IP Linux servers (SSH runs inside the tunnel)
Port Tunneling: mapping a service port on the device (e.g. 8090) to a public port on the panel

> Easily confused concepts: Port Forwarding vs Port Tunneling

> | | Port Forwarding | Port Tunneling |

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

> | Applicable device | servers with a public IP | tunneling devices without a public IP |

> | Implementation | system firewall DNAT, performed on the target server itself | over the reverse tunnel |

> | Data flow | visitor → target public IP → target port | visitor → panel public port → reverse tunnel → device port |

> | Requires device online | no | yes (device must keep the Agent online) |

> In one sentence: "Forwarding" is for servers with a public IP; "Tunneling" is for devices without one.

3. SocketIO — the Android Phone Channel

Purpose: managing Termux on Android phones. Mobile network NAT changes frequently and SSH is unstable, so a stable SocketIO long-polling channel is used (a mature, battle-tested solution).

The Agent running on the phone provides, via SocketIO:

System management (overview/processes/Cron Jobs)
Terminal (PTY bridging)
File management
Health monitoring (reports every 30 seconds: load/memory/disk/battery/temperature)

> This is the only channel in the project that "does not use SSH" — because Android phones do not run sshd, but instead use a SocketIO long-lived connection.

4. HTTP REST — between Frontend and Backend

The browser frontend calls the panel backend through the REST API, while using SocketIO for real-time bidirectional communication such as the terminal.

---

How the Three Device Types Are Reached

Device type	Connection method	Final landing protocol	Notes
Linux server with a public IP	direct panel connection	SSH	the most direct scenario
Linux server without a public IP (NAS/Raspberry Pi, etc.)	reverse tunnel proxy → SSH	SSH (carried through the tunnel)	the tunnel is SSH's "carrier"
Android phone (Termux)	SocketIO long polling	SocketIO (the only one not using SSH)	a stable channel dedicated to phones

---

Data Storage

SQLite database (data/ssheverywhere.db): server cards, port forwarding, tunneling records, users, tasks, etc.
File system: backup files, tunnel keys, static assets.

---

Deployment Form

Panel: systemd service ssh-everywhere.service, listening on 0.0.0.0:5501.
Reverse tunnel: listening on 0.0.0.0:4433.
The target-device Agent runs as a resident service (systemd on Linux / termux-services on Termux).

---

About the Project Name "SSH Everywhere"

The project is named SSH Everywhere, meaning "manageable everywhere, just like SSH". SSH is by far the primary connection method of the whole project: apart from the Android-phone sub-scenario, every other feature (Linux server management, Tunneling, file transfer, health checks) ultimately lands on SSH. And the essence of the reverse tunnel is precisely "delivering SSH anywhere". This is why the name "SSH Everywhere" accurately expresses the project's core capability.

Documentation