essh: Building the SSH Client I Actually Wanted
My server management workflow was embarrassing. A ~/.ssh/config with 40 entries, kept vaguely in sync with a notes file. A shell alias for each server. Multiple terminal tabs, renamed by hand. scp commands reconstructed from memory every time I needed to copy a file.
If you manage fewer than five servers, this works fine. At ten or more, it's death by a thousand cuts. The existing options weren't quite right: mosh is great for flaky connections but doesn't solve fleet management. Teleport and Boundary are serious infrastructure for 100-node organizations. There's a real gap in the middle — a native TUI that treats your servers as a fleet, not individual connections.
The fleet model
essh organizes servers into named groups. You can have a prod group, a staging group, a personal group. The TUI shows all groups in a sidebar, lets you connect to any server in two keystrokes, and gives you a split view for concurrent sessions. No config file archaeology. No alias maintenance.
The thing that makes this useful rather than just pretty: per-session diagnostics. When you connect to a server, a small panel shows live CPU, memory, network interface stats, and gateway latency — pulled via the SSH connection, no agent required. You get netwatch-style visibility without installing anything on the remote host.
Pure Rust SSH
Building an SSH client from scratch is genuinely hard. The protocol is a layered stack: transport → user auth → connection multiplexing → channel handling. russh handles the crypto and protocol state machine correctly, which meant I could focus on the UX layer rather than the wire format.
The trickiest part was concurrent sessions with correct input routing. In a split-view terminal, every keystroke needs to go to exactly the right session. Getting this right with ratatui's input model took two full rewrites — the first attempt had a subtle race condition that only appeared when switching focus quickly between panes.
What it feels like to use
The goal was a tool that feels like it belongs in the terminal, not a web app awkwardly ported to a TUI. That means: keyboard-first navigation, no mouse dependency, consistent visual language, and latency that doesn't feel like a round-trip to a server just to draw a menu.
It also means respecting your existing SSH config. essh reads your ~/.ssh/config on startup and imports known hosts. You don't have to re-enter anything you've already configured. It adds fleet features on top of what you already have, not as a replacement.
What's next
The core is solid: concurrent sessions, host diagnostics, file transfer, port forwarding, fleet management. The next features I want to build are proper SSH jump host support (SSH ProxyJump with full TUI), a key management panel, and SFTP with a two-pane file browser. The hard infrastructure is there. The remaining features are UI problems, which are tractable.
essh is MIT licensed, available on GitHub, and installable via cargo install essh. If you manage more than a handful of servers and live in the terminal, give it a try.