Two Go SSH tools landed within the last year, both hovering around the same star count, both solving very real pain points. But they’re almost entirely different tools that happen to share a protocol prefix.
Let’s break them down.
The Players
boring — 1,661★, Go
Links & Stats 👉 https://github.com/alebeck/boring
A dedicated SSH tunnel manager with a daemon architecture. You define tunnels in TOML, boring open starts them, and a background process keeps them alive with automatic reconnection and keepalives. Supports local, remote, and dynamic (SOCKS5) forwarding, works with your SSH config and ssh-agent, and handles Unix sockets.
My take: boring is for people who maintain persistent SSH tunnels — tunnel-as-service. If you have a dev server you always need a local port for, or a database you proxy through a bastion, boring is the cleanest answer I’ve seen. No TUI, no config manager, no connection history — just tunnels that stay up.
sshm — 1,345★, Go
Links & Stats 👉 https://github.com/Gu1llaum-3/sshm
An interactive SSH config manager with a Bubble Tea TUI that wraps ~/.ssh/config. You can add, edit, move, search, and tag hosts through a beautiful terminal interface. It does port forwarding setup (local/remote/dynamic) via guided forms, tracks connection history with last-login timestamps, runs live connectivity pings (green/yellow/red status), and supports SSH Includes for multi-file configs.
My take: sshm is for people who manage many SSH hosts — dozens or hundreds of entries in ~/.ssh/config. The TUI makes adding a new host with ProxyJump, identity file, and custom SSH options feel like filling out a form instead of memorizing the config file format. The connection history and live status indicators are genuinely useful for a fleet of servers.
The Real Difference: Tunnels vs. Configs
These tools aren’t really competitors — they occupy different layers:
| boring | sshm | |
|---|---|---|
| Primary job | Manage live tunnels | Manage SSH config |
| Persistence | Daemon keeps tunnels up | You manage connections yourself |
| Interface | CLI (list/open/close) | TUI + CLI |
| Config format | Its own TOML (~/.boring.toml) |
Your ~/.ssh/config |
| Reconnection | Automatic, built-in | N/A — standard SSH |
| Port forwarding | Core feature (local/remote/SOCKS) | Guided form setup |
| Host management | Not really | Full CRUD + tags + search |
| Connection history | No | Yes, per-host timestamps |
| Connectivity checks | Through keepalives | Async ping with live indicators |
| When to use | You have 3-10 persistent tunnels | You have 20-200 SSH hosts |
Port Forwarding: Different Approaches
Both tools support local, remote, and dynamic forwarding, but the UX diverges completely.
boring treats forwarding as a tunnel definition in TOML — you write it once, it stays up forever:
[[tunnels]]
name = "db-proxy"
local = "15432"
remote = "localhost:5432"
host = "bastion"
boring open db-proxy starts it. It reconnects on network drops. You forget it exists.
sshm treats forwarding as a per-session setup — select a host in the TUI, press f, choose forward type, fill in the port, and it connects. It remembers your previous forwarding configs per host, but the tunnel lives only as long as the SSH session.
Who Wins?
Neither. They’re complementary.
Use boring when you need tunnels that stay up regardless of network interruptions — API proxies, database port forwards, SOCKS proxies to internal networks. The daemon model is what SSH’s built-in -L/-R/-D should have been from day one.
Use sshm when your ~/.ssh/config is a mess of copy-pasted entries and you want a nice interface to manage hosts, search by tag, see who’s online, and check when you last connected to a server.
Use both — sshm to manage the host definitions, boring to manage the permanent tunnels through those hosts. They touch completely different files and serve different workflows.
Quick Stats
- boring: v0.16.1, 53 forks, 5 open issues, ~10 months old
- sshm: v1.11.0, 69 forks, 25 open issues, ~11 months old
- Both: Go, MIT license, Homebrew installable, cross-platform
- Both were released within a month of each other (Sept 2024 / Aug 2025)