DEV Community: Svyatoslav Pavlov

Connect OpenAI Codex to your servers over SSH — safely

Svyatoslav Pavlov — Wed, 16 Sep 2026 18:14:39 +0000

Codex is happy inside a repo. The task that sends you looking for server access is the one that leaves it — the deploy failed, the migration hung, the service won't come back up on the actual box. The tempting fix is to let Codex run ssh itself: it already executes shell commands on your machine, so if a key sits unlocked in ~/.ssh or a running ssh-agent, ssh prod works for it without you deciding anything. That's not "giving Codex access" — that's discovering you gave it away by default.

There's a cleaner arrangement, and Codex is built for it. OpenAI's Codex CLI speaks MCP, and Termalin is an SSH client with a built-in MCP server. Point Codex at that server and it works your hosts for real — runs commands, reads and writes files — while the agent never holds a key. This is the same shape as the Claude Code and Cursor setups; here's the Codex-specific version, in about twenty minutes.

What you need

Termalin — the desktop app; the Free tier is fine. Its built-in MCP server is what Codex will talk to.
The Codex CLI, on the same machine.
One host saved in Termalin. Pick something you don't mind an agent poking at for the first run — staging, a throwaway VPS.

Step 1 — turn agent access on and set a policy

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

Two things happen underneath. 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 Codex to read, so there's nothing to leak — which also closes the ~/.ssh back door above.

While you're there, set each host's agent policy: full access, an allowlist of commands, or blocked. For anything you care about, start with an allowlist — the shortest list that lets Codex do the job you have in mind.

Step 2 — register the server in config.toml

Codex reads MCP servers from the mcp_servers section of ~/.codex/config.toml. Add one entry pointing at the bundled termalin-mcp binary:

[mcp_servers.termalin]
command = "<path>/termalin-mcp"

Recent Codex builds can add it from the command line instead — the same result:

codex mcp add termalin -- <path>/termalin-mcp

That's the whole integration, and the same config drives Codex in the IDE. Restart Codex, confirm the server shows as connected, and the tools appear to the agent: hosts_list, ssh_exec, persistent sessions (session_open / session_exec), SFTP reads and writes, and port forwards.

One Codex habit worth keeping for the first sessions: leave its command approvals on. Codex asks before it acts unless you tell it not to — don't tell it not to yet. Widen that the same way you widen the host list: one boring thing at a time, after you've watched how it behaves.

Step 3 — give it a real chore

Skip the demo command. Hand it something you'd actually do:

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

Codex 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.

The reason this is comfortable rather than nerve-wracking is that none of it is invisible. Every session Codex opens shows up in Termalin as a live terminal tab, and the watch grid puts all open sessions side by side with the agent-driven tiles glowing. You're watching commands land as they run, not reading a summary afterward — and you can step in mid-session at any point.

Where the boundaries are

The defaults worth knowing before you point Codex at anything that matters:

Your keys never enter Codex'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 Codex opens its own sessions; joining one you already have open is its own consent toggle, and on Pro. It never rides along silently.
Every command is on the record. Session recordings capture output only — never keystrokes — and each agent command is tagged as the agent's in the audit log, with the device and IP it came from. "The agent did this" is a filter you apply, not a story you reconstruct.

When Codex runs where your desktop isn't

If Codex is running in CI or a cloud sandbox rather than on your laptop, the local stdio binary isn't reachable — but Termalin's hosted MCP endpoint is. Create an API key in the web cabinet, scope it to the servers that job should touch, set it to read-only or an allowlist, and give it an expiry. The endpoint reaches your Connector-enrolled servers keyless, authenticating each run with a short-lived certificate — no key handed out, nothing standing. The full pattern, with a copy-paste pipeline example, is in giving an agent SSH access in CI/CD.

The habit that makes it stick

Treat the first week like onboarding a fast-typing teammate. Keep the watch grid open. Give Codex chores with a clear done-state — "make the health check pass", "renew the cert" — and read how it gets there. Keep approvals on until it's earned auto-approve for the dull tools, and widen the host list one unexciting box at a time.

The asymmetry is the whole point: Codex gets real reach, and you keep the one thing 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. Start from the Codex SSH page, read the MCP reference, or download the app — the Free tier has no host limits.

How to audit and record what an AI agent does on your servers

Svyatoslav Pavlov — Tue, 15 Sep 2026 16:49:19 +0000

The moment you let an AI agent touch a real server, a new question appears that never mattered when it was just you at the keyboard: what did it actually do? Not what it says it did — agents narrate their work, and the narration is often tidy fiction, skipping the command that failed, the file it read "just to check," the thing it tried before the thing that worked. When you ask a human colleague "what did you run on prod last night?" you're trusting a memory. When you ask an agent, you're trusting a language model's account of a language model's actions. Neither is an audit trail. This post is about building one.

Why the agent's own report doesn't count

Three reasons, and they compound:

It's produced by the thing being audited. A record the actor writes about itself is a statement, not evidence. If the agent is confused — or steered by a poisoned log line or filename it read along the way — its report is confused or steered too.
It's lossy on purpose. Models summarize. The command that returned an error, the exploratory cat of a config, the curl to an address you didn't expect — exactly the lines an incident review cares about — are the ones a summary drops as noise.
It isn't attributable later. "The agent cleaned up disk space" is not something you can hand an auditor, diff against a change ticket, or replay six months on.

The fix is the same one that has always separated a real audit trail from a story: make the record outside the actor, capture the raw session, and attach identity and time to it.

What a real trail needs

Borrowing the checklist from auditing sessions on a bastion, an agent trail has to answer who, when, from where, what, and can I trust this — with one addition unique to agents:

Every command captured as it ran — not a summary, the actual session output, replayable with its original timing.
The agent distinguished from you. The single most important field. A record that can't tell "the agent ran this" from "I ran this" forces you to reconstruct at 2 a.m. what should have been a filter.
Connection metadata alongside — which host, when, from which device and IP.
Output, never keystrokes. More on this below — it's the trap that turns an audit trail into a liability.
A record the agent can't quietly edit. If the actor can rewrite its own history, you're back to trusting the story.

The keystroke trap — sharper for agents

A terminal session has two streams and they are not symmetric. Output holds every command that ran (the shell echoes it) plus everything those commands printed — the complete forensic record. Input adds exactly one thing output doesn't: the characters deliberately not echoed — sudo passwords, passphrases, a token pasted into a prompt.

Record input and you haven't built an audit trail, you've built a keylogger aimed at your own infrastructure. With agents it's worse: agent sessions are the ones you're most likely to record by default and least likely to be watching keystroke-by-keystroke, so a capture-everything setting quietly becomes a growing archive of secrets nobody decided to collect. The rule holds in every layer: record output, never input.

Server-side, client-side, or both

You can record where the session lands (on the server, with tlog or auditd) or where it originates (in the client). For agents specifically, the client side isn't just a nice complement — it's the only layer that can capture the fact that mattered most: who was driving. A server-side recorder sees a session on db-01; it cannot see that a model opened it via MCP rather than a person via ssh. That distinction has to be stamped in at the source, by the thing that brokered the connection.

So the strong setup is: client-side recording that marks agent commands, plus server-side recording where you need the "everyone, no exceptions, whatever client they used" guarantee. The two answer different questions and corroborate each other in a review.

Doing it with Termalin

Termalin is the client-side layer, and because its MCP server is also the thing brokering the agent's access, it can stamp the record at the source:

Sessions are recorded output-only by design. Keystrokes are never captured — there's no setting to turn that into a keylogger. Turn recording on in Settings → Terminal or per host on the host form, and set a retention window (7, 30, 90, 365 days, or forever) so old recordings prune themselves instead of piling up as liability.
Agent commands are marked. Each command an agent issues gets its own green marker on the replay timeline (your commands and system events are amber), and the same distinction is written to the audit log. "Show me only what the agent did" is a filter, not a reconstruction.
The audit log carries the metadata. Every sign-in, host connection, file operation and agent command, with where (IP · country) and which device — the who/when/from-where an auditor asks for, correlated with the session instead of scattered across log files with drifting clocks.
You can watch it live. The watch grid mirrors every open session as a tile, and the ones an agent is driving glow. Live oversight doesn't lower the odds of a bad instruction landing — it lowers dwell time, so a steered agent is caught in minutes, not discovered in a postmortem.
Recordings the agent can't rewrite. On paid plans they sync end-to-end encrypted — the server stores ciphertext it can't replay, and you replay from the web cabinet anywhere. The record survives even if the box the agent touched is rebuilt.

The honest limits

Worth stating plainly, because a trail you over-trust is its own risk:

A recording proves what ran, not what leaked. If your policy lets the agent cat a file, cat .env returns your secrets into its context, and the recording faithfully shows it happening — after the fact. Auditing tells you that it happened fast; it doesn't prevent it. Pair recording with a tight per-host command policy and with keeping secrets off disk.
Client-side covers the sessions that go through the client. It can't testify about a session someone opened another way — that's what the server-side layer is for.
"Marked as the agent" is only as trustworthy as the broker. The custodian doing the marking is now a thing to protect; concentrating that trust in one hardened place is the right trade, but it is a trade.

None of these are reasons to skip the trail — they're the difference between having an audit story and believing a marketing one. The same setup runs in CI, where every hosted run is logged against the API key that made it.

Termalin is a free, cross-platform SSH client with output-only session recording, an agent-tagged audit log and a live watch grid — download it, or read the security model.

What is a jump host? (And how to use one without collecting keys on it)

Svyatoslav Pavlov — Mon, 14 Sep 2026 16:28:41 +0000

A jump host is a hardened intermediary server that acts as the single, audited entry point into a private network. The servers you actually care about — databases, app servers, build machines — have no public address at all; the only way to reach them over SSH is to go through the jump host. You connect to it from the outside, and from there your connection continues inward to the machine you wanted.

