Eternal Terminal: a re-connectable remote shell built on SSH handshakes

The problem Eternal Terminal targets: sessions that die with the link

A plain SSH session is bound to its TCP connection. When the path between client and server breaks, the connection is gone, and whatever was running in the foreground on the remote side goes with it unless it was already inside a multiplexer. Eternal Terminal exists to remove that binding. The README describes it as "a remote shell that automatically reconnects without interrupting the session." That single sentence is the whole product thesis, and it defines the audience: people working over links that drop, roam between networks, or pass through a VPN that renegotiates. The project is written in C++ and licensed under Apache-2.0. It is not archived, and the last push to the default branch was on 2026-09-23. The most recent release listed is et-v7.0.0 from 2026-07-07, after et-v6.2.11 in July 2025, so the release cadence is not fast. If you need a shell that stays put when the network does not, that is the trade this project makes.

How et, etserver and etterminal split the work

The architecture separates authentication from session transport. The README states that `et` "uses SSH to authenticate and start the remote session, then maintains the reconnectable ET connection." So SSH is the bootstrap, not the transport. `etserver` is the system service that accepts ET client connections and routes them to the correct user's session; its default TCP port is 2022. `etterminal` is an internal server-side helper launched through SSH, and the README is explicit that normal users do not invoke it directly. The protocol-level relationship between the three is documented in docs/protocol.md rather than in the README, which is worth reading before you debug a connection. Two more binaries ship in the installation: `htm`, a foreground client for the bundled terminal multiplexer, and `htmd`, the per-user daemon that owns persistent multiplexer sessions and is started automatically by `htm` when needed. `htm` speaks tmux control mode so compatible terminal emulators can show native windows, tabs and splits. The practical consequence is that ET is not one program but a small suite: a client, a system daemon, an internal helper, and an optional multiplexer pair. That shape matters when you plan deployment, because the daemon has to be running for anything to work.

Installing et on macOS, Ubuntu and Debian

Packages exist for several platforms, and the README points to a Repology badge for the full packaging status rather than listing every distribution. On macOS the recommended route is Homebrew:

brew install et

After that, `which et` should print the path to the client. If you want `etserver` started on every boot, the README gives launchd plist commands that differ between Apple Silicon and x86 Macs, and it notes the plist path must be rewritten for `/opt/homebrew/bin/etserver` on m1 machines. MacPorts is offered as an alternative with `sudo port install et`. On Ubuntu the project maintains a PPA:

sudo add-apt-repository ppa:jgmath2000/et
sudo apt-get update
sudo apt-get install et

Debian uses a signed repository instead, added through a keyring file and an apt source entry, followed by `sudo apt update` and `sudo apt install et`. Fedora and CentOS 8 use `sudo dnf install et`, FreeBSD uses `pkg install eternalterminal`, and openSUSE uses `zypper in EternalTerminal`. CentOS 7 has no package: the README says the only way is to build from source. Windows is handled through WSL, following the Ubuntu instructions.

Building from source and verifying the daemon

For distributions without a package, the README gives a generic source build that clones with submodules and compiles with CMake:

git clone --recurse-submodules --depth 1 https://github.com/MisterTea/EternalTerminal.git
cd EternalTerminal
mkdir build
cd build
cmake ../
make
sudo make install

The `--recurse-submodules` flag is not optional; the repository has a `.gitmodules` entry at the top level, so a plain clone will leave the build incomplete. Dependencies are listed per distribution, for example `boost-devel libsodium-devel protobuf-devel protobuf-compiler cmake gflags-devel libcurl-devel` on Fedora. Verification is two commands. `which et` confirms the client, and `systemctl status et` confirms the server. On some operating systems the README says you may need `sudo systemctl enable --now et` before the service is running. NixOS users get a different path entirely: the flake exposes a NixOS module that manages the package, `/etc/et.cfg` and the `etserver` service together, with options such as `services.eternalTerminal.port` and `settings.Networking.bind_ip`. The README warns that on NixOS you should set `services.eternalTerminal.settings` rather than editing `/etc/et.cfg` directly, so the generated file stays in sync.

A first connection, a jumphost and the SSH config requirement

