DEV Community: Svyatoslav Pavlov

Which SSH clients support MCP in 2026

Svyatoslav Pavlov — Thu, 29 Oct 2026 20:10:38 +0000

A handful of SSH clients and terminals support MCP now, but "support MCP" means three different things, and the difference is what you actually care about:

Built-in MCP server — the client exposes your hosts as MCP tools an external agent can call (Conduit, XPipe, VibeShell, Termalin).
MCP client — the app's own in-terminal agent can use other MCP servers (Warp).
Community bridge or plugin — a third-party add-on exposes the app's sessions (Tabby, MobaXterm, Termius).

Disclosure: we build Termalin, one of the entries below. Facts checked October 14, 2026 — this moves monthly, so check each vendor's page before you commit.

The table

Client	MCP support	Local / hosted	Tools	Price	Platforms
Termalin	Built-in MCP server	Local + hosted (OAuth sign-in + API key)	22 local / 22 hosted	Free; Pro $8/mo yearly	Win, macOS, Linux, iOS (+ web)
Conduit	Built-in MCP server	Local only (socket / named pipe)	~60	Free (1 device); Pro $10/mo	macOS, Win, Linux, iOS
XPipe	Built-in MCP server	Local only (HTTP, off by default)	read-only until enabled	Free / $5–10/mo	Win, macOS, Linux (+ web)
VibeShell	Built-in "Agent Gateway"	Local	~28	Free (MIT)	Win, macOS, Linux
Warp	MCP client + its own agents	Agents run in the terminal	n/a	Free / $20/mo+	Win, macOS, Linux
Tabby	Community plugin (`tabby-mcp-server`)	Local	plugin-defined	Free (MIT)	Win, macOS, Linux (+ web)
MobaXterm	Community bridge (`mobaxterm-mcp`)	Local	reads `MobaXterm.ini`	Home free / $69	Windows
Termius	Community bridges only (no official server)	Local / cloud	varies	Free / $10/mo	Win, macOS, Linux, mobile
Wave Terminal	None found (Oct 2026)	—	—	Free (Apache-2.0)	macOS, Win, Linux
SecureCRT / Royal TS	None found	—	—	paid	varies

Notes on the rows

Conduit is the pick most AI assistants name for "SSH + MCP" today: a connection manager for SSH, RDP, VNC and web with an AES-256 vault and an Apache-2.0 built-in server, local only. XPipe also ships a built-in server — a local HTTP endpoint, off by default and read-only until you enable its mutation tools — handy if you already browse Docker, Kubernetes and VMs there. VibeShell exposes ~28 MCP tools through an Agent Gateway (MIT), with device-local credential storage its own README says is "not Keychain-grade."

Warp is a different case: it's an AI-first terminal whose own agents write and run commands, including in SSH sessions you open. That's not the same as exposing your hosts to an outside agent through a built-in MCP server — check Warp's docs for its current MCP-client support if you want to wire other servers into it.

Tabby, MobaXterm and Termius have no built-in MCP server; the community fills the gap. tabby-mcp-server is a plugin, mobaxterm-mcp reads your saved MobaXterm.ini sessions, and Termius has three separate termius-mcp-style bridges — the full breakdown is in does Termius have an MCP server?. None ship from the vendor.

Wave, SecureCRT and Royal TS: we found no MCP server in their docs as of October 2026. For SecureCRT and Royal TS the agent route today is a standalone SSH MCP server pointed at those hosts.

Termalin, in one row

Since we build it, here's the plain version: Termalin is an SSH client whose MCP server is a key custodian — the agent never holds a private key. It runs two ways: a bundled local server (22 tools) for an agent on your machine, and a hosted endpoint (https://termal.in/mcp, 22 tools) that claude.ai, ChatGPT, Claude Code, Codex and Cursor sign into, reaching servers keylessly through an outbound Connector with a per-connection command policy (full, allowlist or read-only) and an audit log. It's the only entry here with both a hosted endpoint and a custodian model — the other built-in servers (Conduit, XPipe) are local only.

How to pick

Want a built-in server and nothing leaving your machine → Conduit (broadest protocols) or XPipe (if you live in containers and VMs).
Want the agent to work from CI, a cloud sandbox, or a chat with no desktop → you need a hosted endpoint; among SSH clients that's Termalin, otherwise a hosted connector like browser-ssh or sshrew (see the servers comparison).
Already on Tabby, MobaXterm or Termius and happy there → the community bridge for your app, with the usual "read the code" caveat.
Want AI inside your local terminal, not external agent access → Warp.

For the deeper trade-offs — key custody, per-host policy, live oversight — see the landscape roundup and the buying guide.

Termalin is a free, cross-platform SSH client with a built-in MCP server, a key custodian and per-connection policy — download it or read the MCP reference.

Does Termius have an MCP server? (2026)

Svyatoslav Pavlov — Wed, 28 Oct 2026 21:21:43 +0000

As of October 2026, Termius has no official MCP server — nothing built into the app, and no announcement from Termius we could find. But several community projects bridge Termius to an AI agent, and a couple of other SSH clients get you the same result a different way. Here's each one, how it actually works, and the risk to weigh.

One disclosure up front: we build Termalin, one of the options below. We've tried to describe the rest as fairly as we'd want ours described, and to say where they're the better fit.

The community bridges to Termius

Three unrelated projects share the name termius-mcp, and they work in very different ways.

termius-mcp (MiaM1ku, on PyPI) — the one that's pip install-able (BSD, marked beta). A stdio server that logs into Termius Cloud: it syncs your vault, looks up a host, and runs SSH exec and SFTP. Ikaleio/termius-mcp is a close twin with the same description. Because it talks to Termius Cloud, you're handing it your Termius login — read the code and scope it accordingly.
yapp/termius-mcp — drives the terminals in a running Termius desktop app over the Chrome DevTools Protocol. It needs Termius ≥ 10.0.6 launched with --remote-debugging-port=9229, plus Node.js. It can create terminals, send keystrokes and keys, read output, and work the SSH sessions you already have open. The catch is that open debug port: anything local that can reach it can drive your terminals, so treat it as a development convenience, not a hardened setup.
deltaguita/termius-mcp — also drives already-open Termius tabs over CDP, but adds claim/lock guards so two agents don't stomp on the same session.

Termius Session MCP

Termius Session MCP (ItzGlace) is a tidier take on the same idea. It shares one visible Termius terminal with an MCP client through four tools — status, sessions, read, write — and adds an MCP button inside Termius. Its defining feature is caution: every write and every output release needs in-app approval. It's Windows only, needs Node ≥ 22, is MIT-licensed, and is explicit that it's "an internal-API integration, not an official Termius extension" (tested against Termius 9.39.0). If you want a human finger on every step, this is the one.

A name to ignore in these searches: TerminusAI turns up alongside the others but is unrelated to Termius — it's a generic one-tool MCP server that runs a command locally or over SSH, nothing to do with your Termius vault.

The other clients that get you there

If the real goal is "an AI agent that can work my servers," you don't have to stay inside Termius:

Conduit is a connection manager for SSH, RDP, VNC and web sessions with a built-in MCP server (Apache-2.0, around 60 local tools). It's local only — a Unix socket or Windows named pipe — so there's no cloud endpoint, but nothing leaves your machine. Import your hosts and an agent can drive them.
Termalin is an SSH client with its own MCP server in two shapes: 22 local tools in the desktop app, plus a hosted endpoint (https://termal.in/mcp, 21 tools) that claude.ai, ChatGPT, Claude Code, Codex and Cursor sign into. It reaches your servers keylessly through an outbound Connector — no inbound port — applies a per-connection command policy (full, allowlist or read-only), and writes an audit log; it's listed in the ChatGPT and Claude connector directories. Import your Termius hosts first (an ~/.ssh/config export or a CSV) and the agent works them.

The honest trade: if your hosts and habits already live in Termius and you want the lightest possible bridge, a community termius-mcp or Termius Session MCP keeps you there. If you'd rather the agent never hold a key and be able to work your servers from CI or a chat with no app running, a custodian-style client earns the cost of importing your hosts into a second app.

At a glance

Option	How it reaches Termius hosts	Key handling	Approvals	Platforms	License
termius-mcp (MiaM1ku)	Logs into Termius Cloud	Your Termius login	—	Anywhere (Python)	BSD
yapp/termius-mcp	CDP into a running Termius app	Uses the app's sessions	—	Anywhere (Node) + Termius	Unverified
deltaguita/termius-mcp	CDP into open Termius tabs	Uses the app's sessions	Claim/lock guards	Anywhere (Node) + Termius	Unverified
Termius Session MCP	Shares one visible terminal	Uses the app's session	Per write + per output	Windows + Termius	MIT
Conduit	Its own vault (import hosts)	In its AES-256 vault	—	macOS, Win, Linux, iOS	Apache-2.0
Termalin	Its own MCP, local + hosted	Custodian signs; key never handed over	Per-connection policy + audit	Win, macOS, Linux, iOS (+ web)	Source-available in parts

("Unverified" means we couldn't confirm the license on the repo as of October 2026.)

How to pick

Stay inside Termius, lightest touch → a community termius-mcp; read the code and mind the debug port.
Want a human to approve every action → Termius Session MCP (Windows only).
One open-source app across SSH, RDP and VNC, local only → Conduit.
Agent must run from CI or a chat with no desktop, and never hold a key → Termalin, after importing your hosts.

Termalin is a cross-platform SSH client whose built-in MCP server is a key custodian with per-connection policy and an audit log — see the MCP page, or the full Termius alternatives roundup.

SSH MCP servers compared

Svyatoslav Pavlov — Sat, 24 Oct 2026 16:29:13 +0000

Search "ssh mcp server" and you'll find a dozen projects that all promise to let an AI agent run SSH commands. They are not the same thing, and the differences — who holds the key, whether you can bound what runs, whether anyone can audit it — are exactly what decides if you can leave one running. This compares the three families: standalone servers you run yourself, hosted connectors you reach by URL, and SSH clients with a server built in.

Disclosure: we build Termalin, which appears in the third group. The rest are described from their public repos and docs, checked October 14, 2026.

Standalone servers (you run them; they hold a key)

You configure the hosts and keys, run the server, and point your agent at it. No GUI, scriptable, lightweight.

tufantunc/ssh-mcp — the most-starred of the bunch (~800★, MIT, 14 tools, TypeScript), and the one to beat. Its v2 adds command classification (read-only / safe / destructive / privileged), RBAC roles (viewer / operator / admin), approval modes, an audit log with redaction, and host-key pinning. Set up that way, it answers the policy and audit questions most of this family punts on.
AiondaDotCom/mcp-ssh ("MCP SSH Agent") — reads your ~/.ssh/config and known_hosts and shells out to native ssh. Simple and familiar.
blackaxgit/ssh-mcp — also uses ~/.ssh/config, with server groups for working a fleet.
veithly/ssh-client-mcp — SSH plus SFTP, password or key auth.
idletoaster/ssh-mcp-server — Node, built on the official MCP SDK.
the-nine-nation/remote-ssh-mcp — persistent, stateful sessions over your local OpenSSH.
claude-ssh-mcp (MaraBank) — pip/npx, the classic paste-a-password-in-chat style; the quickest to stand up and the bluntest on secrets.

The shared trait: the key lives wherever the server runs, usually a plain key file in the agent's reach, and you audit after the fact from logs — if you configured logging. tufantunc's v2 is the clear exception on both counts.

Hosted connectors (a URL; no key in the agent)

These answer the question the standalone servers can't: what reaches my servers when my laptop is off?

browser-ssh — a remote MCP server at api.browserssh.com/mcp offering, in its words, "scoped, audited SSH exec, sessions, and SFTP on saved servers without exposing credentials." You add it to an agent as a URL.
sshrew (duriantaco) — the self-hosted twin: the box dials out through cloudflared and you paste the resulting URL into Claude's custom connector, with allowlisted commands and a read-only share root (~/.sshrew-share).

These put the credential on the service or the dialing-out box instead of in the agent, and they work from a chat or CI. The trade is that you're trusting a hosted path and, for browser-ssh, a third party in your connection.

Client-bundled servers

The SSH clients that ship a server themselves, so the custodian and the UI come in one package:

Conduit and XPipe — both bundle a local MCP server (Conduit over a socket/pipe, ~60 tools, Apache-2.0; XPipe a local HTTP endpoint, read-only by default). No cloud endpoint, nothing leaves the machine.
Termalin — a bundled local server (22 tools) and a hosted endpoint (https://termal.in/mcp, 21 tools, OAuth sign-in for claude.ai/ChatGPT/Claude Code/Codex/Cursor). The MCP server is a key custodian — it signs on the agent's behalf, so no key is handed over — reaches servers keylessly through an outbound Connector, applies a per-connection policy (full, allowlist or read-only), and writes an audit log.

The comparison

Server	Family	Key custody	Policy / approvals	Audit	Hosted	License
tufantunc/ssh-mcp	Standalone	Key where it runs	v2: classes + RBAC + approvals	Redacted log	Runs anywhere headless	MIT
mcp-ssh (Aionda)	Standalone	Key / `~/.ssh/config`	Basic	Logs	Headless	OSS
the-nine-nation/remote-ssh-mcp	Standalone	Local OpenSSH	Basic	Logs	Headless	OSS
claude-ssh-mcp	Standalone	Password in chat	—	—	Headless	OSS
browser-ssh	Hosted	On the service	Scoped exec	Audited	Yes (URL)	—
sshrew	Hosted	On the dialing-out box	Allowlisted commands	—	Yes (cloudflared)	OSS
Conduit	Client	In its AES-256 vault	None we could find	MCP calls logged	No (local)	Apache-2.0
XPipe	Client	Client-held, local	Read-only until enabled	—	No (local)	Open-core
Termalin	Client	Custodian signs; key never handed over	Per-connection (full / allowlist / read-only)	Watch grid + marked recordings + log	Yes (OAuth + API key)	Source-available in parts

When each fits

You want one small, auditable moving part and you run headless anyway → tufantunc/ssh-mcp v2, with RBAC and approvals turned on. It's the standalone server that takes policy seriously.
You want the lightest native ssh wrapper → mcp-ssh or the-nine-nation, accepting that the key sits with the server and auditing is log-only.
The agent lives in a chat or CI and you don't run a desktop → a hosted connector: browser-ssh (fully managed) or sshrew (self-hosted via cloudflared).
You also want a human to watch live, a per-host policy enforced before a command runs, and the key never in the agent at all → a client-bundled custodian. Conduit and XPipe cover the local case; Termalin adds the hosted, keyless endpoint on top.

There's no single winner — a hardened standalone server and a custodian client are solving the same problem from opposite ends. The question to settle first is the one from what an MCP server is: who holds the credential? Everything in the table above flows from that answer. For the client-only view, see the buying guide.

Termalin is a cross-platform SSH client whose built-in MCP server is a key custodian with per-connection policy, a live watch grid and an agent-tagged audit log — download it or read the security model.

SSH into a server behind NAT or CGNAT, without port forwarding

Svyatoslav Pavlov — Thu, 15 Oct 2026 15:55:05 +0000

Reach a server with no open port: reverse SSH tunnel, Tailscale or WireGuard, Cloudflare Tunnel, or an outbound connector — with trade-offs and setup.

You want to SSH into a machine you can't accept connections to: a home server behind your router, a Raspberry Pi at the office, a box on a mobile or 5G link. The old answer — forward port 22 on the router — increasingly isn't available, and where it is, it's a bad idea. This post walks the four approaches that actually work, what each one costs you, and a worked example of each. None of them opens an inbound port on the machine you're reaching.

Why you can't just forward a port anymore

Two things get in the way. First, carrier-grade NAT (CGNAT): most home fibre, cable, mobile and Starlink connections now share one public IP across many customers, so there's no port on "your" address to forward — the router you control isn't the one holding the public IP. Second, even with a real public IP, a forwarded SSH port is found by scanners within minutes; the logs fill with brute-force attempts from the moment it goes live. The fix in every case below is the same shape: the private machine makes an outbound connection to something reachable, and you ride that connection back in. Outbound works even through CGNAT and locked-down firewalls, because it's just another connection leaving the network.

The four options at a glance

Approach	What you run	Extra infrastructure	Long-lived key on the box?	Best for
Reverse SSH tunnel	`ssh -R` + autossh on the box	a VPS with a public IP	yes (to the VPS)	you already rent a VPS
Mesh VPN (Tailscale / WireGuard)	a VPN client on both ends	a coordination service	your normal SSH key	reaching several machines
Cloudflare Tunnel	`cloudflared` on the box	a Cloudflare account + domain	your normal SSH key	you already use Cloudflare
Outbound connector	a small agent on the box	a Termalin account	no — short-lived certificate	browser access, no VPS or VPN

The first three give you a normal ssh you@… from your laptop. The last one reaches the box from a browser or an AI agent instead. Read on for which fits.

Option 1 — Reverse SSH tunnel through a VPS

If you already rent a cheap VPS with a public IP, the private box can dial out to it and forward its own SSH port back. On the box behind NAT:

ssh -N -R 2222:localhost:22 tunnel@vps.example.com

That opens port 2222 on the VPS and pipes every connection to it back to port 22 on the home box. From anywhere, jump through the VPS to land on the box:

ssh -J tunnel@vps.example.com -p 2222 you@localhost

A raw ssh -R dies the first time the network hiccups, so wrap it in autossh under a systemd unit to keep it alive across reboots and drops, and add -o ServerAliveInterval=30 -o ExitOnForwardFailure=yes. The full mechanics — including the GatewayPorts gotcha and why the tunnel binds to the VPS's loopback by default — are in SSH reverse tunnels, explained. Trade-off: you're maintaining a VPS and a long-lived key on the box that can reach it, and that VPS is now part of your attack surface.

Option 2 — A mesh VPN (Tailscale or WireGuard)

Instead of exposing one port, put both machines on a private network only they can see. Tailscale is the low-effort version. On the box behind NAT:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Install Tailscale on your laptop too, and both get a stable 100.x.y.z address (and a MagicDNS name). Then it's just:

ssh you@home-box

as if you were on the same LAN — the box is never exposed to the public internet at all. sudo tailscale up --ssh can even handle the SSH auth for you, so you don't manage keys for it. WireGuard is the same idea built by hand: you run the coordination yourself and configure peers manually — more work, no third-party coordinator. For a home lab with a NAS and a couple of Pis, a mesh VPN is usually the whole answer, and it's the default I reach for in the home NAS/server guide. Trade-off: every device that needs access has to join the network, which is a client to install and an account to run.

Option 3 — Cloudflare Tunnel

If your domain is already on Cloudflare, cloudflared gives you an outbound tunnel with no open port. On the box:

cloudflared tunnel login
cloudflared tunnel create home

Route a hostname to the tunnel and point it at local sshd (ssh://localhost:22) in the tunnel config, then run cloudflared as a service. On the client side, SSH reaches it through a ProxyCommand in your ~/.ssh/config:

Host ssh.example.com
    ProxyCommand cloudflared access ssh --hostname %h

Now ssh you@ssh.example.com flows through Cloudflare's edge to the box. The free tier covers this. Trade-off: you're routing your SSH through a third party and taking a dependency on a Cloudflare account and a domain you host there — great if you already do, overkill if you don't.

Option 4 — An outbound connector (no VPS, no VPN)

The three options above each ask for standing infrastructure — a VPS, a VPN, or a Cloudflare domain. Termalin's Connector collapses that to one command and reaches the box from your browser, the Termalin app or an AI agent instead of a local ssh. On the private server, one line installs a small static agent (Linux x86_64 and arm64):

curl -fsSL https://termal.in/tunnel-install.sh | sudo TERMALIN_TOKEN=<token> sh

The agent dials out to Termalin over a single WebSocket and holds it open; it never listens on a port. When you open a terminal in the web client, the request travels down that link and the agent connects to the box's own sshd on localhost — it only ever moves opaque SSH bytes, so it never sees your credentials or session plaintext. Enrolment makes the box's sshd trust Termalin's SSH certificate authority, so logins use a short-lived certificate rather than a long-lived private key sitting on the server. That's the one row in the table with "no" under long-lived key on the box.

The catch, stated plainly: you reach the box through Termalin's hosted side — the web terminal, the Termalin desktop and iOS apps (which connect through the same gateway), or an AI agent over the MCP server — not with a raw ssh command from your own machine, and the Connector is part of the paid tier (or the trial). If what you want is a normal terminal from your laptop, options 1–3 fit better. If what you want is browser access from any device — or to let an agent work on a box that has no public address and no key to steal — this is the option built for it.

Which one should you pick?

You already rent a VPS: the reverse tunnel reuses it — one ssh -R under autossh and you're done.
You have more than one machine to reach, or want them to feel like a LAN: a mesh VPN like Tailscale scales best and exposes nothing.
Your domain lives on Cloudflare: their tunnel is a natural fit with no new vendor.
You want zero standing infrastructure, browser access, or supervised agent access: an outbound connector, with no long-lived key left on the server.

All four share the one principle worth remembering: never open an inbound port on a machine you can't afford to have scanned. Let it reach out instead — that single reversal of direction is what makes SSH behind NAT safe.

Termalin is a free, cross-platform SSH client with saved tunnels, a web terminal and a keyless Connector for private servers — download it, or see how it handles your keys safely.

ssh-agent on Windows: start the service, add your keys, fix the errors

Svyatoslav Pavlov — Tue, 13 Oct 2026 15:21:17 +0000

You put a passphrase on your SSH key, and now Windows asks for it on every git push and every ssh. The fix is the SSH agent — unlock the key once, and every connection after that signs silently. The twist on Windows is that there isn't one agent. There are three that can be running at the same time, they hold keys in separate places, and a key loaded into one is invisible to the others. Almost every "it worked yesterday" agent problem on Windows is really a wrong agent problem. So this guide starts by naming them, then gets each one running, then decodes the errors you actually hit.

The three agents, and why they don't share keys

Agent	Ships with	Where it listens	Which `ssh` sees it
OpenSSH Authentication Agent (a Windows service)	Windows' native OpenSSH	named pipe `\\.\pipe\openssh-ssh-agent`	`ssh.exe` in `C:\Windows\System32\OpenSSH`
The MSYS2 agent (`ssh-agent`)	Git for Windows / Git Bash	a Unix-style socket named by `SSH_AUTH_SOCK`	the `ssh` bundled inside Git Bash
A Linux agent	inside your WSL distro	a Unix socket in that distro	`ssh` running inside WSL

The lesson from the table: ssh-add in Git Bash loads a key into the MSYS2 agent, and the native Windows ssh.exe will never see it — different endpoint, different key store. Pick one agent, load your keys there, and use the matching ssh. Mixing them is the root cause of most of the confusion below. The ssh-agent and ssh-add guide covers the cross-platform mechanics; this page is the Windows-specific half.

The built-in OpenSSH Authentication Agent service

Modern Windows 10 and 11 ship OpenSSH, and with it a Windows service that runs the agent — but it's off by default. Enable it once, from an elevated PowerShell (Run as administrator):

Set-Service ssh-agent -StartupType Automatic
Start-Service ssh-agent

Automatic starts it on every boot, so this is a one-time setup. Check the result:

Get-Service ssh-agent | Select-Object Status, StartType

You want Running and Automatic. From then on, in a normal (non-Git-Bash) PowerShell or cmd, ssh-add talks to this service:

ssh-add                                 # load default keys (id_ed25519, id_rsa, …)
ssh-add $env:USERPROFILE\.ssh\id_ed25519  # load a specific key
ssh-add -l                              # list loaded key fingerprints

ssh-add -l is your first diagnostic for any login failure — if the key you expect isn't listed, the agent can't sign with it, whatever else looks right.

To stop retyping ssh-add, let the first connection load the key for you. Put this in %USERPROFILE%\.ssh\config (the same ssh_config file OpenSSH reads everywhere):

Host *
    AddKeysToAgent yes

Now the first ssh that needs a passphrase prompts once and loads the key into the service as a side effect. Because the native Windows git and ssh both use this service, git push starts working silently too.

Error 1058: "unable to start the ssh-agent service"

You run Start-Service ssh-agent and get:

Start-Service : Service 'OpenSSH Authentication Agent (ssh-agent)' cannot be started due to the following error:
Cannot start service ssh-agent on computer '.'.
... error 1058 ...

Error 1058 means the service is disabled — Windows won't start a service whose Startup type is Disabled, and Start-Service doesn't change that for you. Fix the startup type first, then start it (elevated PowerShell):

Set-Service ssh-agent -StartupType Manual
Start-Service ssh-agent

Manual is enough to start it on demand; use Automatic if you want it up on every boot. If you're on a managed or domain machine, a group policy may have disabled it — in that case your admin has to allow the service before this sticks.

"error connecting to agent: No such file or directory"

This one comes from the Git Bash / MSYS2 ssh, not the Windows service. It means that ssh was told where to find an agent socket — via SSH_AUTH_SOCK — and nothing is there. Two common causes:

No agent is running in this shell. Git Bash doesn't start one for you. Start it in the shell you're using:

  eval "$(ssh-agent -s)"
  ssh-add ~/.ssh/id_ed25519

The eval matters: ssh-agent -s only prints the variables; the eval sets them so ssh can find the socket. Running ssh-agent bare and wondering why nothing changed is the classic misstep.

SSH_AUTH_SOCK is stale. A variable set by a previous session, a login profile, or another tool points at a socket that no longer exists. Check it with echo $SSH_AUTH_SOCK, then either unset it and start a fresh agent, or fix it to point at a live one.

If you'd rather use the Windows service from inside Git Bash, call the native binary directly — /c/Windows/System32/OpenSSH/ssh.exe — instead of the MSYS2 ssh on your PATH. Then Git Bash reaches the same keys you loaded into the service, and SSH_AUTH_SOCK stops mattering.

Keys in WSL

WSL is a separate Linux system, so it has its own agent, its own ~/.ssh, and its own SSH_AUTH_SOCK. Keys loaded on the Windows side are not visible inside your distro, and vice versa. You have two honest choices:

Run an agent inside WSL the ordinary Linux way — eval "$(ssh-agent -s)" and ssh-add, or AddKeysToAgent yes in the distro's ~/.ssh/config. Simple, fully isolated, and covered in the ssh-add guide.
Bridge to the Windows agent so both worlds share one key store. The usual recipe pipes the Windows named pipe into a Unix socket that WSL's SSH_AUTH_SOCK points at, using npiperelay.exe together with socat. It works well once set up, but it's extra moving parts — reach for it only if you genuinely need the same key on both sides.

Whichever you pick, remember that ssh-add -l inside WSL is a different question from ssh-add -l in PowerShell. Ask the right one when you debug.

When the agent is fine but login still fails

If ssh-add -l shows your key and the server still says Permission denied (publickey), the agent has done its job — the problem moved downstream to the server's authorized_keys, the wrong user, or the wrong key being offered. That's a separate checklist: Permission denied (publickey), fixed in order. And before you forward the agent to a remote box with ssh -A, read why agent forwarding is convenient and dangerous — it exposes live use of your keys on the far end.

How Termalin handles this on Windows

If juggling services, sockets and three key stores is more than you want to think about, that's the workflow Termalin builds in. It runs its own key agent on a Windows named pipe, \\.\pipe\termalin-ssh-agent, and serves the keys you've already unlocked in the app over the standard ssh-agent protocol — so a tool that speaks that protocol can sign through it with no OS service to enable, no eval line, and no manual ssh-add. The private keys stay in the running app and are never written to disk. The point of that agent is to let Termalin's own MCP server authenticate to your servers with your keys without ever holding the key material itself — the agent signs, the caller never sees the secret. It's the same one-unlock idea as the OpenSSH service, with the Windows setup taken off your plate.

Termalin is a free, cross-platform SSH client whose built-in agent unlocks your keys once and signs on your behalf — download it, or read how it handles your keys safely.

The best SSH client with a built-in MCP server (2026 buying guide)

Svyatoslav Pavlov — Thu, 08 Oct 2026 16:57:37 +0000

Five checks for an SSH client with a built-in MCP server: key custody, per-host policy, a hosted endpoint, live oversight, platforms. How Termalin scores.

"SSH client with a built-in MCP server" is a young category, and it's easy to be sold the wrong thing. A lot of what ships under that banner is a thin wrapper: an ssh_exec tool with a private key sitting in the wrapper's config. That gets a credential out of the model's context — genuinely worth something — but it stops there, and there is where most of the risk lives. This guide is about the criteria that separate a demo from something you'd actually leave running, and how to judge any client against them.

If you want the wide competitive landscape — Termalin, VibeShell, Gumpbox, the hosted proxies and the watch-only iOS apps — that's the full roundup. This post is the shorter, sharper version: the five things to check before you commit.

Verdict: the client that answers all five is the one whose MCP server is a key custodian, enforces a per-host command policy, ships both a local binary and a hosted endpoint, and shows you the sessions live. By that bar the recommendation is Termalin — with three honest exceptions (a fully open-source client you can audit line by line, Apple-only native sandboxing, or a Docker/Kubernetes manager) spelled out at the end. Here's how the shapes on the market score:

Option	Key custody	Per-host policy	Hosted endpoint	Live oversight	Platforms
Termalin	Agent never holds the key — the MCP server signs	Full / allowlist / blocked, per host locally (per API key on the hosted endpoint); a host is only exposed once you tick it	Yes — scoped, expiring API keys (Pro or trial)	Watch grid for agent-driven tabs + marked, output-only recordings; hosted runs audit-logged	Windows, macOS, Linux, iOS (+ web)
Thin `ssh_exec` wrapper	No — the key sits in the wrapper's config	No	No	No	Varies
Standalone MCP server	Usually plain key files in the agent's reach	The good ones take it seriously	It is headless — runs anywhere	No — logs after the fact, if configured	Anywhere headless
Hosted SSH proxy	Credentials sit in the connection path	Per-command policy mid-connection	Yes — it's a hosted service	Approvals mid-connection	A service, not a client
macOS/iOS-only watcher	Keychain-held	Varies	No	Consent sheet per action	Apple only

1. Who holds the key — and can the agent ever read it?

The first question, and the one every option answers differently. Pasting a key into the agent's environment is the one move you can't take back: once the bytes have passed through a model's context, a transcript, or a tool call you didn't read, you can't prove they didn't leak. The bar to look for is a key custodian: the agent asks, and something you control does the authenticating — you unlock once, the client signs on the agent's behalf, and there's no key file for the agent to read at all. Ask of any client: if this agent's context leaks tomorrow, is a credential in it? If the answer is yes, keep looking.

2. Can you bound what the agent runs — per host?

Key custody is necessary and not sufficient. A custodian that hands over an unrestricted shell has solved custody and left the blast radius wide open. What you want is a per-host command policy: each host set to full, an allowlist of commands, or blocked, enforced before a command runs — not a setting the agent is trusted to honor. This is the difference between "the agent has a shell on my fleet" and "the agent may run these commands, on these hosts, and nothing else."

3. Does it work when your desktop isn't running?

A local MCP server (a stdio binary the agent launches) is the right default for an agent on your laptop. But agents increasingly run where you aren't — CI jobs, cloud sandboxes, chat assistants like claude.ai and ChatGPT. For those you need a hosted endpoint: an HTTPS URL the agent reaches with a scoped, expiring API key, that connects to your servers keyless (a short-lived certificate, not a standing key) with no desktop running anywhere. A client that only offers the local binary can't help an agent in CI/CD. One that offers both covers the whole range.

4. Can you see what it did — and prove it later?

An agent's summary of its own work is not a record; it's a statement by the thing being audited. Look for two things: live oversight — a view where sessions the agent is driving are visible as they happen, so you can step in — and an audit trail made outside the agent, where its commands are marked as the agent's, with host, device and time, and session output is recorded (output only — a client that records keystrokes has built a keylogger, not an audit log). "What did the agent do at 2 a.m.?" should be a filter you apply, not a story you reconstruct.

5. Does it run where you do?

Mundane, but it eliminates options fast. Several agent-SSH tools are single-platform (macOS/iOS only, or one desktop OS). If your fleet is managed from a mix of Windows, macOS and Linux — and increasingly a phone — a client that only exists on one of them isn't a contender, however good its agent story.

How Termalin scores against its own checklist

We built Termalin to answer all five, so here's the honest scorecard:

Key custody — the built-in MCP server is the custodian. You unlock once; it signs on the agent's behalf; no key ever reaches the agent or the model.
Per-host policy — locally, a host is only exposed to the agent once you tick it, and each exposed host is full, an allowlist, or blocked, enforced at the point the agent asks. On the hosted endpoint the same three levels are set per API key, and AI access can be switched off per server.
Local and hosted — a bundled termalin-mcp binary for agents on your machine (Claude Code, Cursor, Codex, Gemini), plus a hosted endpoint (on Pro, or the 14-day trial) with scoped, expiring API keys for CI, cloud sandboxes, and the claude.ai / ChatGPT connectors.
Oversight — a live watch grid where terminal tabs an agent drives glow, output-only recordings of those tabs with each agent command marked, and on the hosted endpoint an audit log of every run: server, login, command, exit code and time. (Headless ssh_exec calls from the local binary open no tab and aren't audit-logged yet.)
Platforms — Windows, macOS, Linux and iOS (iPhone, iPad, Apple Watch), plus a browser cabinet for anything else.

Where it isn't the answer: if you need a fully open-source client you can audit line by line, Termalin isn't that (it's a company product, source-available in parts). If your agent work is Apple-only and you want the tightest native sandboxing on the target, a macOS/iOS-only tool may fit better. And Termalin is deliberately an SSH-focused client, not a Docker/Kubernetes/hypervisor manager — if that browsing is the point, a tool built for it will go deeper. The landscape post lays those trade-offs out in a table, including recommendations against ourselves.

The short version

If you're choosing an SSH client to give AI agents server access, don't stop at "it has an MCP server." Check that the agent never holds the key, that you can bound what it runs per host, that it works with no desktop for CI and chat agents, that you can watch and audit it, and that it runs on your platforms. A tool that does all five is one you can leave running; a tool that only checks the first is a demo you'll have to babysit.

Termalin is a cross-platform SSH client whose built-in MCP server is a key custodian with per-host policy, a live watch grid and an agent-tagged audit log — download it, or read the security model.

Connect Google's Gemini CLI to your servers over SSH — safely

Svyatoslav Pavlov — Wed, 07 Oct 2026 20:23:33 +0000

Gemini CLI speaks MCP, so it runs commands and manages files on your servers through Termalin — one entry in ~/.gemini/settings.json, no key handed over.

Google's Gemini CLI is a capable agent in a terminal, and like the other coding agents it eventually needs to leave your laptop and touch a real server — restart a service, tail a log, run the deploy on the box itself. The tempting shortcut is to let it run ssh directly: the CLI already executes shell commands, so if a key sits unlocked in ~/.ssh or a running ssh-agent, ssh prod works for it whether or not you meant to grant that. That's the whole problem in one line — you gave away full server access by default.

Gemini CLI has a cleaner path built in: it speaks MCP, the same protocol Claude Code, Cursor and Codex use. Termalin is an SSH client with a built-in MCP server, so you point Gemini at that server and it works your hosts for real — while the agent never holds a key. About twenty minutes, one host.

What you need

Termalin — the desktop app; the Free tier is fine. Its built-in MCP server is what Gemini talks to.
Gemini CLI, on the same machine.
One host saved in Termalin — something low-stakes for the first run.

Step 1 — turn on agent access and set a policy

Agent access is off by default. In Termalin, open Settings → MCP, enable it, and tick the hosts Gemini may reach. Nothing outside that list exists as far as the agent is concerned — a new host is a decision you make in the app, not something the agent can talk its way into.

Under the hood, Termalin writes a host inventory for the MCP server with agent-only auth entries — no passwords or keys land in that file — and authentication stays with the app's key custodian: you unlock once, and Termalin signs on the agent's behalf. There's no key file for Gemini to read, so there's nothing to leak, and the ~/.ssh back door above closes with it.

While you're there, set each host's agent policy: full access, an allowlist of commands, or blocked. Start with an allowlist for anything you care about — the least-privilege setup is its own short post.

Step 2 — register the server in Gemini's settings

Gemini CLI reads MCP servers from the mcpServers object in its settings file — ~/.gemini/settings.json for all your projects, or a project-local .gemini/settings.json. Add one entry pointing at the bundled termalin-mcp binary:

{
  "mcpServers": {
    "termalin": {
      "command": "<path>/termalin-mcp"
    }
  }
}

That's the whole integration. Restart Gemini CLI (or reload its MCP servers), and the tools appear to the agent: hosts_list, ssh_exec, persistent sessions (session_open / session_exec), SFTP reads and writes, and port forwards. Run /mcp in Gemini to confirm the server is connected and see the tools it exposes. The full tool list documents every one.

If you'd rather not wire MCP at all, there's a lighter option: Termalin has a local terminal tab, so you can just type gemini and run the CLI right inside the app next to your SSH sessions. That gives you Gemini in the same window — but it's the MCP setup above that lets Gemini act on your servers through the custodian, which is the part that keeps your keys out of its reach.

Step 3 — give it a real chore

Skip the demo. Hand it something real:

The deploy to staging-1 finished but the health check keeps flapping. Find out why and fix it.

Gemini calls hosts_list, sees staging-1, opens a session, and starts pulling threads — service status, the last hundred log lines, the config diff against what's running. It proposes a fix, applies it within the policy you set, and confirms the check goes green.

What makes this comfortable rather than nerve-wracking is that you can watch it. Turn on Agent in Terminal in Settings and Gemini can work in the app's own terminal tabs (terminal_open / terminal_run): each tab it opens is marked as the agent's, and the watch grid puts all open sessions side by side with the agent's tiles glowing, so you see the commands land and can step in at any point. Its headless calls (ssh_exec, session_*) don't open a tab; they run straight from the MCP server, inside the host list and policy you set.

Where the boundaries are

Defaults worth knowing before you point it at anything that matters:

Your keys never enter Gemini's environment. The custodian signs; the agent requests. Revoking access is a toggle in Settings, not a key rotation across your fleet.
Its reach is the host list you ticked in Step 1, and each host's command policy bounds what it can run there. "Full" on production is still a full shell — set it deliberately.
Typing into your session is separate. By default Gemini opens its own sessions; joining one you already have open is its own consent toggle.
Watch it, or record it. Agent work in the app's terminal tabs is visible live and can be recorded — output only, never keystrokes. How auditing an agent works covers the rest.

When Gemini runs in the cloud

If Gemini is running where your desktop isn't — a CI job, a cloud sandbox — the local binary isn't reachable, but Termalin's hosted MCP endpoint is (on Pro, or the 14-day trial). Mint an API key in the web cabinet, scope it to the right servers, set it read-only or to an allowlist, give it an expiry, and point the agent at https://termal.in/api/v1/mcp. It reaches your Connector-enrolled servers keyless, authenticating each run with a short-lived certificate — the full CI/CD pattern is here.

The habit that makes it stick

Treat the first week like onboarding a fast teammate. Keep the watch grid open, give Gemini chores with a clear done-state, and read how it gets there before widening anything. The trade is the point: Gemini gets real reach on your servers, and you keep the one thing — the keys — that can't be handed back once it's out.

Termalin is a cross-platform SSH client with a built-in MCP server, a key custodian and per-host agent policy — download it, read the MCP reference, or see how it handles keys.

Watch many SSH sessions at once — a live grid for humans and agents

Svyatoslav Pavlov — Tue, 06 Oct 2026 18:08:47 +0000

tmux and csshX tile your terminals; Termalin's watch grid tiles every open SSH session as a live view and glows the ones an AI agent is driving.

Anyone who has run more than a couple of servers knows the failure mode: eight terminal windows, a deploy going out across four of them, and no single place to see whether it's working. The old answers — tmux panes, csshX, a wall of iTerm splits — tile terminals so you can glance across them. They work, and they stop working the moment the thing you're watching isn't just you. When an AI agent is driving some of those sessions, "glance across the panes" isn't enough: you need to know which sessions are the agent's, and you need to be able to step in. That's what a watch grid is for.

The problem tmux solves, and the one it doesn't

tmux and csshX are about your attention across your sessions. Broadcast a command to a set of panes, watch the outputs line up, done. It's a genuinely good tool for fan-out work — patch twelve boxes, tail a log on all of them at once.

What they don't model is authorship. Every pane is you; there's no notion of "this session is being driven by something else, and I'm supervising it." In 2026 that's the gap, because more and more of the sessions on your machine are opened by an agent — Claude Code, Codex, Gemini — working a host through an MCP server. A pane full of commands you didn't type needs a different kind of attention than one you did.

What the watch grid does

Termalin's watch grid is one screen that mirrors every open session as a live tile. Not a summary, not a status dot — the actual terminal, updating as output arrives, laid out side by side. Two things make it more than a pretty tmux:

Agent-driven tiles glow. A session an AI agent is running is visually marked, in real time, while it acts. You don't have to remember which tab you handed to the agent; the grid tells you at a glance, across the whole fleet if need be.
You can step in. A tile isn't a read-only feed. See the agent heading somewhere you don't like, and you drop into that session and take over — the same session, live, no reconnecting. Supervision, not just observation.

Which agents show up here: ones working through Termalin's local MCP server inside the app's own sessions (the "Agent in Terminal" switch). Calls from a hosted chat connector, such as Claude or ChatGPT in the browser, run one by one on the server and land in the audit log instead of a tile.

Because every session stays alive in the background whether or not it's on screen, switching to a tile is instant and nothing is lost when you look away. (Keeping dozens of live SSH sessions responsive at once is its own engineering problem — we wrote up how the session store stays lock-free under that load.)

Why "glowing" matters more than it sounds

The live view changes what supervision costs. Without it, letting an agent work a server is an act of faith punctuated by reading a summary afterward — and a summary is written by the thing you're supervising, so it's the least trustworthy possible record. With a grid where agent sessions glow, oversight is ambient: you see the commands land as they happen, and a steered agent — one talked into something by a poisoned log line or filename — gets caught in the seconds it takes to notice, not in a postmortem. It doesn't lower the odds of a bad instruction; it collapses the time between the instruction and you seeing it.

That's the same argument as recording, one step earlier in time. Recording lets you answer "what did it do?" after the fact; the watch grid lets you answer "what is it doing?" right now, and intervene. Together they're the blast-radius safety net: a per-host policy bounds what the agent can do, the grid shows you what it is doing, and the marked recording proves what it did.

For a human fleet, too

None of this is agent-only. The grid is also just a good way to run several servers at once:

A deploy across a set of hosts — watch all of them go green (or one of them not) in one view, instead of alt-tabbing to find the straggler.
An incident — pull up the affected boxes as tiles, with each one's live CPU, memory and disk in the status bar, so "which node is actually pegged?" is visible, not guessed.
Routine fan-out — paired with send-to-many input, the grid is the classic csshX workflow with a modern client around it: reach a whole folder of hosts at once, type once, watch everywhere.

The difference from stitching this together with tmux and SSH config is that it's one app that already knows your hosts, holds your keys safely, and keeps the sessions alive — so the grid is a button, not a shell script you maintain.

Where recording and audit fit

The watch grid is the live layer; it pairs with the durable one. Every session can be recorded output-only (never keystrokes), with each agent command marked on the replay timeline, and the audit log keeps the who/when/from-where — the same client-side approach that makes recording and auditing sessions work through a jump host. Watch live to catch things fast; replay and audit to prove what happened. You want both, and they're the same feature seen at two speeds.

The short version

If your reason for tiling terminals is "I have a lot of servers," tmux and csshX are fine and free. If some of those sessions are driven by an AI agent — or will be soon — you want a view that marks authorship, lets you take over, and feeds a recording you can trust. That's the watch grid: see it in motion, then set your agents loose knowing you're watching.

Termalin is a free, cross-platform SSH client with a live watch grid, output-only recording and a built-in MCP server — download it, or read how it keeps keys safe.

Leaving MobaXterm: take your sessions and keys to macOS or Linux

Svyatoslav Pavlov — Mon, 05 Oct 2026 18:29:23 +0000

Where MobaXterm stores bookmarks and keys, how to export them, and how to land the whole setup in a cross-platform client — plus when to stay.

MobaXterm earned its following. On Windows it's the Swiss Army knife: tabbed terminal, a real X server, SFTP browser docked beside every shell, and a pile of bundled Unix tools that mean you rarely reach for anything else. If you live on Windows and lean on the X server, you may not need to leave at all — this guide will even tell you when to stay.

But two itches send people looking. One is the platform wall: MobaXterm is Windows-only, so the day you pick up a Mac or a Linux box, your whole setup stays behind. The other is the opposite of its strength — some people want a fast, focused SSH client, not a toolbox that does everything. Either way, getting out with your sessions, keys and habits intact is a smaller job than it looks. It's written with Termalin as the destination, but the first half applies to any modern client.

Know where MobaXterm keeps your stuff

MobaXterm calls saved sessions bookmarks, and where they live depends on which edition you run:

Installer edition — in the Windows registry, under HKEY_CURRENT_USER\Software\Mobatek\MobaXterm.
Portable edition — in a MobaXterm.ini file sitting next to the .exe. That single file is your whole configuration, which is why the portable build travels on a USB stick.
Private keys — wherever you saved them. MobaXterm works with standard OpenSSH keys and with PuTTY's .ppk, and it ships MobaKeyGen (a PuTTYgen clone) for making and converting them.
Saved passwords — in MobaXterm's own credential store, protected by its master password. These do not export in plaintext, by design — you'll re-enter them once in the new client.

Step 1 — export the sessions

The portable, any-OS route: open the Sessions sidebar, right-click the top User sessions node, and choose Export sessions to write a .mxtsessions file (it's plain text — you can open it and read your inventory). That file is what an importer consumes on a Mac or Linux box where the registry doesn't exist.

In Termalin, open the hosts list's import menu and paste that file or load it — the portable edition's MobaXterm.ini works too. Bookmarks arrive with their folders, as regular hosts you can sort, tag and colour-label. (The same importer also takes an ~/.ssh/config, a CSV, or a PuTTY .reg export, and on Windows it can read saved PuTTY sessions straight from the registry, if your setup is a mix.)

Step 2 — bring the keys

Here MobaXterm users are usually in good shape, because MobaXterm already speaks OpenSSH. If your keys are OpenSSH-format id_ed25519 / id_rsa files, just import them into the new client — done.

If some keys are in PuTTY's .ppk format (common if you migrated into MobaXterm from PuTTY years ago), convert them once: open MobaKeyGen, Load the .ppk, and Export OpenSSH key (force the new format — the legacy one predates Ed25519). The passphrase carries over. New to key formats? The Ed25519 vs RSA explainer is the thirty-second version, and a migration is a fine moment to generate a modern key for anything still on an old RSA one.

In Termalin the imported keys go into the built-in agent, so it's one unlock per session of work with passphrase caching on a timer you set, the same role MobaXterm's agent played. It speaks the standard ssh-agent protocol on its own per-user pipe or socket, so a CLI pointed at it with SSH_AUTH_SOCK can sign through it too.

Step 3 — don't blindly re-trust every server

MobaXterm remembers the host keys of servers you've connected to. Don't try to migrate that list. A move is the one natural moment you'll ever get to re-verify what you're actually connecting to. A modern client (Termalin uses trust-on-first-use with a proper known_hosts) shows each server's fingerprint on first connect — glance at the ones that matter, accept, move on. Ten minutes for a fleet you'll then trust cleanly for years.

Step 4 — the habits that carry over (and the one that doesn't)

Most of what you like about MobaXterm has a direct equivalent:

Tabs — you already think in tabs; you keep them (browser-style, drag to reorder, an activity glow on the quiet ones).
Files beside the shell — MobaXterm's docked SFTP browser becomes an SFTP panel in the same tab as the terminal: browse, edit in place with a built-in editor, upload. No second window, no re-entering credentials.
The credential vault — replaced by a local encrypted vault with a master password, auto-lock, and (on Windows) Windows Hello to re-unlock.

The one habit that does not carry over: the bundled X server. Termalin deliberately isn't a toolbox — it's a focused client for SSH, SFTP, FTP, Telnet, Serial and S3, and it does not ship an X server or a bag of Unix binaries. If forwarding X11 GUI apps from a server to your Windows desktop is part of your daily work, that's the honest reason to keep MobaXterm installed alongside — use the right tool for that job and let the new client handle the day-to-day.

What you gain that MobaXterm can't offer

The same setup on every OS. Windows, macOS and Linux desktops and native iPhone and iPad apps, with your hosts, keys and command history following you — plus a browser cabinet at termal.in/account for a real terminal from any laptop, phone or tablet with no install. That's the wall MobaXterm can't cross.
Encrypted sync instead of a USB stick (Pro). Your vault syncs end-to-end encrypted, so the sync server only ever holds ciphertext — the modern version of carrying MobaXterm.ini around.
An agent layer. A built-in MCP server lets an AI agent — Claude Code, Cursor, Codex — work your servers through the app without ever holding a key, under a per-host policy you set and mirrored in a live watch grid.

On price: MobaXterm's Professional license is a one-time $69. Termalin's Free tier is the whole desktop app, local, with no host limits; Pro (the encrypted cloud) is $8/mo billed yearly, with a one-time lifetime deal during the beta and a 14-day trial that needs no card. Different models — pick the one that fits how you like to pay.

Termalin runs on Windows, macOS, Linux and iOS; the Free tier has no host limits and imports a MobaXterm sessions export with its folders — download it, or see the full MobaXterm comparison.

Take it out of the map: keeping a shared session store lock-free during slow work

Svyatoslav Pavlov — Sun, 04 Oct 2026 16:27:10 +0000

An SSH client keeps every live session in a shared map behind a lock. Holding it through a slow handshake froze every other session — here's the Rust fix.

Here's a shape you'll recognise if you've ever put "a bunch of live things" behind one lock. An SSH client keeps its open sessions in a single map:

struct SessionManager {
    sessions: HashMap<String, SshSession>,
    // ...
}

static SESSION_MANAGER: OnceLock<Arc<Mutex<SessionManager>>> = OnceLock::new();

One Arc<Mutex<HashMap<Id, Session>>>, shared by every tab. Reads are cheap — grab the lock, find the session, write some bytes, drop the lock. It worked fine until someone opened a tenth tab and connected to a new host, and every other tab froze for three seconds. Through a jump host, longer.

The bug is one `.await` too many

The connect path looked like the obvious thing:

async fn connect_session(id: &str, creds: Creds) -> Result<(), String> {
    let mgr = get_session_manager();
    let mut mgr = mgr.lock().await;
    let session = mgr.sessions.get_mut(id).ok_or("not found")?;
    session.connect(creds).await   // <-- SSH handshake: seconds
}

The problem is the last line. session.connect(...).await is the full SSH handshake — key exchange, auth, maybe an agent trying keys in batches, maybe a whole second hop through a jump host. And we're holding the manager lock across it. Every keystroke in every other session, every stats poll, every "write these bytes to the terminal" now waits in line behind a network round-trip to a machine that might be on the other side of the planet.

Holding a lock across .await isn't a deadlock here — tokio's Mutex is fair and it'll get released. It's head-of-line blocking: the lock is held for as long as the slowest operation under it takes, and everyone else pays for it.

Move ownership out, do the slow work unlocked

The fix is to stop treating the session as something you borrow from the map for the duration of a slow call. Take it out:

/// Remove a session from the map so a slow `&mut self` op can run on it
/// without holding the manager lock. The caller MUST hand it back.
async fn take_session_for_op(id: &str) -> Result<SshSession, String> {
    let mut mgr = get_session_manager().lock().await;
    if mgr.in_flight.contains_key(id) {
        return Err("an operation is already in progress for this session".into());
    }
    match mgr.sessions.remove(id) {
        Some(session) => {
            mgr.in_flight.insert(id.to_string(), false); // false = not cancelled
            Ok(session)
        }
        None => Err("session not found".into()),
    }
}

Now the lock is held only long enough to remove the entry and record that an operation is running. The connect becomes:

async fn connect_session(id: String, creds: Creds) -> Result<(), String> {
    let mut session = take_session_for_op(&id).await?; // brief lock
    let result = session.connect(creds).await;         // NO lock held
    finish_session_op(&id, session).await;             // brief lock
    result.map_err(|e| e.to_string())
}

Between the first and third line the manager lock is free. The ten other tabs keep echoing keystrokes and drawing output while the new connection does its handshake in the background, holding nothing but its own owned SshSession. The slow work is exactly as slow as before — it just stops being everyone else's problem.

Now handle the two races you just created

The moment a session can be "outside the map," two things can go wrong, and both have bitten real users.

A second operation on the same session. Someone double-clicks connect, or a reconnect fires while the first is still handshaking. That's what the in_flight map is for: take_session_for_op refuses if an entry is already there. One in-flight &mut self operation per session, enforced at the door.

A disconnect arrives mid-handshake. This is the nasty one. The user closes the tab while the connection is still coming up. disconnect grabs the lock, looks in sessions… and it's not there, because we took it out. If you do nothing, the handshake finishes a moment later, finish_session_op puts a now-fully-connected session back into the map, and you have a live connection nobody is watching — a zombie.

So the in-flight marker doubles as a cancel flag:

async fn disconnect_session(id: String) -> Result<(), String> {
    let owned = {
        let mut mgr = get_session_manager().lock().await;
        // Not in the map? It's mid-connect. Flag the in-flight op to tear
        // its fresh connection down instead of re-inserting it.
        if !mgr.sessions.contains_key(&id) {
            if let Some(cancel) = mgr.in_flight.get_mut(&id) {
                *cancel = true;
            }
        }
        mgr.sessions.remove(&id) // Some(..) if already connected; None if mid-connect
    };
    if let Some(mut session) = owned {
        session.disconnect().await?; // slow part, lock released
    }
    Ok(())
}

And the return path honours it:

async fn finish_session_op(id: &str, session: SshSession) {
    let mut to_drop = None;
    {
        let mut mgr = get_session_manager().lock().await;
        // unwrap_or(true): if the marker vanished, assume cancelled.
        let cancelled = mgr.in_flight.remove(id).unwrap_or(true);
        if cancelled {
            to_drop = Some(session);          // don't re-insert
        } else {
            mgr.sessions.insert(id.into(), session);
        }
    }
    if let Some(mut session) = to_drop {
        let _ = session.disconnect().await;   // tear the fresh connection down
    }
}

The decision — reinsert or tear down — is made under the lock by reading one flag; the actual teardown happens after the lock is dropped. A disconnect that races a connect now always wins cleanly: either it removes an already-connected session, or it leaves a note that turns the in-flight connection into a no-op on arrival. No zombie either way.

Reaping the dead, without a background timer

Sessions also die on their own — the server hangs up, the network drops, the OS kills a backgrounded app. Those need collecting too, and the same "short lock, slow work released" discipline applies:

async fn cleanup_dead_sessions() -> Vec<String> {
    let (dead, owned) = {
        let mut mgr = get_session_manager().lock().await;
        let dead: Vec<String> = mgr.sessions.iter()
            .filter(|(_, s)| s.is_handle_closed())
            .map(|(id, _)| id.clone())
            .collect();
        let owned: Vec<_> = dead.iter().filter_map(|id| mgr.sessions.remove(id)).collect();
        (dead, owned)
    };
    for mut session in owned {
        let _ = session.disconnect().await; // lock released
    }
    dead
}

Two deliberate choices here. There's no background task — this is the only GC path, and the UI just calls it on a cheap interval (and on demand). A background reaper is one more thing holding the lock on a timer you don't control; calling it explicitly keeps GC on your schedule. And it only touches sessions that are actually in the map: anything mid-connect (owned out of the map) or never-connected is left alone, so the reaper and an in-flight handshake can never fight over the same session.

The shape, minus the SSH

Strip out the protocol and the pattern is reusable anywhere you keep live, individually-slow things in a shared map:

Hold the shared lock only long enough to move ownership out (remove), not for the duration of the work.
Do the slow async work on the owned value, lock released.
Re-acquire briefly to put it back — with a guard against a second concurrent operation, and a cancel flag so an op that raced the slow work can tear its result down instead of reinserting it.

It costs you a second map (in_flight) and a little bookkeeping, and it buys you a lock that's never held longer than a HashMap::remove. For anything behind Arc<Mutex<HashMap<_, _>>> where the per-entry operations touch the network, that trade is almost always worth it.

Where this lives

This is from the Rust core of Termalin, a cross-platform SSH client (the protocol layer is russh). The full session manager has more moving parts — per-session output buffers, tunnels, stats collectors — but the connect/disconnect/reap paths all follow the take-and-return discipline above.

Termalin is a fast SSH client for you and your AI agents — have a look, or read how the agent side works.

SSH reverse tunnels (ssh -R): expose a local port through a remote server

Svyatoslav Pavlov — Sat, 03 Oct 2026 19:12:34 +0000

How ssh -R works — the listener opens on the remote side. Demoing a dev server, reaching a machine behind NAT, catching webhooks, plus GatewayPorts.

You have something running on your laptop — a dev server, an API, a machine at home behind NAT — and something on the other side of the internet needs to reach it. No public IP, no router access, no time to set up a VPN. This is the job of the SSH reverse tunnel, ssh -R: it makes a port appear on a server you can reach, and quietly pipes everything that hits it back to your machine.

It's the flag people find backwards, so let's fix the mental model first, then work through the real cases.

The mental model: `-L`, mirrored

Every SSH tunnel opens a listening port on one machine and ships whatever arrives to somewhere reachable from the other machine. With local forwarding (-L), the port opens on your machine and traffic exits on the server's side. A reverse tunnel is the exact mirror image:

With -R, the listening port opens on the remote server, and connections to it come out on your side.

That's the entire trick. The machine that can't accept inbound connections makes an outbound SSH connection instead — and rides connections back in over it. If the two still blur together, the full family portrait is in SSH port forwarding, explained.

The syntax, read left to right

ssh -R [bind_address:]remote_port:localhost:local_port user@server

Read it as: on the server, listen on remote_port; forward whatever arrives to localhost:local_port — as resolved from my machine. So:

ssh -R 8080:localhost:3000 deploy@vps.example.com

opens port 8080 on the VPS, and every connection to it lands on port 3000 of your laptop. The destination doesn't have to be your laptop itself — -R 8080:192.168.1.50:80 forwards to another machine on your LAN, using your laptop as the exit.

One flag worth knowing: -R 0:localhost:3000 lets the server pick any free port, and prints Allocated port 43022 for remote forward so you know which one you got.

Three things people actually build with it

Show a local dev server to a client. Your work-in-progress runs on localhost:3000. Instead of deploying it somewhere just for a demo:

ssh -N -R 8080:localhost:3000 deploy@demo.example.com

Anyone who can reach demo.example.com:8080 is now looking at the app on your laptop, live. (-N skips the remote shell — you only want the tunnel. Whether anyone or only the server itself can connect depends on GatewayPorts — next section.)

Reach a home machine behind NAT. Your home box can't accept connections, but it can make them. Have it hold a tunnel out to a small VPS:

# on the home machine
ssh -N -R 2222:localhost:22 tunnel@vps.example.com

Now the VPS's port 2222 is the home machine's SSH port, and from anywhere:

ssh -J vps.example.com -p 2222 you@localhost

jumps through the VPS straight into the box behind NAT. This is the classic self-hosted answer to how to SSH into your home server.

Deliver webhooks to your laptop. A payment provider or git host needs to POST to your in-development handler. Tunnel their reachable endpoint back to you:

ssh -N -R 9000:localhost:9000 deploy@vps.example.com

Point the webhook at the VPS. If you keep the tunnel bound to the server's loopback (the default), put nginx or any reverse proxy on the VPS in front of 127.0.0.1:9000 — you get TLS termination for free and never expose the raw tunnel port.

GatewayPorts: why nobody else can reach your tunnel

The number-one surprise: the tunnel works when you test it from the server (curl localhost:8080 succeeds) but nobody outside can connect. That's by design — by default, sshd binds remote-forwarded ports to 127.0.0.1 only, no matter what bind address you asked for.

To open a tunnel to the world, the server's /etc/ssh/sshd_config needs:

GatewayPorts clientspecified

then restart sshd, and request the bind explicitly: ssh -R 0.0.0.0:8080:localhost:3000 .... (GatewayPorts yes binds every remote forward to all interfaces, which is broader than you usually want.) This is a server-side decision you cannot override from the client — a deliberate safety default, since a reverse tunnel is a hole punched from the inside, and whatever it exposes is now effectively internet-facing. Treat it that way.

Two related server-side switches can bite you: AllowTcpForwarding no disables tunnels entirely, and PermitListen can restrict which ports -R may claim.

Keeping it alive

A reverse tunnel is one TCP connection, and idle TCP connections die. For anything longer than a demo:

ssh -N -R 2222:localhost:22 \
    -o ServerAliveInterval=30 \
    -o ExitOnForwardFailure=yes \
    tunnel@vps.example.com

ServerAliveInterval 30 keeps traffic flowing so NAT entries and idle timeouts don't reap the connection.
ExitOnForwardFailure yes makes ssh die loudly if the remote port can't be bound, instead of connecting anyway and forwarding nothing.
autossh wraps the command and restarts the tunnel whenever it drops — the standard tool for tunnels that should survive reboots and flaky networks, usually run as autossh -M 0 -N -R ... under a systemd unit.

And once a tunnel earns a permanent place, move it into ~/.ssh/config with a RemoteForward line so it travels with the host entry — structure covered in the ssh_config guide:

Host homelink
    HostName vps.example.com
    User tunnel
    RemoteForward 2222 localhost:22
    ServerAliveInterval 30
    ExitOnForwardFailure yes

`-L` vs `-R` vs `-D` at a glance

Flag	Port opens on	Traffic exits on	Typical job
`-L`	your machine	server's side	pull a remote DB/dashboard to localhost
`-R`	the server	your side	expose local service; reach a NATed box
`-D`	your machine	server's side, any destination	SOCKS proxy into a network

When a reverse tunnel is the wrong tool

A reverse tunnel is a superb temporary answer: demos, webhook debugging, rescuing a machine behind NAT. It's a poor permanent one. If the thing you're exposing needs to be up for months, serve real users, or survive your laptop sleeping — that's ingress, and ingress deserves real infrastructure: a reverse proxy on a server, a VPN or overlay network, an actual deployment. The tunnel's charm is that it's one command with no standing footprint; the moment you're writing monitoring for it, you've outgrown it.

Troubleshooting the usual failures

Warning: remote port forwarding failed for listen port 8080 — the port is taken on the server. Often the culprit is your own previous tunnel: the old sshd process holds the port until the dead connection times out. Keepalives prevent the zombie; -R 0:... sidesteps the collision; ExitOnForwardFailure turns the warning into an error you can't miss.
Works from the server, refused from outside — the listener is on the server's loopback. That's the GatewayPorts default doing its job; either configure it or front the port with a reverse proxy.
Tunnel connects but the service doesn't answer — check the local half: is anything actually listening on the local port you named? -R 8080:localhost:3000 with nothing on your :3000 yields connection refused for every visitor.
The SSH connection itself won't establish — that's a different problem with its own checklist: connection refused and timed out, decoded.

When tunnels become furniture

The reverse tunnel you run once, you type. The one that carries your home lab, your demo box and your webhook endpoint is state you rebuild every morning after every laptop sleep — and lose track of by Thursday. Termalin's saved tunnel manager keeps local, remote and dynamic forwards attached to the host they belong to: start them with a click, see at a glance which are live, and have saved ones start when the app launches and come back if they drop, instead of being retyped from shell history. On Pro, the host list — keys, jump hosts and tunnels included — syncs across your machines end-to-end encrypted. And when a box sits behind NAT for good, its outbound-only Connector (Pro) replaces the hand-rolled reverse tunnel entirely — no inbound port, and no autossh unit to babysit. The command line teaches you what -R means; a client keeps the tunnels you rely on from depending on your memory.

Termalin is a free, cross-platform SSH client with built-in tunnels, SFTP and a key manager — download it, or see how it handles your keys safely.

Leaving PuTTY: migrate your sessions, keys and habits without losing anything

Svyatoslav Pavlov — Fri, 02 Oct 2026 17:17:06 +0000

Where PuTTY hides your sessions and host keys, how to convert .ppk keys to OpenSSH, and how to land the whole setup in a modern client in one evening.

PuTTY deserves its reputation. It's small, it's honest, it has worked the same way since the dial-up era, and half the world's server closets were administered through it. Nobody has to leave. But if you've caught yourself juggling eleven PuTTY windows on a taskbar, copying files with a separate WinSCP window, and typing the same passphrase forty times a day — the itch is real, and the move is smaller than it looks.

This guide gets everything out of PuTTY intact: sessions, keys, host keys, habits. It's written with Termalin as the destination, but the first half applies to any modern client.

Know where PuTTY keeps your stuff

PuTTY famously has no config file. Everything lives in the Windows registry:

Sessions — HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Sessions, one key per saved session: host, port, username, per-session settings.
Known host keys — HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys — the fingerprints of every server you've ever trusted.
Private keys — wherever you saved the .ppk files. The registry only stores the path to a session's key, not the key itself. If you're like most long-time users, there's a keys folder somewhere you haven't opened since 2019.

Worth knowing even if you stay: this is why your PuTTY setup doesn't follow you to a new machine unless you remember to export the registry branch.

Step 1 — export the sessions

On the machine with your PuTTY setup, from a command prompt:

reg export "HKCU\Software\SimonTatham\PuTTY\Sessions" putty-sessions.reg

That single .reg file is your complete session inventory — portable, human-readable, and the input format most importers (Termalin included) accept on any OS. On Windows you can usually skip even this: Termalin's hosts list has an import menu that reads your saved PuTTY sessions straight from the registry, one click, and they arrive as regular hosts you can sort into folders and tag.

Step 2 — convert the keys

PuTTY's .ppk format is its own thing; the rest of the world speaks OpenSSH. Conversion is built into PuTTYgen and takes seconds per key:

Open PuTTYgen, Load the .ppk (enter its passphrase).
Menu Conversions → Export OpenSSH key (force new file format).
Save as id_ed25519 / id_rsa — the passphrase carries over.

Two notes from the trenches: export the new format (the legacy one predates Ed25519), and don't forget keys referenced by sessions but stored in odd places — each session's PublicKeyFile value in the .reg export shows the path it expected (the import marks those hosts as key-based, so you know which ones still need a key). Once converted, import the keys into your new client; in Termalin they go into the built-in agent, which means one unlock per session of work, passphrase caching on a timer you control, instead of one passphrase per connection.

If you drove Pageant all day, that habit maps directly: Termalin's agent plays the same role. It speaks the standard ssh-agent protocol on its own per-user pipe or socket, so a CLI pointed at it with SSH_AUTH_SOCK can sign through it too.

Step 3 — don't blindly re-trust every server

You can migrate PuTTY's SshHostKeys — but honestly: don't bother. Fingerprint formats differ, and a migration is the one natural moment you'll ever have to re-verify what you're connecting to. A modern client (Termalin uses trust-on-first-use with a proper known_hosts) will show each server's fingerprint on first connect — glance at the ones that matter, accept, move on. Ten minutes for a fleet you'll trust cleanly for years.

Step 4 — rebuild the two habits PuTTY never had

Tabs instead of windows. Eleven sessions become one window with browser-style tabs (drag to reorder, activity glow on the quiet ones). The win isn't cosmetic — it's that "which window was staging?" stops being a question.

Files next to the terminal. The separate-WinSCP-window workflow collapses into an SFTP panel in the same tab as the shell: browse, edit in place with a built-in editor, upload — no second app, no reconnecting the same credentials.

Everything else transfers as-is: your servers are still your servers, your muscle memory still works, Ctrl+D still logs you out.

What you gain that has no PuTTY equivalent

Sessions that follow you — hosts, keys and command history sync across machines, end-to-end encrypted so the sync server only ever holds ciphertext. Terminal themes per host (staging in Nord, production in something appropriately red). And if you work with AI agents: a built-in MCP server that lets an agent open SSH sessions through the app, under your eyes, without ever seeing a key — a sentence that would have sounded like science fiction when your .ppk files were created.

Termalin runs on Windows, macOS, Linux and iOS; the Free tier has no host limits and imports PuTTY sessions in one click — download it, or see the full PuTTY comparison.

DEV Community: Svyatoslav Pavlov

Which SSH clients support MCP in 2026

The table

Notes on the rows

Termalin, in one row

How to pick

Does Termius have an MCP server? (2026)

The community bridges to Termius

Termius Session MCP

The other clients that get you there

At a glance

How to pick

SSH MCP servers compared

Standalone servers (you run them; they hold a key)

Hosted connectors (a URL; no key in the agent)

Client-bundled servers

The comparison

When each fits

SSH into a server behind NAT or CGNAT, without port forwarding

Why you can't just forward a port anymore

The four options at a glance

Option 1 — Reverse SSH tunnel through a VPS

Option 2 — A mesh VPN (Tailscale or WireGuard)

Option 3 — Cloudflare Tunnel

Option 4 — An outbound connector (no VPS, no VPN)

Which one should you pick?

ssh-agent on Windows: start the service, add your keys, fix the errors

The three agents, and why they don't share keys

The built-in OpenSSH Authentication Agent service

Error 1058: "unable to start the ssh-agent service"

"error connecting to agent: No such file or directory"

Keys in WSL

When the agent is fine but login still fails

How Termalin handles this on Windows

The best SSH client with a built-in MCP server (2026 buying guide)

1. Who holds the key — and can the agent ever read it?

2. Can you bound what the agent runs — per host?

3. Does it work when your desktop isn't running?

4. Can you see what it did — and prove it later?

5. Does it run where you do?

How Termalin scores against its own checklist

The short version

Connect Google's Gemini CLI to your servers over SSH — safely

What you need

Step 1 — turn on agent access and set a policy

Step 2 — register the server in Gemini's settings

Step 3 — give it a real chore

Where the boundaries are

When Gemini runs in the cloud

The habit that makes it stick

Watch many SSH sessions at once — a live grid for humans and agents

The problem tmux solves, and the one it doesn't

What the watch grid does

Why "glowing" matters more than it sounds

For a human fleet, too

Where recording and audit fit

The short version

Leaving MobaXterm: take your sessions and keys to macOS or Linux

Know where MobaXterm keeps your stuff

Step 1 — export the sessions

Step 2 — bring the keys

Step 3 — don't blindly re-trust every server

Step 4 — the habits that carry over (and the one that doesn't)

What you gain that MobaXterm can't offer

Take it out of the map: keeping a shared session store lock-free during slow work

The bug is one .await too many

Move ownership out, do the slow work unlocked

Now handle the two races you just created

Reaping the dead, without a background timer

The shape, minus the SSH

Where this lives

SSH reverse tunnels (ssh -R): expose a local port through a remote server

The mental model: -L, mirrored

The syntax, read left to right

Three things people actually build with it

GatewayPorts: why nobody else can reach your tunnel

Keeping it alive

-L vs -R vs -D at a glance

When a reverse tunnel is the wrong tool

Troubleshooting the usual failures

The bug is one `.await` too many

The mental model: `-L`, mirrored

`-L` vs `-R` vs `-D` at a glance