That's the definition. The design question that follows — how to pass through it without scattering credentials along the way — is where most setups go wrong, and it's what the rest of this page is about. If you already know the concept and just want the commands, the ProxyJump setup guide is the how-to; this page is the what and the why.

Jump host, bastion, jump box, gateway: one idea, four names

The terminology is an archaeology of the same pattern. Bastion host is the oldest term, borrowed from fortification — the strongpoint built to face the attack. Gateway emphasizes the network role: the machine that connects two networks that otherwise don't touch. Jump host and jump box describe what operators experience — you "jump" through it to get somewhere else. Cloud vendors' managed offerings are the same idea again, productized.

There are shades of usage — "bastion" tends to imply deliberate hardening, "jump host" sometimes just means "the box I hop through" — but in practice the terms are interchangeable. If a machine's job is to be the one exposed SSH door in front of private infrastructure, it's a jump host, whatever the runbook calls it.

Why funnel everyone through one machine

The logic is concentration. Exposing twenty servers to the internet means twenty attack surfaces to patch, twenty sshd configs to keep tight, twenty places to watch for brute-force noise. Put a jump host in front and the arithmetic changes:

One machine to harden. Minimal packages, current patches, strict sshd config — affordable when it's one box instead of a fleet.
One place for strong authentication. Enforce keys-only, MFA, or short-lived certificates at the door, once, instead of wiring it into every internal server.
One choke point to audit. Every administrative session crosses the same threshold, so "who connected, when, from where" has a single authoritative answer — more on that below.
A smaller blast radius. Internal machines can drop their public exposure entirely and accept SSH only from the jump host's address.

The trade is obvious and accepted: the jump host becomes the most attractive target on your network. The entire design rests on it holding access without holding secrets — which is exactly the property careless usage destroys.

How traffic actually flows through one

The modern mechanism is OpenSSH's ProxyJump (ssh -J), and the detail that matters is where the second connection terminates. Your client connects to the jump host, authenticates, and then uses that connection purely as a transport — inside it, your client opens a second, end-to-end encrypted SSH connection directly to the internal machine. Authentication to the target happens from your laptop; the session's encryption is negotiated between your laptop and the target.

The jump host shuttles ciphertext. It never sees your private key, never holds your session's plaintext, and cannot read what you type on the inner connection. Even if the jump host were fully compromised, the attacker could observe that a connection passed through — not what happened inside it.

Contrast the old pattern this replaced: SSH to the jump host, land in a shell on it, then run ssh again from there to the target. In that world the jump host is a full participant — the inner session is decrypted and re-encrypted on the box, so anything on it can read your session, and you need credentials for the target available on the jump host to make the second hop at all. That one requirement is the root of most jump-host security failures.

The minimal setup

A common misconception is that a jump host needs special software. It doesn't — it's a role, not a product. The bastion side needs an ordinary sshd and user accounts (hardened, patched, keys-only — but ordinary). All the routing intelligence lives client-side, in one line of ~/.ssh/config:

Host bastion
    HostName bastion.example.com
    User jump

Host db
    HostName 10.0.0.9
    User deploy
    ProxyJump bastion

Now ssh db transparently routes through the bastion to a private address your laptop can't even reach directly. Chains (ProxyJump hop1,hop2) and the full set of options are in the setup guide.

A minimal hardening checklist

The bastion has to earn the trust the design places in it. None of this is exotic — the point of the pattern is that it only has to be done on one machine:

Keys only, no passwords. PasswordAuthentication no and PermitRootLogin no in sshd_config. An internet-facing sshd gets password-guessed around the clock; this ends that class of attack outright.
Nothing on the box but the door. No app code, no databases, no developer tooling — the fewer packages installed, the less to patch and the less an intruder finds to work with.
Patch on a schedule. Unattended security updates for the OS, and a standing habit of keeping sshd itself current — this is the one host where "we'll update next quarter" isn't acceptable.
Throttle the noise. fail2ban, or sshd's own MaxStartups limits, so brute-force attempts stay background static instead of becoming load.
Log off the box. Ship auth logs somewhere the bastion can't edit — a compromised gateway shouldn't get to rewrite its own history. Whether to go further and record sessions is its own question, covered below.

The two mistakes that undo the design

Both come from the old land-in-a-shell habit, and both put your identity on the one machine most likely to be attacked.

Storing private keys on the jump host. If making the second hop requires a key sitting in ~/.ssh on the bastion, then everyone's keys accumulate on the single most exposed machine in the network — and a compromise of that one box yields credentials to everything behind it. The jump host was supposed to contain a breach; a key collection turns it into the breach's distribution point. With ProxyJump there is simply no reason for any private key to exist there.

Agent forwarding through it (ssh -A). Subtler, because the key itself stays home — but forwarding exposes your agent's socket on the jump host, and anyone with root there can use your identity for as long as you're connected. On a shared, internet-facing gateway, that's precisely the wrong place to offer it. The full argument is in agent forwarding is convenient and dangerous; the short version is that ProxyJump makes forwarding unnecessary for the hop itself.

When you don't need one

A jump host earns its keep when there's a private network behind it and more than a couple of people in front of it. If you run a single VPS with a public address, adding a bastion adds a hop and a maintenance burden without meaningfully reducing exposure — tighten that one sshd instead. And modern mesh VPNs and overlay networks solve an overlapping problem by putting your laptop on the private network, so every internal machine is reachable directly over an encrypted mesh. That can replace a jump host for connectivity — though teams often keep one anyway, precisely because a single audited SSH door is easier to reason about (and to show an auditor) than "every device can reach everything."

The same honest comparison applies to zero-trust access products — identity-aware proxies that put SSO, device checks and per-request policy in front of every connection. They solve the jump host's problem with more machinery and stronger guarantees, and at some combination of headcount and compliance pressure that machinery pays for itself. Below that line, a jump host is the version of the same idea you can build in an afternoon with stock OpenSSH — no new vendor, no new agent on every laptop, and every property of it inspectable in two config files.

The audit dividend

Concentration cuts both ways, and the second edge is useful: because every session crosses the jump host, it's the one place with a complete view of who came in, when, and from where. That makes the bastion the natural anchor for session auditing — and also the place where doing it wrong (shared accounts, keystroke capture, recordings stored on the same box) hurts most. The architectures and traps get a full treatment in recording and auditing SSH sessions on a bastion.

Where Termalin fits

Termalin treats the jump host as part of a saved server's configuration: attach a bastion to a host, and every connection to that internal machine routes through it automatically — keys stay on your machine, nothing is copied to the gateway, no agent socket is exposed there, and each hop's identity is verified on first connect with a loud warning if a fingerprint ever changes. For the audit side, sessions can be recorded client-side — output only, never keystrokes — with an audit log of who connected where and when, which pairs naturally with whatever recording the bastion itself does. The Free tier has no host limits — download it and put the private network one click away.

Termalin is a free, cross-platform SSH client with jump-host support, output-only session recording and a key manager — download it, or see how it handles your keys safely.

ssh-agent and ssh-add, in practice: stop typing your passphrase

Svyatoslav Pavlov — Sun, 13 Sep 2026 16:14:01 +0000

You've done the right thing and put a passphrase on your SSH key — and now you're typing it for the fifth time before lunch. The fix has existed for decades: the SSH agent. Unlock the key once, and every connection after that authenticates silently. The catch is that "once" only works if the agent is actually running, your shell can find it, and the key is loaded — three separate things, each with its own way of failing. This is the practical guide: starting the agent on each OS, driving it with ssh-add, making the whole thing automatic, and decoding the two errors that account for nearly all agent trouble.

What the agent is, in one paragraph

ssh-agent is a small background process that holds your decrypted private keys in memory. When a server challenges you, ssh hands the challenge to the agent, the agent signs it with the in-memory key, and only the signature goes back — the key itself never leaves the agent, never touches the wire, and stays encrypted on disk. One passphrase prompt to load the key, then every later connection is served from memory. If you want the full mental model — why it's built as a signing service and what that implies — that's covered in what is the SSH agent?; this post stays hands-on.

Starting the agent, per OS

Linux. On a desktop login you almost certainly have an agent already — either a systemd user service or GNOME Keyring playing the role — with SSH_AUTH_SOCK exported for your whole session. Test with ssh-add -l. If nothing answers (common over a bare SSH login, in containers, or on minimal servers), start one by hand:

eval "$(ssh-agent -s)"

The eval matters. ssh-agent -s only prints the SSH_AUTH_SOCK and SSH_AGENT_PID variables; the eval is what sets them in your current shell so ssh can find the socket. Running ssh-agent bare and wondering why nothing changed is the single most common way to "start" an agent that no tool can see.

macOS. launchd runs an agent for you from login — there is nothing to start. The macOS-specific win is the Keychain integration below.

Windows. Modern Windows ships an OpenSSH Authentication Agent service, but it's not running by default. Enable it once, from an elevated PowerShell:

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

After that, ssh-add works in any terminal, and the agent survives reboots.

Driving it with ssh-add

Load, inspect, and clear keys:

ssh-add                          # load the default keys (id_ed25519, id_rsa, …)
ssh-add ~/.ssh/work_ed25519      # load a specific key
ssh-add -l                       # list fingerprints of loaded keys
ssh-add -L                       # print the full public keys
ssh-add -d ~/.ssh/work_ed25519   # remove one key
ssh-add -D                       # remove all keys

ssh-add -l is the first diagnostic for any auth problem: if the key you expect isn't in that list, the agent can't sign with it, whatever else looks right.

Two flags are worth making habits:

-t sets a lifetime. ssh-add -t 3600 ~/.ssh/id_ed25519 loads the key for one hour; after that the agent forgets it and the next use re-prompts. A key that sits unlocked in memory for a three-week uptime is a key usable long after you stopped thinking about it.
-c requires confirmation. Every signing request pops a local prompt before the agent answers. Slightly annoying, exactly right for high-value keys.