The client syntax is close to ssh, with the username defaulting to whoever runs `et`:

et hostname
et user@hostname:8000

The first form assumes `etserver` on port 2022 and the current username. The second targets port 8000 and a different user. Port forwarding uses the `-t` option with pairs, and `-c` runs a command immediately after the connection is set up. For hosts behind a bastion, `--jumphost` and `--jport` are available, and if `--jport` is omitted, et tries port 2022 on the jumphost. The README states that et parses both user-specific and system-wide SSH config files, and that the config file is required when the sshd on the server or jumphost listens on a port other than 22. The example given uses `HostName`, `User`, `Port` and `ProxyJump` keys under a `Host` block. This is the part most likely to bite you: ET depends on SSH being reachable and correctly described before the ET connection can even be attempted, so a working `ssh user@hostname` is a precondition, not an optional check.

Where Eternal Terminal is the wrong tool

ET needs a listening TCP port, 2022 by default, and a system service on the far side. If your policy allows only outbound SSH to port 22 and nothing else, ET does not fit without a tunnel or a port change in `/etc/et.cfg`. The README also notes that ET uses TCP, which is a different bet from mosh's UDP approach; on high-latency or lossy mobile links, TCP's congestion behaviour is a real consideration, and the project does not claim otherwise in the documentation available. CentOS 7 users get no package. Windows users are routed through WSL, so a native Windows client is not offered. The README does not document rollback or downgrade procedures, and it does not describe what happens to a session when `etserver` is restarted, so treat daemon restarts as an unknown until you test them. Finally, if your only problem is keeping a long-running job alive, a multiplexer alone may be enough; ET adds a daemon and a port, and that is more surface than a plain `tmux` session requires.

Eternal Terminal compared with mosh, tmux and autossh

The closest comparison is mosh, which also aims to survive network changes, but the mechanisms differ: mosh uses its own state synchronization protocol over UDP, while ET authenticates with SSH and then runs its own reconnectable connection over TCP on port 2022 through `etserver`. That difference decides deployment. Mosh needs a UDP port range open; ET needs one TCP port and a daemon. Against tmux, the difference is layer. tmux is a multiplexer that keeps processes alive on the server; it does not keep the connection alive, so a dropped link still means reattaching. ET's own bundled `htm` and `htmd` sit in the tmux space, speaking tmux control mode, which makes them a complement to the reconnect logic rather than a competitor. autossh is the wrapper approach: it restarts SSH when the connection dies, which reconnects the transport but does not preserve the session state the way ET claims to. If you already run tmux and only need the process to survive, autossh plus tmux is a smaller install. If you want the session itself to persist without reattaching, ET is the more direct answer.

Licence, maintenance and upgrade cost

Eternal Terminal is Apache-2.0, which permits commercial and private use and includes an explicit patent grant, but it also carries notice and attribution obligations for redistributed copies. If you vendor `et` into a product image, read the LICENSE file in the repository rather than relying on the SPDX identifier alone; this is a description of the licence, not legal advice. Maintenance signals are mixed. The repository is not archived and the last push was on 2026-09-23, so it is current. But the release history shows et-v6.2.10 and et-v6.2.11 one day apart in July 2025, then a jump to et-v7.0.0 in July 2026. A major version bump after roughly a year suggests a larger change set than the patch releases, and the README does not document an upgrade path between major versions. Upgrading therefore means checking whether client and server versions must match, which the documentation does not state. Because `et` and `etserver` are separate programs on separate machines, an upgrade is a two-sided operation, and a version skew between them is the failure mode to plan for.

Editorial conclusion

Adopt Eternal Terminal if you already have SSH access to the host, can open or forward TCP port 2022, and want an interactive session that survives a dropped link without a wrapper script. Do not adopt it if you need a pure UDP path with no server daemon, or if you cannot run etserver as a system service. Before rolling it out, confirm three things: that `which et` finds the client, that `systemctl status et` shows the server running, and that your sshd configuration matches what the client will parse, including a non-22 port and any jumphost, since the README states the SSH config file is required in those cases.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. MisterTea/EternalTerminal on GitHub
3. Project website
4. README
5. Releases