Make it automatic: AddKeysToAgent

The manual ssh-add ritual disappears with one line in ~/.ssh/config:

Host *
    AddKeysToAgent yes

Now the first ssh that needs a key prompts for the passphrase once and loads the key into the agent as a side effect. No separate command to remember — the prompt simply stops recurring. You can set it to a lifetime too (AddKeysToAgent 1h) to get the -t behaviour without the flag.

macOS: survive reboots with the Keychain. By default the agent forgets keys when it restarts. macOS can store the passphrase in your login keychain so keys reload without retyping:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

and in ~/.ssh/config:

Host *
    AddKeysToAgent yes
    UseKeychain yes

After that, the passphrase question is answered by the Keychain at login and you never see it again — while the key file on disk stays encrypted.

The two errors everyone hits

Could not open a connection to your authentication agent — ssh-add can't find an agent. Either none is running, or one is running but this shell doesn't have SSH_AUTH_SOCK set. The fix is the per-OS start above: the eval "$(ssh-agent -s)" line on Linux (check first whether your desktop session already provides one — starting a second agent per terminal just scatters loaded keys across processes), the service start on Windows. You'll also meet this in cron jobs and CI, where no login session ever exported the variable.

The agent has no identities. — the opposite problem: the agent is fine, but nothing is loaded. ssh-add your key. If it was loaded and vanished, a -t lifetime expired or the agent restarted — which is precisely what AddKeysToAgent yes and the macOS Keychain are for.

And the third case: the agent looks perfect — ssh-add -l shows the key — but the server still says Permission denied (publickey). That's no longer an agent problem; work through the publickey checklist — wrong user, wrong key offered, authorized_keys permissions.

An unlocked agent is a live credential

The agent never leaks the key — but it signs for whoever can reach its socket, and it doesn't ask who's asking. On your own machine that means any process running as your user can request signatures: that's the deal you accept for the convenience, and it's why agent hygiene is worth the small effort.

Give keys a lifetime (-t, or a lifetime on AddKeysToAgent) so an idle agent goes cold on its own.
Lock the agent when stepping away: ssh-add -x locks it behind a password, ssh-add -X unlocks; ssh-add -D simply drops everything.
Use -c for the keys that reach production.
Don't forward the agent by default. ssh -A exposes live use of your keys on the remote host — anyone with root there can sign as you for the length of your session. That one deserves its own read: agent forwarding is convenient and dangerous.

How Termalin handles this

Termalin builds this whole workflow in, with the sharp edges filed down. Its key agent unlocks your keys once and signs on your behalf — no OS service to enable, no eval line, no per-shell socket to lose. Passphrase caching comes with a re-lock timeout by default, which is the ssh-add -t habit enforced for you rather than remembered by you. And because it speaks the standard ssh-agent protocol, git and your existing CLI tools sign through it unchanged — it replaces the ritual, not your toolchain.

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

Best SSH Clients for Linux in 2026

Svyatoslav Pavlov — Sat, 12 Sep 2026 15:12:58 +0000

Let's not pretend: on Linux, the best SSH client is the one already installed. OpenSSH plus a terminal emulator you like plus tmux is the default answer, it's the right answer for most people, and any roundup that buries it below seven GUI apps is selling something. We are selling something (we build Termalin, last entry), which is exactly why this post starts with the free setup that makes most paid clients unnecessary, and only then covers the cases where a dedicated client earns its keep: big host inventories, files-next-to-terminal workflows, sync across machines, and mixed-protocol fleets.

Prices as of September 2026, checked against official sites.

Tool	Price	Best for
OpenSSH + tmux	Free, preinstalled	The default answer, and usually the right one
Tabby	Free, open source (MIT)	Open-source GUI with a host manager
Termius	Free local / Pro $10/mo (annual)	Sync to native mobile apps
Remmina	Free, open source	RDP/VNC alongside SSH, GNOME-friendly
WindTerm	Free, source published (Apache-2.0)	Raw speed, minimal resource use
Asbru-CM	Free, open source	Cluster commands, big host trees
XPipe	Free / Homelab $5/mo / Pro $10/mo	Docker, K8s, VM and WSL discovery
Termalin	Free (no host limits) / Pro $8/mo yearly	Integrated SFTP + E2E sync + AI agents

1. OpenSSH + tmux (+ your terminal of choice)

The floor, and for many people the ceiling. A maintained ~/.ssh/config gives you host aliases, ProxyJump chains, per-host keys and connection multiplexing. ssh-agent means one passphrase a day. tmux keeps sessions alive through dropped Wi-Fi and gives you panes, and whichever emulator your distro ships (or Ghostty, Kitty, Alacritty if you care about rendering speed) is the glass on top. Total cost: zero, forever, with no vendor in the loop. What this stack genuinely lacks: a visual inventory once you pass a few dozen hosts, any SFTP UI beyond sftp's readline, and sync that isn't "dotfiles repo you forget to push." If none of those bite you, close this tab; that's our first recommendation against ourselves.

Best for: most Linux users, most of the time.

2. Tabby

The strongest open-source GUI client on Linux: MIT license, tabs and splits, a proper saved-connection manager with credentials, serial support, and plugins. It's Electron, so memory use is an order of magnitude above a native emulator, and there's no first-party sync (config files or community plugins fill in). If you want a Termius-shaped app whose source you can read, this is the pick, and if closed source rules Termalin out for you, Tabby is what we'd hand you. Longer comparison on our Tabby page.

Best for: an open-source host manager with a modern UI.

3. Termius

Termius ships a real Linux desktop app, which most commercial clients never bothered to do, and it's the only entry here whose hosts follow you to genuinely good native iOS and Android apps. The free plan is local-only on one device; cross-device sync needs Pro at $10/month billed annually, through Termius's cloud only. On a Linux desktop specifically, you're mostly paying for the mobile half of the ecosystem, so be sure you'll use it. The alternatives are mapped in our Termius comparison.

Best for: the desk-to-phone workflow, if the phone half is real for you.

4. Remmina

The GNOME-world staple, free and GPL. Remmina is a remote desktop client first (RDP, VNC, SPICE) that also does SSH and SFTP, with a tidy profile list and system-tray quick connect. Its SSH terminal is basic and its SFTP browser is functional rather than pleasant, but if your week includes RDPing into Windows servers from a Linux workstation, having every protocol behind one profile list is worth more than a fancier terminal.

Best for: mixed RDP/VNC/SSH work on a Linux desktop.

5. WindTerm

Free for commercial use with source published under Apache-2.0, and the fastest full-featured client in this list: startup, scrolling and rendering all feel native because they are. Sessions, SFTP and a shell-aware autocompleting input line are built in. Know before adopting: the sole maintainer has said openly that development pace has dropped to a fraction of its peak, so buy the current version, not the roadmap. On Linux it's an AppImage-style unpack rather than a distro package, which your package manager won't love.

Best for: speed and low resource use with sessions and SFTP included.

6. Asbru-CM

The old-school Linux connection manager, alive and well: GPL, Perl/GTK, actively maintained in 2026. Its superpower is scale and automation: deep folder trees of hundreds of hosts, scripted expect-style logins, and cluster mode, where one keyboard drives many sessions at once, which is the feature that keeps it installed in ops teams. The UI is unapologetically functional and the learning curve is real.

Best for: big host trees and typing into twenty servers at once, for free.

7. XPipe

Different category, same problem space: XPipe doesn't render a terminal, it discovers and organizes everything shell-shaped (SSH hosts, Docker containers, Kubernetes pods, VMs, Podman, WSL) and opens each one in the terminal and editor you already use. It's built by Linux-first people and it shows. Community tier is free with unlimited connections; Homelab is $5/month, Professional $10/month or $80/year. Pair it with the stock OpenSSH setup from entry one and you've solved inventory without changing your terminal. Comparison here.

Best for: container-heavy and VM-heavy infrastructure on top of your existing terminal.

8. Termalin

Ours, judged last and hardest. It's a native desktop app for Linux (plus Windows and macOS) with browser-style tabs, an SFTP panel and built-in editor next to the shell, snippets, live server stats in the status bar, and output-only session recording with replay. Sync is end-to-end encrypted, so the server only ever holds ciphertext, at $8/month billed yearly; the free tier is the full desktop app with no host limits, and the 14-day Pro trial needs no card. The unusual part: a built-in MCP server that gives AI agents like Claude Code supervised access to your hosts through a key custodian (the agent never sees a key) with every agent session mirrored in a live watch grid.

Against ourselves, plainly: Termalin is young, not open source (a real minus on this platform in particular), and current beta builds are unsigned. If open source is a requirement, take Tabby or Asbru-CM from this list and don't look back. If you want one window where terminal, files, encrypted sync and agent access live together, that's the case we built for.

Best for: integrated terminal + SFTP + E2E sync, or letting an AI agent work on servers under your eyes.

The short version

Start with OpenSSH + tmux; it's the default answer for a reason. Add XPipe if your problem is inventory, Remmina if your problem is RDP, Asbru-CM if your problem is scale, Tabby if you want an open-source GUI, Termius if your phone is a work tool, WindTerm if you want speed with batteries included. And if you want the integrated-with-encrypted-sync setup, or AI agents on your hosts, try ours. The platform guide lives at SSH client for Linux.

Disclosure: this blog is written by the Termalin team. Termalin is free with no host limits on Linux, Windows and macOS — download it and hold it to the standard above.

Best SSH Clients for macOS in 2026

Svyatoslav Pavlov — Fri, 11 Sep 2026 15:53:44 +0000

The Mac starts from a better place than Windows: OpenSSH is preinstalled, Terminal.app is decent, and half the "SSH client" category is really about what you add on top. So this roundup is honest about the fact that many Mac users need nothing at all, and then covers what earns its disk space when you outgrow that. One entry is ours: we build Termalin, and this post lives on its blog, so weigh entry nine accordingly.

Prices as of September 2026, checked against official vendor pages.

Tool	Price	Best for
Terminal.app / iTerm2 + OpenSSH	Free	The default answer; iTerm2 for power features
Warp	Free (limited AI credits) / Build $20/mo	AI assistance inside the terminal
Ghostty	Free, open source	Fast, native, minimalist terminal
Termius	Free local / Pro $10/mo (annual)	Sync across Mac, iPhone, iPad
Tabby	Free, open source (MIT)	Open-source tabs + SSH manager
Royal TSX	Free lite mode / €49 perpetual	Mixed RDP + VNC + SSH estates
SecureCRT	$119 perpetual (1 yr updates)	Enterprise emulation and scripting
Core Shell	Free / paid Premium (from $9.99)	Native Mac feel, Keychain integration
Termalin	Free (no host limits) / Pro $8/mo yearly	Integrated SFTP + E2E sync + AI agents

1. Terminal.app or iTerm2, plus plain OpenSSH

The correct first answer, and the first recommendation against our own product in this post. macOS ships a full OpenSSH client; a tidy ~/.ssh/config with aliases and ProxyJump entries, plus the built-in Keychain integration for key passphrases (UseKeychain yes), covers a shocking amount of real work. iTerm2 (free, open source) adds the power features Terminal.app lacks: real split panes, triggers, instant replay, tmux integration, shell integration marks. If your host list fits in your head, stop here and spend nothing.

Best for: everyone as a baseline; iTerm2 for daily heavy use.

2. Warp

Warp treats the terminal as an AI product: output grouped into blocks, an agent that proposes and runs commands, shared workflows for teams. It's genuinely pleasant, and the Mac build is its most mature. The free tier includes a small monthly allowance of AI credits; the Build plan is $20/month. As an SSH client specifically it's serviceable rather than central: there's no real host inventory, SFTP UI, or session recording, because that's not the product. Choose it for the AI, not for server management; the fuller comparison is on our Warp page.

Best for: developers who want an AI pair inside every shell session.

3. Ghostty

The terminal purist's current favorite: native macOS app (real tabs, native windowing), extremely fast, open source, free. It supports macOS and Linux only, with no official Windows build. It is deliberately just a terminal emulator: no host manager, no SFTP, no sync. Pair it with ~/.ssh/config and tmux and it's a beautiful minimal setup; pair it with expectations of a Termius-style app and you'll be confused about what it's for.

Best for: people who want the best possible glass to run plain ssh through.

4. Termius

The strongest reason to pick Termius on a Mac is that your servers follow you to an iPhone and iPad with native apps that are still best in class. The desktop app is clean and the vault model is coherent. The costs: the free plan is local-only on one device, and cross-device sync requires Pro at $10/month billed annually, cloud-hosted by Termius with no self-host option. Desk-only users end up subsidizing mobile they don't use; that math is the subject of our Termius comparison.

Best for: managing servers from Apple devices in your pocket, not just on your desk.

5. Tabby

The open-source pick if you want an actual SSH manager rather than a bare terminal: connection tree, saved credentials, serial support, split panes, plugins, all MIT-licensed and free. On a Mac its Electron nature stands out more than on Windows; it feels heavier than iTerm2 or Ghostty and takes longer to launch. No first-party sync. If Termalin's closed source rules us out for you, this is what we'd suggest. Details on our Tabby page.

Best for: open-source policy, plugin tinkering, serial consoles.

6. Royal TSX

A connection manager first: one window organizing SSH, RDP, VNC, web panels and file transfers across hundreds of entries, with strong credential management. The free shareware mode handles small environments; a personal license is €49, perpetual, with a year of maintenance included. The terminal itself is unremarkable, and the app's breadth means complexity everywhere. But for consultants juggling many clients' mixed infrastructure on a Mac, it has no direct rival. Our head-to-head is here.

Best for: mixed RDP/VNC/SSH estates and MSP-style work.

7. SecureCRT

The enterprise veteran runs natively on macOS, and one $119 perpetual license (with a year of updates) covers Windows, macOS and Linux installs. You buy it for rigor: precise terminal emulation, deep session options, Python scripting, serial and legacy protocols. You tolerate its interface, which has changed little in a decade. Procurement departments love the licensing; designers do not love the rest. Comparison on our SecureCRT page.

Best for: network engineers and orgs that require perpetual licenses.

8. Core Shell

The most Mac-assimilated SSH app here: sandboxed, Keychain-integrated, with per-host themes and automatic reconnect. The free tier includes unlimited hosts; a paid Premium unlock (in-app, from $9.99) adds sync via iCloud, import/export and scripting. macOS 12+ only, and only macOS, which is the point. It's a lovely small tool with a small tool's scope: no SFTP browser, no recording, no cross-platform story.

Best for: Mac-only users who want SSH to feel like a first-party Apple app.

9. Termalin

Ours. What it adds over the stock setup: browser-style tabs across live sessions, an SFTP panel with a built-in editor beside the shell, snippets, live server stats in the status bar, output-only session recording with replay, and end-to-end encrypted sync at $8/month billed yearly (free tier is the full app, local, no host limits, and there's a 14-day Pro trial without a card). The differentiator is the agent layer: a built-in MCP server lets Claude Code or another AI agent work on your hosts through a key custodian, so no private key ever reaches the agent, with every agent session mirrored in a live watch grid.

Against ourselves: Termalin is young, not open source, and current beta builds are unsigned, so Gatekeeper needs a right-click-open on first launch. If you want a pure native-Mac feel, Core Shell and Ghostty are more polished as Mac apps than we are today.

Best for: one integrated window for terminal + files + sync, or supervised AI-agent access to servers.

Coming from MobaXterm? Read this first

A steady stream of people search "MobaXterm for Mac" after switching machines. The short answer: MobaXterm is Windows-only and there is no Mac version, so you're replacing a bundle, not an app. Its two headline features map like this:

X11 forwarding: macOS has no built-in X server. Install the free XQuartz, and ssh -X works from any client on this page, including Terminal.app. That's the whole migration.
The automatic SFTP sidebar: this is the part people actually miss. Cyberduck (free) as a separate window is the classic answer; if you want the MobaXterm-style files-next-to-terminal layout in one app, that's precisely what Termalin's SFTP panel does, and our MobaXterm comparison walks through the rest of the mapping.

The short version

Nothing wrong with free: iTerm2 + OpenSSH is a complete answer, Ghostty if you want it faster and prettier. Apple-native small tool: Core Shell. Mobile-first: Termius. Mixed protocols: Royal TSX. Perpetual enterprise: SecureCRT. Open source with a host manager: Tabby. Integrated terminal + SFTP + encrypted sync, or AI agents: us. The platform-level guide lives at SSH client for macOS.

Disclosure: this blog is written by the Termalin team. Free, no host limits, runs on macOS, Windows and Linux — download it and see if it beats your current setup.

Best SSH Clients for Windows in 2026: 9 Tested

Svyatoslav Pavlov — Thu, 10 Sep 2026 17:22:36 +0000

Windows is the platform where SSH client choice actually matters. On a Mac or a Linux box you can live in the stock terminal forever; on Windows the gap between "PuTTY and a pile of windows" and a good integrated client is measured in hours per week. We run all of these on real Windows 11 machines, and one of them is ours: we build Termalin, so read entry nine knowing that, and note that we recommend against ourselves twice below.

Prices as of September 2026, checked against official sites.

Tool	Price	Best for
PuTTY / KiTTY	Free	Minimal, portable, runs anywhere
Windows Terminal + OpenSSH	Free (in the box)	The no-install baseline
MobaXterm	Home free / Pro $69 per user/year	X11 forwarding, bundled admin tools
Bitvise	Free (all use, incl. commercial)	Best-in-class SFTP and tunneling GUI
mRemoteNG	Free, open source	Mixed RDP + SSH fleets in one window
WindTerm	Free, source published (Apache-2.0)	Fastest rendering, low-spec hardware
Tabby	Free, open source (MIT)	Open-source tabs, plugins, serial
Termius	Free local / Pro $10/mo (annual)	Cross-device sync incl. native mobile apps
Termalin	Free (no host limits) / Pro $8/mo yearly	Integrated SFTP + E2E sync + AI-agent access

All of these are Windows-native; every price was taken from the vendor's own page.

1. PuTTY / KiTTY

Still the reflex answer, still fine. PuTTY is tiny, stable, and auditable; it does SSH, Telnet and serial, and nothing else. No tabs, no file browser, no sync: you add WinSCP for files and Pageant for keys, and your "client" is really a toolkit of four programs. KiTTY is the fork that patches the daily irritations (session filters, portability, stored passwords) at the cost of tracking upstream with a delay. If you've built decades of muscle memory here and want to keep it, nobody should talk you out of it; if the multi-window juggling is the problem, that's the itch our PuTTY comparison addresses.

Best for: locked-down machines, USB-stick portability, one-job simplicity.

2. Windows Terminal + built-in OpenSSH

The baseline people forget exists. Windows 10 and 11 ship a real OpenSSH client; Windows Terminal gives it tabs, panes, and profiles that can launch ssh myserver directly. Add a ~/.ssh/config and the native ssh-agent service and you have a genuinely good setup for zero dollars and zero installs, which matters on corporate machines where you can't install anything. What's missing: any visual host inventory, SFTP UI, or sync. It's the Windows equivalent of the Linux answer, and it's the second recommendation against ourselves in this post: if your needs stop at "a few servers, keys, tabs," start here and spend nothing.

Best for: admins on restricted machines, and anyone's first month of SSH.

3. MobaXterm

The Swiss-army option. One window contains sessions, an automatic SFTP sidebar for every SSH connection, an embedded X server (still the killer feature: ssh -X just works), plus bundled tools from port scanners to a local shell with Unix commands. Home Edition is free with real caps: 12 sessions, 2 tunnels. Professional is $69 per user/year. The interface is an acquired taste, dense in a very 2010 way, and there's no sync between machines. But nothing else on Windows matches the X11-plus-SFTP combo, which is why it keeps its seat. Full rundown on our MobaXterm page.

Best for: sysadmins who need remote GUI apps and love a toolbox.

4. Bitvise

Quietly excellent and genuinely free for all use, including commercial (paid licenses exist, but they buy support commitments, not features). The terminal is plain, but that's not why you run Bitvise: its graphical SFTP client is fast and robust, its port-forwarding UI is the clearest we've used anywhere, and single-click remote desktop over an SSH tunnel is built in. Windows only, closed source, and visually stuck in the Windows 7 era. We compare it with Termalin here.

Best for: heavy SFTP transfers and tunneling without memorizing -L/-R syntax.

5. mRemoteNG

A free, open-source connection manager that puts RDP, SSH, VNC, Telnet and more in one tabbed window, with a folder tree for hundreds of connections. The SSH side is actually embedded PuTTY, so terminal quality is exactly PuTTY's. Development moves slowly, with long gaps between stable releases, and the config file holding your credentials deserves careful handling. But if your day is 60% RDP into Windows servers and 40% SSH into Linux ones, nothing free does the mixed-fleet job better.

Best for: Windows admins with mixed RDP + SSH estates.

6. WindTerm

The performance champion: startup, rendering and scrolling are noticeably quicker than anything else here, and it's free for commercial use with source published under Apache-2.0. Sessions, SFTP, and a clever shell-aware autocompletion are all in the box. One thing to weigh: the maintainer has publicly said development time has dropped to a fraction of what it was, so treat the current version as the product. It's a very good current version.

Best for: speed above all, older laptops, terminal purists who still want sessions.

7. Tabby

The open-source modern option: MIT-licensed, tabs and split panes, a real SSH connection manager, serial support, and a plugin ecosystem. Being an Electron app, it eats more RAM than anything else in this list, and startup is leisurely. No first-party sync; config-file sync is DIY. If "not open source" disqualifies Termalin for you, and it's a fair disqualifier, Tabby is what we'd point you to on Windows. Longer comparison here.

Best for: open-source policy shops and plugin tinkerers.

8. Termius

The polished cross-platform incumbent. The Windows app is clean, and the real product is the ecosystem: hosts, keys and snippets syncing across desktop and genuinely good iOS/Android apps. The free plan is local-only on one device; sync requires Pro at $10/month billed annually, and sync runs only through Termius's cloud. If mobile is central to your workflow, it earns the money. If you only ever SSH from your desk, you're paying the mobile tax without using it; the alternatives are cataloged in our Termius comparison.

Best for: people who manage servers from a phone as often as a desk.

9. Termalin

Ours, so hold it to the harshest standard. What it is: a native-feeling client for Windows, macOS and Linux with browser-style tabs, an SFTP panel with a built-in editor next to the shell, live server stats in the status bar, snippets, and output-only session recording with replay. Sync is end-to-end encrypted (the server stores ciphertext only) at $8/month billed yearly, and the free tier is the full desktop app with no host limits. The unusual part is the agent layer: a built-in MCP server lets Claude Code or another AI agent open sessions through a key custodian, so the agent never touches a private key, while every agent session is mirrored live in a watch grid.

Weaknesses, plainly: it's young, it's not open source, and current beta builds are unsigned, so SmartScreen will warn you on first launch until our signing certificate lands. If any of those three is disqualifying, pick Tabby or Bitvise above; both are excellent.

Best for: an integrated terminal + SFTP + E2E sync workflow, or giving AI agents supervised access to your servers.

Worth a look: XPipe

Not a terminal, so it's outside the numbered list: XPipe is a connection hub that discovers SSH hosts, Docker containers, K8s pods and WSL distros and opens them in whatever terminal you chose above. Free Community tier; paid tiers from $5/month.

The short version

Restricted machine: Windows Terminal + OpenSSH. X11: MobaXterm. SFTP and tunnels: Bitvise. Mixed RDP fleet: mRemoteNG. Open source: Tabby or PuTTY. Mobile-first: Termius. Integrated everything with encrypted sync, or AI agents on your hosts: us. There's a deeper platform guide at SSH client for Windows.

Disclosure: this blog is written by the Termalin team. The free tier has no host limits — download Termalin and compare it against whatever you use today.

9 Termius Alternatives in 2026 (Free and Paid, Tested)

Svyatoslav Pavlov — Wed, 09 Sep 2026 15:18:11 +0000

Termius is a polished client, and if it's working for you, keep it. But the reasons people go looking for a replacement are consistent, and they're structural, not cosmetic. The free Starter plan keeps your hosts in a local vault on one device: no cross-device sync, no session logs, no snippet automation. Unlocking sync means Pro at $10 per user per month billed annually, and that sync only goes through Termius's cloud; there is no self-hosted or file-based option. On mobile, the same paywall bites hardest, because a phone is exactly where you want your hosts to follow you.

So here are nine alternatives we've actually run, with prices checked in September 2026. Cards on the table: we build Termalin, entry number one, and this blog lives on its site. We've tried to judge it by the same bar as everything else, including telling you when a competitor is the better pick.

Tool	Platforms	Price	Best for
Termalin	Windows, macOS, Linux	Free (no host limits) / Pro $8/mo yearly	Termius workflow with cheaper E2E sync, AI-agent access
Tabby	Windows, macOS, Linux	Free, open source (MIT)	Open-source replacement with plugins
MobaXterm	Windows only	Home free / Pro $69 per user/year	Windows admins who need X11 and bundled tools
PuTTY / KiTTY	Windows (PuTTY also Unix)	Free	Minimalists, locked-down machines
WindTerm	Windows, macOS, Linux	Free (Apache-2.0 published source)	Raw speed on old hardware
XPipe	Windows, macOS, Linux	Free / Homelab $5/mo / Pro $10/mo	Browsing Docker, K8s and VMs, not a terminal itself
SecureCRT	Windows, macOS, Linux	$119 perpetual (1 yr updates)	Enterprise emulation, scripting, serial
Warp	Windows, macOS, Linux	Free (limited AI credits) / Build $20/mo	AI inside the terminal, not host management
OpenSSH + tmux	Everywhere	Free	The baseline that never bills you

Prices as of September 2026, from official sites; check before buying.

1. Termalin

The closest feature-for-feature match on this list: tabbed terminal, SFTP panel with a built-in editor, snippets, live server stats, and account-based sync that is end-to-end encrypted, so the server only ever stores ciphertext. Pro is $8/month billed yearly ($10 month-to-month) against Termius's $10, and the free tier is the full desktop app with no host limits, just local-only. There's a 14-day Pro trial with no card. Two things Termius doesn't attempt: output-only session recording with replay, and a built-in MCP server so AI agents like Claude Code can use your hosts through a key custodian (the agent never sees a key) while you watch every session live in a grid.

Now the honest part. Termalin is a young product; it is not open source; and the current beta builds are unsigned, so Windows shows a SmartScreen warning on first run. Phones are covered by a web app, not native apps, so if the Termius iOS or Android client is the reason you pay, nothing on this list fully replaces that and you should read no further. The full head-to-head is on our Termius comparison page.

Best for: keeping the Termius workflow while paying less for sync, or giving an AI agent supervised SSH access.

2. Tabby

If your objection to Termius is philosophical, Tabby is the answer: free, MIT-licensed, genuinely cross-platform, with a plugin ecosystem, serial support, and an SSH connection manager built in. It's an Electron app, so it's heavier on RAM than a native terminal, and there's no first-party cloud sync; you sync settings via config files or community plugins, which is either a dealbreaker or exactly the point, depending on your threat model. We keep a detailed Tabby comparison if you want the long version.

Best for: anyone who wants the source code and zero subscriptions.

3. MobaXterm

Windows only, and unapologetic about it. The Home Edition is free but capped at 12 sessions and 2 SSH tunnels; Professional is $69 per user per year and lifts the caps. What you get for living inside one app: an embedded X server (still the easiest way to run remote GUI apps on Windows), automatic SFTP browser per session, and a small arsenal of bundled network tools. The UI is dense and dated, and there's no sync story at all. Details in our MobaXterm comparison.

Best for: Windows sysadmins who need X11 forwarding without ceremony.

4. PuTTY / KiTTY

The opposite trade from Termius: no accounts, no sync, no tabs, no telemetry, no cost. PuTTY is small enough to run from a USB stick and battle-tested over decades; KiTTY is a Windows fork that adds session filters, portability and automatic passwords. You will assemble the rest of the workflow yourself (WinSCP for files, Pageant for keys). If that assembly is the part you hate, see our PuTTY comparison.

Best for: locked-down corporate machines and people who want one binary that does one thing.

5. WindTerm

The fastest client on this list, and it isn't close on older hardware. Free for commercial use, with published source under Apache-2.0. It has sessions, SFTP, and a shell-aware input line that autocompletes from history. The caveat you should know before adopting it: the sole maintainer has said openly that work commitments have cut development pace to a fraction of what it was. The project isn't abandoned, but issues sit longer than they used to. Adopt it for what it is today, not its roadmap.

Best for: speed junkies and low-spec machines.

6. XPipe

Not a terminal: XPipe is a connection hub that discovers and organizes everything you can shell into (SSH hosts, Docker containers, Kubernetes pods, VMs, WSL) and opens them in the terminal and editor you already use. The Community tier is free with unlimited connections; Homelab is $5/month and Professional $10/month (or $80/year). If your Termius pain is "too many kinds of things to connect to" rather than the terminal itself, this is the interesting answer. Comparison here.

Best for: heterogeneous infrastructure: containers and VMs, not just hosts.

7. SecureCRT

The enterprise workhorse. $119 for a perpetual license with a year of updates, one license valid across Windows, macOS and Linux. Its terminal emulation and scripting (Python, VBScript) are the most rigorous in this roundup, and it handles serial, Telnet and legacy protocols that consumer clients dropped years ago. It looks and feels like the twenty-year-old professional tool it is, and that's a compliment or an insult depending on your day job. Our take versus Termalin is on the SecureCRT page.

Best for: network engineers, serial consoles, compliance-minded shops that want perpetual licenses.

8. Warp

Warp is what happens when the terminal itself becomes an AI product: block-based output, shared notebooks, and an agent that writes and runs commands. The free tier includes a modest monthly allowance of AI credits; the Build plan is $20/month. As a Termius replacement specifically, it's a partial fit: SSH works fine, but host management, sync of server inventory, and SFTP are not what Warp is optimizing for. You'd be switching categories, not vendors. More in our Warp comparison.

Best for: developers who want AI assistance in every shell, local or remote.

9. OpenSSH + tmux + ~/.ssh/config

The baseline deserves its slot. A well-kept ~/.ssh/config gives you aliases, jump hosts and per-host keys; tmux gives you sessions that survive disconnects; ssh-agent gives you one passphrase per day. It costs nothing, runs everywhere, and will outlive every company on this page. What it lacks is exactly what people pay for: a visual host list, file transfer UI, and anything resembling sync across machines.

Best for: everyone, as a floor. Learn it even if you buy something on top.

Also considered

Bitvise and mRemoteNG are both solid and free but Windows-only, so they're covered in our Windows roundup instead. Royal TSX is macOS-only and appears in the Mac roundup.

How to choose

Open source or nothing → Tabby, or PuTTY if you want minimal. Not us.
Mobile apps are non-negotiable → stay on Termius, honestly. Its iOS/Android clients are still the best in class.
X11 on Windows → MobaXterm.
Perpetual license for procurement → SecureCRT.
Containers and VMs everywhere → XPipe, possibly alongside one of the terminals above.
Same workflow, E2E sync, smaller bill, or AI agents on your hosts → that's the corner we built Termalin for.

One-line disclosure, as always: this blog is written by the Termalin team. Termalin is free with no host limits on Windows, macOS and Linux — download it and judge the rest yourself.

Let Claude Code and Cursor query your database (safely) — the MCP setup

Svyatoslav Pavlov — Tue, 08 Sep 2026 17:20:07 +0000

An agent that can read your database answers questions you'd otherwise open a SQL editor for. "Why did signups drop on Tuesday?" "Which orders have been stuck in pending for more than an hour?" "What's actually in the events table?" With a query capability the model answers in seconds; without one it guesses. The useful part isn't the SQL — Claude Code and Cursor both write SQL fine — it's giving the agent a way to run a read without handing it your credentials. That handoff is the whole friction, and it's what this post walks through for both tools.

We've written separately about why pasting a database connection string into an agent is the move you can't undo — the credential is bearer access, it can write and drop as well as read, and once it's passed through a model's context you can't un-share it. Read that for the safety model; here we take it as settled and get the wiring done. The short version: the client holds the credential, the agent gets a scoped, read-only-by-default ask.

What you need

Termalin — the desktop app, free tier is fine. It's an SSH and database client with a built-in MCP server; that local server is what your agent will talk to.
At least one database connection saved in Termalin's Data client — Postgres, MySQL, SQLite, SQL Server, ClickHouse, MongoDB, Redis, and more. Pick something low-stakes for the first run: an analytics replica, a staging database, a copy.
Claude Code or Cursor on the same machine as the app. The database tools drive the live desktop app, so the agent and the app share a box.

One expectation to set: for Claude Code and Cursor, database access runs through the local stdio MCP server, so the agent needs to be on the same machine as your unlocked desktop app. (There's a hosted path too — the connectors for claude.ai and ChatGPT can query an enrolled server's databases passwordless through termal.in/api/v1/mcp, using the server's own local database trust — but for a local IDE agent, the local server is the one you want.)

Step 1 — turn agent data access on

This is off by default, and deliberately so. Open Settings → Agent and enable "Let agents query your databases." The subtitle spells out the posture: off by default, and stays read-only unless a connection grants full access. Until you flip it, every database tool returns database access for agents is off — enable it in Settings → Agent, full stop.

Two defaults are worth internalizing before you go further:

It's a second opt-in, on top of the running app. Turning on agent access to servers doesn't turn on database access — this is its own switch. Nothing is exposed until you make the decision.
Every connection is read-only for the agent. Even with the master switch on, each query is checked before it runs. A write only goes through if you've raised that specific connection's agent policy to full access — a per-connection choice, not a global one. Leave it read-only for now.

The credential itself never moves: the connection's host, port and password stay in the app's vault, and the agent only gets to ask the running app to run a query and hand back rows. There's no connection string in a config file for the agent — or a prompt injection — to read.

Step 2 — register the local MCP server

Claude Code — one command:

claude mcp add termalin -- <path>/termalin-mcp

Replace <path> with wherever the termalin-mcp binary lives (the app can point you at it). Restart Claude Code and it picks up the tools.

Cursor — Cursor reads MCP servers from a JSON file: .cursor/mcp.json in a project root for that project only, or ~/.cursor/mcp.json to make the server available everywhere. For a local stdio server the entry is a command and its arguments:

{
  "mcpServers": {
    "termalin": {
      "command": "<path>/termalin-mcp",
      "args": []
    }
  }
}

The global file is the sensible choice — database access isn't a per-repo concern. Restart Cursor (or reload the MCP list in its settings) and confirm the server shows as running. This is the same registration the Cursor SSH walkthrough and the Claude Code one use — one server, and it now carries the database tools alongside the SSH ones.

Step 3 — the tools, and a real first task

With the server registered and the switch on, the agent sees four database tools:

data_list     # your saved connections: id, name, engine, and whether the agent may write
data_tables   # tables / collections / measurements for a connection, with row counts
data_schema   # one table's columns: name, type, nullable, primary key
data_query    # run a query in the connection's own language; default cap 200 rows

They mirror how you'd explore a database by hand: list what's connected, see the tables, describe a table, run the query. data_query speaks whatever the connection speaks — SQL for the relational engines and ClickHouse, Cypher for Neo4j, a Redis command, a collection {filter} for MongoDB — and returns rows up to a cap you can raise per call (maxRows), defaulting to 200 so an agent can't accidentally pull a million rows into its context.

Now give it a question you'd actually ask, not a demo query:

Signups dropped on Tuesday according to the dashboard. Using the analytics database, figure out what happened.

Watch the agent work the tools in order:

data_list — it finds your analytics connection, sees the engine is Postgres, and notes it's read-only for the agent.
data_tables — it lists the tables, spots signups and signup_events, and reads the row counts to know what's worth querying.
data_schema on signups — it learns the columns (created_at, source, status, …) and now knows how to slice by day and by source.
data_query — it runs something like SELECT date_trunc('day', created_at) AS day, source, count(*) FROM signups WHERE created_at >= now() - interval '10 days' GROUP BY 1, 2 ORDER BY 1 and reads the rows back.

The rows tell the story — maybe one source went to zero on Tuesday (a broken referral link), maybe the total held but status = 'failed' spiked (a provider outage). Either way the agent formed its query from the real schema, not a guess, and never held anything more than the ability to ask. If a result truncates at the 200-row cap, it says so and narrows the query rather than pushing for more.

Where the boundaries are

Brief, because the safety post covers it in full — but the defaults you're relying on:

Read-only by default. On the SQL-family engines only read verbs pass — SELECT, SHOW, DESCRIBE, EXPLAIN, WITH, PRAGMA. On Redis, only read commands; on MongoDB, an aggregation with $out/$merge is blocked; on Neo4j, CREATE/MERGE/DELETE/SET/DROP are blocked. A confused or hijacked model gets a read, not a DROP.
Per connection, not global. Your analytics replica is a separate decision from your production primary; raising one to full write access doesn't touch the other.
Off with one toggle, and the app holds the credential — nothing was ever shared, so turning it off leaves no copies and no password to rotate.

For anything sensitive, do both: point the Data connection at a read replica or a least-privilege database role and leave the agent read-only. The client-side gate catches mistakes; the database grant sets the ceiling.

Tool-specific notes

Cursor asks before each tool call by default. Leave that on for the first sessions — you'll see every data_query before it runs and can read the SQL the agent proposes. Auto-approval is a convenience to extend one tool at a time: data_list and data_schema are safe to wave through first, data_query the one to keep on manual longest.
Claude Code surfaces each tool call inline with its arguments, so the query text is in the transcript before it executes. You're reading the agent's SQL, not trusting a summary of it — and every call is attributed to the agent, so at 2 a.m. you can tell "it read this" from "I read this."

Where Termalin fits

Most "connect your agent to a database" guides end at pasting a connection string into a config file, which quietly grants an agent the same write-and-drop power your app has. Termalin's Data client inverts that: the app is the custodian, the agent gets four scoped tools driven through the running window, and the whole capability is read-only until you decide otherwise and off with a single switch. It's the same custody idea we apply to SSH access for agents and to what an MCP server actually is — a database is just the version where a bad write is measured in rows. Start with one connection, keep it read-only, and ask something real before you consider widening anything.

Termalin is a free, cross-platform SSH and database client with a built-in MCP server and a per-connection agent policy — download it, or read how it handles credentials safely.

Connect to a database behind a firewall — over an SSH tunnel, without exposing the port

Svyatoslav Pavlov — Mon, 07 Sep 2026 11:54:33 +0000

You've got a database on a server somewhere, and you want to reach it from your laptop — run a query, point a GUI at it, let a migration tool connect. It listens on 5432 (Postgres) or 3306 (MySQL), and right now your laptop can't get to it, because the database sits on a private network with no route from the outside. So you go looking for the fastest bridge, and the internet offers a shortcut that works immediately and quietly costs you the thing the private network was protecting.

The mistake: opening the database port to the world

The shortcut is to make the database reachable: bind it to 0.0.0.0 instead of 127.0.0.1, punch a hole in the security group for port 5432, and now you can connect from anywhere. It works on the first try, which is exactly why it's dangerous.

A database port on the public internet is a standing target. Postgres and MySQL speak on well-known ports, and the whole internet is scanned for them continuously — a listener on 5432 starts collecting login attempts within minutes of going up. The only thing between the internet and your data is now the database's own password, one protocol quirk, or one CVE. Managed databases don't let you do this by accident: RDS, Cloud SQL and the rest default to a private subnet with no public IP, precisely because a database is the last thing you want facing the internet. Opening it up anyway — a 0.0.0.0/0 rule "just for now" — trades the whole design away for a few minutes saved. The fix costs about as little and gives up nothing.

What an SSH tunnel to a database actually does

You almost certainly already have a way onto that network: an SSH login to a server that can see the database — the app server, a bastion, any box on the same subnet. SSH port forwarding lets you borrow that reach without exposing anything new.

ssh -L 5432:db.internal:5432 deploy@bastion.example.com

Read it left to right: open port 5432 on my laptop, and forward anything that arrives there to db.internal:5432 as resolved from the bastion. Then you point your client at localhost:

psql -h 127.0.0.1 -p 5432 -U app appdb

psql connects to your own machine; SSH carries the bytes, encrypted, over the connection you already had; the bastion opens a plain connection to db.internal from inside the private network, where it's allowed to. From the database's point of view nothing changed — it still only accepts connections from its own network. And no new port was opened anywhere on the internet. You got reachability without exposure.

The one detail that trips everyone up: db.internal is resolved on the far side, by the bastion, not by your laptop. It can be a name only the private network knows, or a raw address your laptop can't route to:

# the database only the bastion can see, by private IP
ssh -L 5432:10.0.0.9:5432 deploy@bastion.example.com

That's the whole trick, covered in depth — local, remote and dynamic — in SSH port forwarding explained. Here we only need the local (-L) case.

The bastion is where the tunnel starts

The box you tunnel through is usually the same gateway you already jump through to get a shell on the private network. If you reach your internal servers with ProxyJump, you already have the piece a database tunnel needs. The two are complementary: ProxyJump gets your shell onto a host behind the gateway, and -L brings a service's port from the far side back to your localhost. If you have to hop through two gateways, chain them:

ssh -J bastion.example.com -L 5432:db.internal:5432 deploy@app.internal

Why people still get the tunnel wrong

The mechanism is clean. The day-to-day of running tunnels by hand is where it frays:

The command rots in your shell history. Next week you're reconstructing which local port mapped to which database, on which bastion, in which environment. Staging and production both want 5432; you get one at a time on your laptop.
The local port is open to every process on your machine. -L 5432 listens on 127.0.0.1:5432 — any program on your laptop can now reach the production database through it, no SSH auth required, for as long as the tunnel is up. (And -L 0.0.0.0:5432:... quietly exposes it to your whole LAN.)
The tunnel dies mid-session and takes the query with it. A laptop sleep, a Wi-Fi change, an idle timeout, and the forward drops silently — usually solved with -N, -f and ServerAliveInterval 30, none of which you remembered the first time.
One ssh -L per database. A primary, a read replica, a MySQL box, a Redis — that's four tunnel commands on four local ports, each re-run after every disconnect, none telling you at a glance whether it's still up.

A saved ssh_config block — LocalForward, a ProxyJump, keepalives — smooths most of this over. But you're still starting it by hand, still watching it, still pointing your client at the right loopback port yourself.

How Termalin's Data client does it

Termalin is a cross-platform SSH client that recently grew a Data client — a database client in the desktop app and in the web cabinet at termal.in/account. You add a database the way you'd add a server: pick the engine, give it a host, port and credentials, optionally a default database. It speaks a wide spread of engines — PostgreSQL, MySQL, SQL Server, ClickHouse, MongoDB, Redis, Elasticsearch, Neo4j and more. The part this article is about is what happens when that database is behind a firewall — you don't open a port and you don't hand-run ssh -L:

A database on a network you can already route to, you reach directly. Termalin dials the host and port you gave it.
A database behind a firewall, you reach through a tunnel. On the desktop, attach a saved SSH host — your bastion, jump host and all — to the connection; Termalin opens a local forward on that session and points the driver at the resulting 127.0.0.1:<port> for you, so a database that only listens on localhost or sits behind a VPN comes through as if it were local. In the web cabinet, the same job is done by a Connector: Termalin opens the Connector's SSH session, forwards a loopback port through it, and runs the query over that. Either way the encrypted SSH session carries the traffic to a box that can see the database, and the database itself never faces the internet.

So you keep what the private subnet was there to give you — a database reachable only from inside its own network — while getting a working query editor on your laptop. The tunnel comes up with the connection and goes down when you close it, along with the loopback port it opened. There's no command to remember, no forward to babysit, and no 0.0.0.0/0 rule left behind in a security group.

A tunnel is reachability, not authorization

Worth stating plainly, because it's the one thing a tunnel doesn't do: getting the connection to the database isn't the same as deciding what it may do once it's there. A tunnel is a wire, and a wire is neutral — whoever's on the other end still connects as whatever database user you handed over. Point the connection at a least-privilege role, and if an agent is going to be on the other end of it, keep that a separate decision — the subject of giving an AI agent read-only database access, not this one.

Where Termalin fits

Every developer should know ssh -L cold — it's the honest way to reach a database without opening it to the world, and the mental model (open a port on my side, forward it to something the far side can see) is the whole game. The friction was never the concept; it was the bookkeeping: the commands in your history, the ports you juggle, the tunnels that drop, the one forward per database.

Termalin keeps the tunnel and the database connection as one saved thing. Attach a jump host or a Connector, and reaching a database on a private subnet is a click — the forward opens with the connection, the driver points at the loopback port for you, and the database stays exactly where it belongs: behind the firewall, listening only to its own network.

*Termalin is a free, cross-platform SSH and database client with built-in tunnels, jump hosts and a Data client — download it, or see how it handles your keys and credentials safely.

How to give an AI agent safe access to your database (read-only by default)

Svyatoslav Pavlov — Fri, 04 Sep 2026 11:24:00 +0000

An agent that can read your database is genuinely useful. "Why did signups drop on Tuesday?" "Find the orders stuck in pending for more than an hour." "What's the schema of the events table?" These are questions the model answers in seconds if it can run a query — and slowly, badly, or never if it can't. So you go looking for how to connect it, and every guide says the same thing: put your database connection string in the agent's environment, or in an MCP server's config, and you're done.

You are done, in the sense that it works. But you've also made a security decision, whether you meant to or not. The moment an agent can touch a real database, the interesting question isn't "can it write SQL" — of course it can. It's who holds the credential, and what can that credential do.

The naive path, and why it's a trap

A database connection string is a bearer credential. postgres://app:hunter2@db.internal:5432/prod isn't a pointer to access — it is access. Whoever holds those bytes can connect as that user, with everything that user can do. And the user in your app's connection string can almost always do a lot more than SELECT: INSERT, UPDATE, DELETE, DROP TABLE, TRUNCATE. You wanted the agent to answer a question about last week's signups; you handed it the ability to delete them.

Three things make this worse than it looks:

You can't un-share it. Once a connection string has passed through a model's context — an env var, a config blob, a tool call you didn't read — you can't prove it didn't end up in a transcript or a log. The only honest remediation is to rotate the database password everywhere it's used.
Prompt injection reaches it. A poisoned row, a booby-trapped document, a tool result from elsewhere in the session — any of these can talk a model into running a query you never asked for, or into exfiltrating the very credential it was handed. The agent's context is not a safe place to keep a secret.
There's no scope and no expiry. A raw connection string doesn't come with a "read-only" mode or a clock. If the account can write, the agent can write. If the credential never expires, neither does the access.

The rule of thumb is the one we keep coming back to for SSH keys: if revoking a credential means remembering it exists and rotating it everywhere, you'll put it off, and it will outlive the experiment.

What good looks like: the client holds the credential

Flip the model. The agent should never hold the connection string at all.

The client is the custodian. A trusted program holds the database credential and does the connecting. The agent doesn't get the secret — it gets the ability to ask that program to run a query and hand back rows.
Read-only is the default, not an option you remember to set. Write and schema-changing statements are refused unless you've explicitly granted that specific connection more. A confused or hijacked model gets SELECT, not DROP.
Scope is per connection. Access to your analytics replica is a separate decision from access to your production primary. Enabling one doesn't enable the other.
Revocation is a toggle. Because nothing was ever shared, turning access off costs nothing and leaves no copies behind.

This is the same custody thesis we apply to servers — in shrinking an agent's blast radius and in what an MCP server actually is. Databases are just the sharpest version, because the blast radius of a bad write is measured in rows.

How Termalin's Data client works

Termalin is a cross-platform SSH client that recently grew a Data client — a database client in the desktop app and in the web cabinet at termal.in/account. You add a connection the way you'd add a server: pick the engine, give it a host and credentials (or, for SQLite, a file), optionally name a default database. Then you get a workspace — a tree of databases and tables on the left, a SQL editor in the middle, results below. Click through the schema, write a query, read the rows. None of that requires an agent; it's a normal, useful database client.

The Data client speaks a spread of engines, not just Postgres:

PostgreSQL, MySQL / MariaDB, and SQLite
Microsoft SQL Server and ClickHouse
MongoDB / DocumentDB
Redis
Elasticsearch / OpenSearch
Cassandra / ScyllaDB
Neo4j and InfluxDB
RabbitMQ
Cloudflare D1

Each speaks its own query language — SQL for the relational engines and ClickHouse, Cypher for Neo4j, a Redis command, a collection {filter} for MongoDB, and so on.

Direct, or through a Connector. A database on your own network, you reach directly. A database behind a firewall — the common case in production — you reach through a Termalin Connector: it opens an SSH tunnel to a box that can see the database, forwards a loopback port through it, and points the driver at that port. The database never faces the internet, and you never open a port to it.

Where the agent comes in

Termalin ships a built-in MCP server, and once you turn agent data access on it exposes four database tools:

data_list     # your saved connections: id, name, engine
data_tables   # tables / collections / measurements, with row counts
data_schema   # one table's columns: name, type, nullable, primary key
data_query    # run a query, get rows back (default cap 200)

Register the local server and it drives the Data client inside your running, unlocked app, so the connection details stay with the client:

claude mcp add termalin -- <path>/termalin-mcp

(No desktop running? The connectors for claude.ai and ChatGPT reach an enrolled server's databases the same read-only way through the hosted endpoint — passwordless, using the server's own local database trust, no local app required.)

The agent can now discover connections, walk a schema, and run queries. What it can't do is anything you didn't allow, because two gates sit in front of it:

Agent data access is off by default. A single master switch in Settings → Agent. Until you flip it, the data tools return "database access for agents is off," full stop.
Every connection is read-only for the agent by default. Even with the master switch on, each query is checked before it runs. On the SQL-family engines only read verbs pass — SELECT, SHOW, DESCRIBE, EXPLAIN, WITH, PRAGMA. On Redis, only read commands. On MongoDB, an aggregation with $out or $merge is blocked. On Neo4j, CREATE, MERGE, DELETE, SET, DROP are blocked. A write only goes through if you've raised that specific connection's agent policy to full access — a per-connection decision, not a global one.

So the property you wanted holds. The agent can answer "why did signups drop on Tuesday?" by reading the rows. It cannot delete Tuesday.

What "read-only by default" actually gets you, honestly

It's a query gate, and it's worth being precise about its edges. It stops the obvious destructive path — the accidental or injected DELETE, DROP, UPDATE, the aggregation that writes back out. What it is not is a substitute for a properly scoped database role: a SELECT can still read data you'd rather it didn't. For anything sensitive, do both — point the Data connection at a read replica or a least-privilege role and leave the agent read-only. The client-side gate catches the mistakes; the database-side grant sets the ceiling. And because the agent works through your running app, no connection string is written anywhere it can read, and the whole thing switches off with one toggle.

Where to start

Start read-only, with one connection you don't mind an agent poking at — a staging database, an analytics replica, a copy. Leave the per-connection policy where it defaults: read-only. Ask the agent something real — describe a table, count the stuck orders, explain the slow query — and watch how it forms its SQL before you consider granting anything more. If you later want it to write, raise exactly one connection to full access, and know precisely what you traded.

That's the quiet payoff of the custodian model, whether it's shells or schemas: you expand one connection at a time, because no step you take is one you can't take back.

Termalin is a free, cross-platform SSH and database client with a built-in MCP server, a key custodian and per-connection agent policy — download it, or read how it handles credentials safely.

GitHub / GitLab SSH key not working: the fix, step by step

Svyatoslav Pavlov — Thu, 03 Sep 2026 08:57:05 +0000

An SSH key that won't authenticate to GitHub or GitLab is one of the most-Googled developer problems there is, and half the time the key is fine — the diagnosis is just wrong. So before you regenerate anything, run one test and learn to read its answer. Then work the culprits in order of how often they're actually the cause.

Step 0: the test that tells you if it's even broken

Ask the git host directly whether it recognizes your key:

ssh -T git@github.com        # GitHub
ssh -T git@gitlab.com        # GitLab

Now read the response carefully, because the success message looks like an error:

Hi <username>! You've successfully authenticated, but GitHub does not
provide shell access.

That is success. "Does not provide shell access" is not a failure — GitHub and GitLab don't give you a shell, they only speak git over SSH, so they authenticate you and then hang up. People see "does not provide" and start troubleshooting a working setup. If you see your username in that line, your key works; your problem is somewhere else (jump to the HTTPS remote culprit below — that's the usual real issue).

The genuine failure looks like this instead:

git@github.com: Permission denied (publickey).

That's the one we're here to fix. Note the endpoint: Permission denied (publickey) means the server accepted no key you offered. Work down the list.

Culprit 1: the key isn't added to your account

The most common real cause. A key on your laptop does nothing until its public half is registered with the git host. Copy the public key:

cat ~/.ssh/id_ed25519.pub     # note the .pub — this is the safe half to share

Paste that into GitHub → Settings → SSH and GPG keys → New SSH key, or GitLab → Preferences → SSH Keys.

One rule, no exceptions: paste the .pub file, never the file without .pub. The public key is one line starting ssh-ed25519 AAAA… (or ssh-rsa AAAA…). If what you're about to paste starts with -----BEGIN OPENSSH PRIVATE KEY-----, stop — that's your private key, the secret that is your identity. Pasting it into a web form hands your credential to anyone who can read that page. Share the public half; guard the private half.

(No key yet? Generate one — Ed25519 in almost all cases: ssh-keygen -t ed25519 -C "you@device".)

Culprit 2: the wrong key is being offered

Your key is registered, but SSH is offering a different one — common when you carry several keys and the agent tries them in an order the server rejects. See exactly which key is sent:

ssh -vT git@github.com

Look for the Offering public key: lines. If the key you registered isn't among them, or a wrong one is being accepted, pin the right key per host in ~/.ssh/config:

Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

IdentitiesOnly yes is the key line — it tells SSH to offer only the IdentityFile you named and stop spraying every key in your agent at the server (which also cures Too many authentication failures). Do the same with Host gitlab.com for GitLab. More on structuring the file in the ssh_config guide.

Culprit 3: the agent isn't running, or the key isn't loaded

If your key has a passphrase and the agent doesn't hold it, SSH may skip it silently. Check what the agent has:

ssh-add -l

The agent has no identities (or Could not open a connection to your authentication agent) means you need to start it and load the key:

eval "$(ssh-agent -s)"        # start the agent in this shell
ssh-add ~/.ssh/id_ed25519     # load the key (prompts for the passphrase once)

ssh-add -l should now list your key's fingerprint. (For what the agent actually is and how it holds keys, see what is the SSH agent.)

Culprit 4: you're on an HTTPS remote, not an SSH one

This is the culprit behind "my key works (ssh -T succeeded) but git push still asks for a password." Your repository is configured to use HTTPS, which ignores SSH keys entirely and wants a token. Check:

git remote -v

If you see https://github.com/you/repo.git, that's the problem — HTTPS never touches your SSH key. Switch the remote to SSH:

git remote set-url origin git@github.com:you/repo.git      # GitHub
git remote set-url origin git@gitlab.com:you/repo.git      # GitLab

Run git remote -v again to confirm it now starts with git@. This single fix resolves a huge share of "SSH key not working" reports where the key was fine all along.

Culprit 5: permissions on ~/.ssh

SSH refuses to use keys and config that others could tamper with. If verbose output mentions bad modes, or keys are being ignored for no clear reason:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519          # private key
chmod 644 ~/.ssh/id_ed25519.pub      # public key
chmod 600 ~/.ssh/config

On Windows this surfaces after copying keys off a synced drive or between machines; fix it via the file's Security properties, or keep keys out of cloud-synced folders.

Culprit 6: passphrase prompts every time

If every git operation demands your key passphrase, the agent isn't caching it. Load it once with ssh-add (culprit 3), and make it stick across sessions by adding to ~/.ssh/config:

Host github.com gitlab.com
    AddKeysToAgent yes

On macOS, ssh-add --apple-use-keychain ~/.ssh/id_ed25519 stores the passphrase in Keychain so it survives reboots.

Culprit 7: two accounts, one host

Work and personal GitHub accounts can't share one key — a given public key belongs to exactly one account. Give each its own key and a Host alias that selects it:

Host github-work
    HostName github.com
    User git
    IdentityFile ~/.ssh/work_ed25519
    IdentitiesOnly yes

Host github-personal
    HostName github.com
    User git
    IdentityFile ~/.ssh/personal_ed25519
    IdentitiesOnly yes

Then clone or set the remote with the alias as the host: git@github-work:org/repo.git. SSH matches github-work, picks the work key, and rewrites the connection to github.com under the hood.

Culprit 8: organization SSO not authorized (GitHub)

You authenticate fine to your own repos but get Permission denied on an org's repos behind SAML SSO. The key exists but isn't authorized for that organization. Go to Settings → SSH and GPG keys, find the key, click Configure SSO, and authorize it for the organization. GitLab has a parallel case where an expired key is silently rejected — check the key's expiry date in SSH Keys if a previously working key suddenly stops.

When it's still `Permission denied (publickey)`

If you've worked the list and still hit the endpoint, you've narrowed it to a genuine key-acceptance problem — the systematic loop for that exact error (reading ssh -vvv, the server's method list, offered vs. accepted keys) is in permission denied (publickey), a fast systematic fix, and the broader map of SSH errors is in SSH errors decoded. But for git hosts specifically, the order above catches nearly everything: register the public key, offer the right one, load it into the agent, and make sure you're actually on an SSH remote.

Where a client removes the setup entirely

Most of this friction is bookkeeping — which key belongs to which host, whether it's loaded, whether the remote is even SSH. Termalin keeps the key with the host it belongs to, unlocks your keys once through a built-in agent so passphrases aren't retyped (and a cancelled prompt never silently skips a key), and — because it speaks the standard ssh-agent protocol — git and your CLI can sign through that same agent. Fingerprints are visible per key, so registering the right public half with GitHub or GitLab is copy-and-paste rather than a hunt through five ~/.ssh folders. The account-and-alias juggling above becomes a per-host setting instead of a config-file puzzle.

Termalin is a free, cross-platform SSH client that manages your keys with a one-unlock agent git can sign through — download it, or read how it handles keys safely.