DEV Community: Svyatoslav Pavlov

Every way to give an AI agent SSH access, ranked by blast radius

Svyatoslav Pavlov — Thu, 13 Aug 2026 00:00:00 +0000

Sooner or later you'll want an AI agent to touch a real server — tail a log, restart a service, run the deploy. Every way of arranging that answers the same underlying question: when the agent gets confused or compromised — prompt injection, a poisoned tool result, a plan that skipped a step — what does it cost you? That's the blast radius, and it's the right axis to rank the options on, because the failure isn't hypothetical. A model that reads untrusted input (logs, filenames, web pages, other tools' output) can be steered by it. You don't get to prevent that; you get to decide what it's worth when it happens.

Here are the five arrangements people actually use, worst to best. The tradeoffs of each are real, including the good ones.

1. Paste the private key into the agent's environment

The direct route: id_ed25519 in an env var, a config blob, a mounted file, so the agent can run ssh itself.

Blast radius: everything, forever. An SSH key is a pure bearer credential — whoever holds the bytes is you, on every host that trusts the key, with a full shell, from anywhere on the internet. And it's the one arrangement you can't walk back: once the key has passed through the model's context, a transcript, or a tool call you didn't read, you can't prove it didn't leak. The only honest remediation is rotating the key on every host that trusts it.

The honest upside: it works in thirty seconds with zero dependencies, which is why it's everywhere. That's the entire upside.

2. Forward your agent into the box the AI runs on

ForwardAgent yes into the VM or devbox where the coding agent lives, so anything there can authenticate as you without holding the key.

Blast radius: your full identity, live, for the duration of the session. The key bytes stay home — that's genuinely better than option 1, and when the session closes the exposure ends. But while it's open, any process on that box that can reach the forwarded socket can sign as you, to every host your keys reach, and nothing on your side shows it happening. You've lent the box live use of your identity; whether the borrower is the agent following instructions or something the agent was injected into is invisible from where you sit. We've written up the mechanics and the mitigations — ssh-add -c at minimum, so every signature needs a local click.

The honest upside: revocation is closing the session, and no secret is ever at rest on the agent's side. As a supervised, short-lived arrangement it beats a pasted key by a wide margin. As a standing one, it's option 1 with a timer.

3. A raw SSH-MCP server holding a key, no policy

A standalone MCP server with an ssh_exec tool and a key (or password) in its own config. The model never sees the credential — it sees tools. This is the shape of most minimal SSH-MCP servers you'll find.

Blast radius: a full shell on every host the server's key reaches. Getting the key out of the model's context is a real improvement — a leaked transcript no longer contains a credential, and revocation means rotating one known key, not auditing everywhere the model's context went. But the capability is unbounded: any tool call can run anything, on any configured host, and a steered model doesn't need the key when ssh_exec("curl … | sh") is on the menu. These servers also tend to ship with no session visibility and no audit trail, so your record of what an agent did is whatever the agent says it did.

The honest upside: simple, self-hosted, credential out of the context window. The gap is that it treats key custody as the whole problem, when unbounded execution is most of it.

4. A scoped credential per task

The classical ops answer: a deploy key limited to one repo, a command=-restricted line in authorized_keys, a dedicated low-privilege user, or — the serious version — short-lived certificates minted per task with the principals and TTL baked in.

Blast radius: one task's worth of capability, expiring on its own. This is a genuinely strong position. A stolen deploy credential deploys; it doesn't read the production database two hops over. Short-lived certs mean stolen material goes stale in minutes, and command= restrictions bound even a live credential to one action.

The honest tradeoffs: the operational burden is real and it compounds. Somebody has to mint, distribute, and track every scoped credential; a certificate flow needs CA infrastructure most teams don't run; and scoped credentials sprawl — the forced-command entry for a task finished in March is still in authorized_keys in August, because revoking something requires remembering it exists. Under deadline pressure, "just this once" broadens the scope, and the scheme quietly degrades toward option 1. Observability is also not included: a scoped credential bounds what the agent can do, but records nothing about what it did.

5. A custodian with per-host policy, live watch, and audit

The agent never holds any credential. A custodian — a broker the human controls — holds the keys or mints the certificates, signs on the agent's behalf, and wraps execution in controls: the agent reaches only enrolled hosts, each host carries a command policy (full shell, an allowlist, or blocked), a human can watch the session live, and every command lands in an audit log attributed to the agent. The MCP explainer covers why "who holds the credential" is the load-bearing question; this is the arrangement where the answer is "not the agent, ever."

Blast radius: the policy, minus what output can carry. Compromise the agent's context entirely and what you hold is the ability to request allowed commands on listed hosts — requests that appear in a live view and an audit log as they happen. No credential to exfiltrate, revocation is a toggle, and the record distinguishes the agent's actions from yours.

The honest limits — because this option has them too:

Policy doesn't stop exfiltration through allowed output. If cat is on the allowlist, cat .env returns your secrets into the model's context, and from there they can go wherever the model's output goes. A custodian bounds actions, not the information content of results. Allowlists need to be written with reads in mind, not just writes — and secrets on disk are their own problem to fix.
A full-access host is still a full shell. The policy is only as tight as you set it; "full" on production recreates option 3 for that host.
The custodian is now the thing to protect. Compromise the machine it runs on and you're back to holding keys. Concentrating custody is the right trade — one hardened place beats copies everywhere — but it's a trade, not a free lunch.
Watching reduces dwell time, not probability. The live view and audit log mean a steered agent gets caught in minutes instead of discovered in a postmortem. Injection still happens; you've bounded what it's worth and how long it runs.

The ranking, compressed

What a compromise costs, top to bottom: (1) your identity, everywhere, unrevocably → (2) your identity, live, until you notice → (3) a full shell behind one revocable credential → (4) one task's capability, self-expiring, if the hygiene holds → (5) the policy you wrote, observed and revocable, minus whatever allowed output carries.

If you're assembling option 4 or 5 yourself from certificates, forced commands and tlog, that's a respectable project. The reason we built Termalin is that almost nobody finishes that project: it's an SSH client whose built-in MCP server is the custodian — keys stay in the one-unlock agent, per-host policy is a setting (full / allowlist / blocked), agent sessions mirror into a live watch grid, and every agent command is tagged in output-only recordings and the audit log. The same pattern works with a local model as with a hosted one, and the full custody story is written up on the security page.

Whatever you pick, pick it deliberately. The worst arrangement on this list is also the one you get by not choosing.

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

SSH port forwarding, explained: local, remote and dynamic tunnels

Svyatoslav Pavlov — Fri, 07 Aug 2026 00:00:00 +0000

SSH port forwarding is one of those features people copy off Stack Overflow, get working once, and never quite understand — so the next time they need it, it's back to guessing which of -L, -R and -D to use. The three flags aren't hard; they're just badly named. Here's the one mental model that makes them obvious, an example for each, and the flags and traps that decide whether the tunnel survives the afternoon.

The one question that picks the flag

Every SSH tunnel opens a listening port on one machine and quietly ships whatever hits it to somewhere reachable from the other machine. So the only question is: which side opens the port you connect to?

-L (local) — the port opens on your machine. You connect locally; traffic comes out on the server's side.
-R (remote) — the port opens on the server. Someone connects there; traffic comes out on your side.
-D (dynamic) — the port opens on your machine, but it's a SOCKS proxy: the destination is decided per-connection, not fixed up front.

Everything else is detail. Keep "which side opens the port" in your head and you'll never reach for the wrong flag again.

Local forwarding (`-L`) — pull a remote service to localhost

The most common one. A database, an internal dashboard, a metrics UI — something bound to 127.0.0.1 on the server, or on a machine only the server can reach. You want it on your laptop as if it were local.

ssh -L 5432:localhost:5432 deploy@db.example.com

Read it left to right: open 5432 on my machine, and forward anything that arrives to localhost:5432 as seen from the server. Now psql -h 127.0.0.1 on your laptop talks to the server's Postgres — through the encrypted SSH connection, without exposing the database to the network at all.

The middle host is resolved on the server side, which is what makes this powerful:

# reach a database that only the bastion can see
ssh -L 5432:10.0.0.9:5432 deploy@bastion.example.com

Here 10.0.0.9 is a private address your laptop can't route to — but the bastion can. The tunnel bridges the gap.

Remote forwarding (`-R`) — expose your machine to the server's side

The mirror image, and the one people find backwards. The port opens on the server; connections to it come back out on your end. Two classic uses:

# let the server (or its network) reach a dev server running on your laptop
ssh -R 8080:localhost:3000 deploy@app.example.com

Now anything hitting localhost:8080 on the server is piped to localhost:3000 on your laptop — handy for showing a teammate on the box your work-in-progress, or letting a remote service call back into something only you're running.

This is also the trick for reaching a machine stuck behind NAT with no inbound access: have it open a reverse tunnel out to a server you control, and you connect through the server. The machine that can't accept connections makes the outbound one instead.

One catch: by default the server binds the forwarded port to localhost, so only the server itself can use it. To let other machines on the server's network reach it, the server's sshd_config needs GatewayPorts yes (or clientspecified) — a server-side setting, not something you can force from the client.

Dynamic forwarding (`-D`) — a SOCKS proxy in one flag

-L forwards to one fixed destination. -D opens a SOCKS proxy instead, so the destination is chosen per request:

ssh -D 1080 deploy@jump.example.com

Point your browser (or curl --socks5 127.0.0.1:1080) at 127.0.0.1:1080 and every request is routed from the server. It's the quick way to browse an internal network, test what a service looks like from a datacenter's IP, or reach a handful of internal hosts without a -L for each one.

The flags that make it usable

A bare tunnel command also opens a shell you don't want and dies the moment you close it. In practice:

ssh -N -L 5432:localhost:5432 deploy@db.example.com

-N — don't run a remote command. You only want the tunnel, not a shell.
-f — background the process after connecting (pair with -N).
-o ExitOnForwardFailure=yes — if the port can't be bound (already in use, permission denied), fail loudly instead of connecting anyway and silently forwarding nothing.
Keepalives — a long-lived tunnel dies to idle timeouts without ServerAliveInterval 30. Add it or the tunnel drops the moment you stop using it.

Make it permanent in ssh_config

Anything you'd pass with -L/-R/-D has a config directive, so a saved host carries its tunnels:

Host db-tunnel
    HostName db.example.com
    User deploy
    LocalForward 5432 localhost:5432
    ServerAliveInterval 30
    RequestTTY no

Now ssh -N db-tunnel brings the database to 127.0.0.1:5432 with no flags to remember. RemoteForward and DynamicForward work the same way. (More on the config file itself in the ~/.ssh/config guide.)

Three traps

Bind address matters. -L 5432:... listens on 127.0.0.1 only. To let other devices on your LAN use the tunnel, prefix a bind address: -L 0.0.0.0:5432:... — and understand you've just exposed it to your local network.
"Address already in use" means the local port is taken (often a previous tunnel that didn't exit). Pick another local port or kill the old one; ExitOnForwardFailure turns the silent failure into an error you'll actually notice.
The middle host is resolved on the far side. localhost in -L a:localhost:b means the server's localhost, not yours. Getting this backwards is the single most common port-forwarding mistake.

When juggling tunnels by hand gets old

Forwarding is a great primitive, and every developer should know the three flags cold. The friction shows up later: you keep a scratchpad of ssh -N -L ... commands, you re-run them after every laptop sleep, you forget which local port maps to which service, and you can't tell at a glance whether a tunnel is even still up.

That's where a client that treats tunnels as first-class state helps. Termalin keeps local, remote and dynamic forwards attached to the host as saved config — start them with a click, see which are live, and let them re-establish with the connection instead of retyping the command. The same host list (with its keys, jump hosts and keepalives) syncs across your machines end-to-end encrypted, and each server is verified on first connect. The command line teaches you how tunnels work; a client keeps you from rebuilding them by hand every morning.

Either way, the model is the whole trick: decide which side opens the port, and the rest of the flag writes itself.

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

How to give a local LLM safe SSH access to your servers

Svyatoslav Pavlov — Fri, 07 Aug 2026 00:00:00 +0000

Local models are having a moment. Ollama on a workstation, an open-weight model behind your own endpoint, a self-hosted coding agent — you run them for good reasons: privacy, cost, no rate limits, works on a plane. And once a model is already handling your prompts, the obvious next step is to point it at your infrastructure: let it tail a log, restart a service, run the migration.

Here's the trap that rides along with it: "it's local, so it's safe" is not true. Running the model on your own hardware keeps your prompts off someone else's servers. It does nothing about what happens when that model gets a shell.

Why "local" doesn't make server access safe

Two things stay exactly as dangerous whether the model runs in a datacenter or on the box under your desk.

The key is still a bearer credential. Drop id_ed25519 into the agent's environment so it can run ssh itself, and whoever — or whatever — holds those bytes is you, on every host that trusts the key. Running the model locally doesn't change that; it just moves the copy to a machine you happen to own. And you still can't take it back: once the key has passed through the model's context — an env var, a mounted file, a tool call, a transcript — you can no longer prove it didn't end up somewhere it shouldn't. The only honest answer to "did the model see my key?" is to rotate it on every host.

A local model still gets confused. Prompt injection doesn't need a cloud model. A poisoned log line, a malicious filename, a booby-trapped tool result, an over-eager plan — a local model acts on all of them just as readily as a hosted one. If anything the risk is worse, because people trust local setups more, wire them up with fewer guardrails, and hand them broader access, precisely because "it's on my machine." That's the wrong instinct: the model's judgement isn't better because the weights are local.

So the goal is the same as for any agent — let the model do the work without ever holding the credential, and make every action scoped, visible and reversible.

Three ways to do it badly

Paste the raw key. The direct route, and the worst: no scope, no expiry, and the irreversibility above. The key that deploys to staging can usually also reach the production database two hops over.

Mint a long-lived token. A deploy token or "automation" credential that expires never. It feels tidier than a key, but it's the same bearer problem with extra steps. If revoking something means remembering it exists, it'll outlive the experiment that created it.

Give it its own root login and walk away. The right instinct — a separate identity — done the wrong way. Drop a public key into authorized_keys for a bot user and you've built access with no audit trail: nothing distinguishes the model's commands from anyone else's, and when something breaks at 2 a.m. you're reconstructing its session from bash history and vibes.

The common thread: the model holds a standing credential, and observability is an afterthought.

The pattern that works: a custodian, not a copy

Flip it. The model should never hold the credential at all.

The model asks; a custodian signs. A broker holds the keys (or mints short-lived certificates) and authenticates on the model's behalf. Compromise the model's context and you get the ability to request actions through the broker — not the ability to impersonate you from anywhere.
Scope is explicit. The model reaches only the hosts you've listed. A new host is a new decision, not a default.
Commands are policed. Per host, decide whether the model gets a full shell, an allowlist of commands, or nothing — so "restart nginx" is allowed on the web tier and "anything at all" never is.
A human can watch — live. Not just in the post-mortem, and with the record distinguishing "the model did this" from "I did this."
Revocation is a toggle, not a rotation. Because nothing was ever shared, turning access off costs nothing.

None of this is exotic — it's roughly how certificate-based SSH already works on serious infra teams. The catch has always been that wiring it up yourself is a project, so people skip to one of the bad options above.

Wiring it to a local model

MCP — the Model Context Protocol — is the clean way to do this, and it's client-agnostic: any MCP-capable client can drive it, so it doesn't matter whether your model is Claude, an open-weight model behind Ollama, or something you host yourself.

Run your local model through an MCP-capable client (a coding agent or chat client that speaks MCP).
Point it at an MCP server that fronts SSH — one that authenticates for the model rather than handing it a key.
Turn on only the hosts you want, and set each host's command policy (full / allowlist / blocked).
Keep the session in view and let it write to an audit log, so every command the model runs is attributable and replayable.

The model gets tools — open a session, run a command, read or write a file — and the custodian does the authenticating. Your key never enters the model's environment, on your machine or anywhere else.

How Termalin does it

Termalin is an SSH client with a built-in MCP server, so this pattern is the default rather than a project.

On your machine, register the bundled local server with your agent (claude mcp add termalin -- <path>/termalin-mcp, or the equivalent for any MCP client). The model reaches only the hosts you enable — agent access is off by default — and authentication goes through Termalin's key custodian: you unlock your keys once, Termalin signs on the model's behalf, and no key file is ever there for the model to read.
Per host, you set the policy — full access, an allowlist of commands, or blocked — so a local model that gets confused can't run something you never authorized on that box.
You watch it happen. Agent sessions run as live terminal tabs; the watch grid mirrors them, and the tiles a model is driving glow. Every command is marked in the session recording — output only, never your keystrokes — and written to an audit log with the device and IP it came from.
No app running? Point the model at Termalin's hosted MCP endpoint with an API key that's scoped to specific servers, carries an expiry, is command-policed, and authenticates each run with a short-lived certificate — so even a leaked key can't reach an unlisted host or run outside its allowed commands.

Either way, the property you wanted holds: your local model can operate your servers, and it has never seen a key.

Start with one boring host

Don't begin with production. Enroll a low-stakes box — a staging server, a toy VPS — set it to an allowlist, and give the model a real chore: tail the log until the error shows, fix the config, restart the service. Keep the grid open while it works. What you learn in the first hour — how it behaves, where it hesitates, what it does with ambiguity — tells you whether the second host gets enrolled, and with how much rope.

That's the quiet payoff of the custodian model: you expand one host at a time, because no step you take is one you can't take back — no matter where the model is running.

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

SSH key types in 2026: Ed25519 vs RSA vs ECDSA — which to use

Svyatoslav Pavlov — Thu, 06 Aug 2026 00:00:00 +0000

When you run ssh-keygen, it asks nothing about the algorithm and quietly picks one for you — and that default has changed over the years. If you're generating a key today and want the short answer: use Ed25519. The longer answer, and the cases where it's not that simple, are below.

The one-line recommendation

ssh-keygen -t ed25519 -C "you@device-2026"

That's it. Ed25519 keys are small, fast, and as strong as a 3072-bit RSA key while being a fraction of the size. Unless you have a specific reason not to (one real case below), this is the key to make.

The four you'll meet

Ed25519 — the modern default. An elliptic-curve signature scheme (Curve25519) designed by Daniel J. Bernstein and collaborators. Fixed size (~68-character public key), fast to generate and verify, and immune to the RNG and parameter footguns that plagued older ECDSA. Supported by OpenSSH since 6.5 (2014), so every current server and service — GitHub, GitLab, your VPS — accepts it. This is the right default in 2026.

RSA — the compatibility fallback. The old workhorse. Still perfectly secure at 3072 or 4096 bits (ssh-keygen -t rsa -b 4096). Its one advantage is reach: some ancient appliance, a legacy jump host, or an enterprise system stuck on an old OpenSSH may not know Ed25519. If you hit no matching host key type, an RSA key is your escape hatch. The catch: bigger keys, slower, and anything under 2048 bits is unsafe — regenerate old 1024-bit keys now.

ECDSA — skip it. Elliptic-curve like Ed25519, but it depends on a per-signature random value that, if the random number generator is weak, leaks your private key (this is how a certain game console's signing key was recovered in 2010). Ed25519 was specifically designed to remove that failure mode. ECDSA isn't broken if implemented perfectly, but there's no reason to choose it over Ed25519 today.

DSA — never. Capped at 1024 bits, disabled by default in modern OpenSSH, being removed entirely. If you find a id_dsa in your ~/.ssh, retire it.

Quick decision

Your situation	Use
Making a key today, normal servers	Ed25519
Must reach an old/legacy system that rejects Ed25519	RSA 4096
You have an existing ECDSA or 1024-bit key	Regenerate as Ed25519
Anything DSA	Delete it

Things worth doing while you're here

Always set a passphrase. A private key with no passphrase is a plaintext password to your servers — anyone who copies the file is you. Add one at generation; unlock it once per session with an agent (AddKeysToAgent yes in your ssh_config).

Name your keys by device, not by "id". ~/.ssh/id_ed25519 on five machines is five keys you can't tell apart. laptop_ed25519, work-desktop_ed25519 makes revocation a one-line edit to authorized_keys instead of a guessing game.

Rotate on a schedule, and when a device is lost. A key is a credential; treat it like one. When a laptop dies or is stolen, the fix is removing its public key from every server's authorized_keys — which is far easier when keys are named per device and you have a list of your servers.

Where a client helps

Generating one key is easy. The friction shows up at scale: which key is on which server, which passphrase goes with which file, and un-trusting a lost device across a fleet. Termalin generates Ed25519 and RSA keys, shows each key's fingerprint, and unlocks them once through a built-in agent so passphrases aren't retyped all day — and because it keeps the list of your hosts and keys together (synced across machines, end-to-end encrypted), rotating a compromised key is a visible, finite task rather than an archaeology dig through five ~/.ssh folders.

The algorithm choice, though, stays simple: Ed25519 unless something old forces your hand.

Termalin is a free, cross-platform SSH client that generates and manages your keys with a one-unlock agent — download it, or read the security model.

The ~/.ssh/config file: stop retyping the same SSH flags

Svyatoslav Pavlov — Thu, 06 Aug 2026 00:00:00 +0000

If you've ever typed ssh -i ~/.ssh/work_ed25519 -p 2222 -o ServerAliveInterval=30 deploy@203.0.113.10 more than twice, you've already earned back the ten minutes it takes to learn ssh_config. It's the single highest-leverage file in your SSH setup: it turns that whole line into ssh web1, and it's read automatically by ssh, scp, sftp, rsync, git, and anything else that shells out to SSH.

Here's the practical tour — the directives that actually earn their place, and the traps worth knowing.

Where it lives and how it's read

Your personal config is ~/.ssh/config (create it if it doesn't exist; chmod 600). There's also a system-wide /etc/ssh/ssh_config. The rules that trip people up:

First match wins, not most specific. SSH reads top to bottom and the first value it sees for each option is the one it uses. Put your specific hosts at the top and broad Host * defaults at the bottom.
Every setting lives under a Host block (a pattern), indented by convention (indentation isn't required, but read the file your future self will thank you for).

The building block: a host alias

Host web1
    HostName 203.0.113.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/work_ed25519

Now ssh web1 expands to the full command. So does scp file.tar web1:/srv/, sftp web1, and rsync -a ./dist/ web1:/var/www/. The alias is the whole point: name the server once, use the name everywhere.

Directives that earn their place

ProxyJump — reach servers through a bastion. The modern replacement for the old ProxyCommand ... netcat incantation:

Host db1
    HostName 10.0.0.5          # private address, only reachable from the bastion
    User deploy
    ProxyJump bastion

Host bastion
    HostName bastion.example.com
    User jump

ssh db1 now transparently hops through bastion to reach a host with no public address. Chain them with commas (ProxyJump a,b,c) for deeper networks.

Keepalives — stop idle sessions from dying. The fix for client_loop: send disconnect: Broken pipe when you look away:

Host *
    ServerAliveInterval 30
    ServerAliveCountMax 4

A packet every 30 seconds keeps NAT routers and firewalls from forgetting your connection; four missed replies (two minutes) before it gives up.

IdentitiesOnly — offer only the right key. If you carry several keys, SSH offers them all and a strict server replies Too many authentication failures. Pin one key per host and stop the guessing:

Host github.com
    IdentityFile ~/.ssh/personal_ed25519
    IdentitiesOnly yes

AddKeysToAgent — unlock a passphrase-protected key once:

Host *
    AddKeysToAgent yes

Patterns and wildcards — configure a fleet in one block:

Host *.staging.example.com
    User deploy
    IdentityFile ~/.ssh/staging_ed25519

Host 10.0.*
    ProxyJump bastion

A realistic config, top to bottom

# Specific hosts first (first match wins)
Host web1
    HostName 203.0.113.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/work_ed25519

Host db1
    HostName 10.0.0.5
    User deploy
    ProxyJump bastion

Host bastion
    HostName bastion.example.com
    User jump
    IdentityFile ~/.ssh/work_ed25519

Host github.com
    IdentityFile ~/.ssh/personal_ed25519
    IdentitiesOnly yes

# Broad defaults last
Host *
    ServerAliveInterval 30
    ServerAliveCountMax 4
    AddKeysToAgent yes

Split it up as it grows: Include ~/.ssh/config.d/* at the top of the file lets you keep one file per project or client.

Two traps

"First match wins" bites you when a Host * block near the top sets a value you meant to override below — it won't override, because the earlier value already won. Defaults go at the bottom.
Comments are # at line start. Trailing comments after a value can be parsed as part of the value on some options — keep comments on their own lines.

When the config file isn't enough

ssh_config is excellent and everyone should have one. Its edges show when the setup gets bigger than a text file: you're syncing it across machines by hand, sharing sanitized versions with teammates, remembering which passphrase goes with which key, or trying to see at a glance which of forty hosts is even online.

That's the seam Termalin fills. It keeps the same per-host settings — hostname, user, port, key, jump host, keepalives — but attached to the host as structured data you organize into folders and tags, unlocks your keys once through a built-in agent, verifies each server on first connect, and shows live status for every host in the list. It imports your existing PuTTY sessions, and its host list syncs across your machines end-to-end encrypted. The file scales to a point; a client that keeps the state for you scales past it.

Either way, the principle holds: name a server once, and never retype its flags again.

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

How to let an AI agent deploy to your server — without handing it your SSH keys

Svyatoslav Pavlov — Wed, 05 Aug 2026 07:24:51 +0000

The coding part is mostly solved. An agent can branch, patch, write the tests, open the PR. Then the change has to land on an actual server — a service restarted, a migration run, an nginx config edited — and the autonomy stops cold. Deploying needs SSH, SSH needs credentials, and nobody in their right mind wants to paste a private key into an agent's environment.

That hesitation is correct, and it's worth being precise about why. An SSH private key is a bearer credential: whoever holds the bytes is you. Sharing it with an agent is not like sharing it with a colleague, because you can't take it back. Once a key has passed through an agent's context — an env var, a mounted file, a config blob — you can no longer prove it didn't end up in a log, a transcript, or a tool call you never read. The only honest answer to "did the model see my key?" is to rotate the key, on every host that trusts it. That's the irreversibility problem, and it's why "just give the agent a key" feels wrong even to people who can't articulate the threat model.

Three ways to do it badly

Paste the raw key. The direct route: drop id_ed25519 into the agent's config or environment and let it run ssh itself. Beyond the irreversibility above, an SSH key has no scope and no expiry — the key that deploys to staging can usually also read the production database credentials two hops away. And revocation means rotation, which means touching authorized_keys on every box, which means you'll put it off.

Mint a long-lived token. A deploy token, a PAT, an "automation" credential that expires never. It feels more hygienic than a key, but it's the same bearer problem with extra steps. The rule of thumb: if revoking a credential requires remembering it exists, it will outlive the experiment it was created for.

Give the agent its own root account. This one at least shows the right instinct — a separate identity you can revoke separately. But done the usual way (drop a public key into authorized_keys for a deploy-bot user, walk away), it ships with no audit trail. Nothing distinguishes the agent's commands from anyone else's, nothing records what it actually did, and when something breaks at 2 a.m. you're reconstructing an agent's session from bash history and vibes.

The common thread: in all three, the agent holds a standing credential, and observability is an afterthought.

What good looks like: a custodian, not a copy

Flip the model. The agent should never hold the credential at all.

The agent asks; a custodian signs. A broker process holds the keys — or mints short-lived certificates — and performs the authentication on the agent's behalf. The agent's environment contains nothing worth stealing: compromise the context and you get the ability to request actions through the broker, not the ability to impersonate you from anywhere on the internet.
Scope is explicit. The custodian only reaches the hosts you've listed. A new host is a new decision, not a default.
A human can watch. Live, while it happens — not just in the post-mortem. And the record must distinguish "the agent did this" from "I did this".
Revocation is a toggle, not a rotation. Because nothing was ever shared, turning access off costs nothing.

None of this is exotic — it's roughly how certificate-based SSH already works at companies with real infrastructure teams. The catch has always been that wiring it up yourself is a project, so most people skip straight to one of the bad options above.

How Termalin implements it

Termalin is an SSH client with a built-in MCP server. Your agent — Claude, or anything that speaks the Model Context Protocol — gets tools like hosts_list, ssh_exec, SFTP reads and writes, and persistent sessions. Termalin does the authenticating.

On your machine. Register the bundled local server with your agent:

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

The agent reaches only the hosts you've enabled in Settings → MCP — agent access is off by default, and the host inventory is written with agent-only auth, so no passwords land on disk. Authentication goes through Termalin's key custodian: you unlock your keys once, and Termalin signs on the agent's behalf. No ssh-add, no key file for the agent to read, no key touching disk at all.

And you can actually watch. Agent sessions run as live terminal tabs, the watch grid mirrors every open session side by side, and the tiles an agent is driving glow. Letting the agent type into a session you already have open is a separate consent toggle, not a default. Every agent command is marked in the session recording — which captures output only, never your keystrokes — and written to the audit log with the device and IP it came from.

No app running. If your agent lives where your desktop isn't — CI, a cloud sandbox — create an API key in the web cabinet and point it at the hosted MCP endpoint:

{
  "mcpServers": {
    "termalin": {
      "url": "https://termal.in/api/v1/mcp",
      "headers": { "Authorization": "Bearer tk_live_…" }
    }
  }
}

The hosted endpoint reaches only servers enrolled with the tunnel agent, and it authenticates each run with a short-lived certificate — again, no standing key is ever handed out. The API keys themselves are scoped to specific servers, carry an expiry (30, 90 or 365 days), and can be revoked any time; hosted runs are rate-limited and time-boxed per key.

Either way, the property you wanted holds: the agent can deploy, and it has never seen a key.

Start with one boring host

Don't begin with production. Enroll one low-stakes box — the staging server, a toy VPS. Give the agent a real chore: deploy the branch, tail the log until the error shows up, fix the config, restart the service. Keep the watch grid open while it works. What you learn in the first hour — how it behaves, where it hesitates, what it does with ambiguity — tells you whether the second host gets enrolled.

That's the quiet payoff of the custodian model: you get to expand one host at a time, because no step you take is one you can't take back.

Termalin's Free tier is the full desktop app, and every new account starts with a 14-day Pro trial — download it, or start with the MCP docs.

How to record SSH sessions — without keylogging yourself

Svyatoslav Pavlov — Wed, 05 Aug 2026 00:00:00 +0000

Sooner or later you want a record of what happened in a terminal. A deploy went sideways at 2 a.m. and the postmortem needs facts, not memories. A new teammate wants to see how the migration was actually run. An auditor wants proof. Or — the new reason — an AI agent worked on your server, and "what exactly did it do?" deserves a better answer than a summary written by the same agent.

Recording SSH sessions is a solved problem several times over. What's not solved by default is doing it without quietly building a keylogger aimed at yourself. Let's go through the options, then the trap. (If you'd rather see how a client does this out of the box, that's SSH session recording in Termalin — this guide covers the DIY routes.)

The quick ways to record a session

script — always there. Ships with every Unix since before you were born:

script -T timing.log session.log
# ... work ...
exit
scriptreplay -t timing.log session.log

Records everything printed to the terminal, replays with original timing. Crude but dependable; the files are plain text plus a timing track.

asciinema — the pretty one. asciinema rec demo.cast records the terminal as a compact JSON event stream you can replay in a browser, embed in docs, or share. Perfect for demos and how-tos; less ideal as an audit trail (it's trivially editable).

tlog — the server-side one. Red Hat's tlog wraps the login shell and journals every session to systemd-journald or Elasticsearch. Being server-side, it catches every way in — handy for the "all access to this box is recorded" requirement. Pairing it with a session-recording-aware SSSD setup is the classic RHEL compliance stack.

auditd tty logging — the heavyweight. pam_tty_audit records TTY input at the kernel level. Note the word input. We'll come back to it.

The trap: recording input records your secrets

Here's the thing nobody mentions until an incident: a terminal session has two streams. Output — what the server printed — is what you almost always want: commands appear there anyway (your shell echoes them), along with everything they printed. Input — the raw keystrokes — adds exactly one category of data output doesn't have: the things that were deliberately not echoed.

What isn't echoed? Passwords at sudo prompts. Passphrases. The token you pasted into a login prompt. The database password you typed into psql. Record keystrokes and your audit trail is now a credentials file with excellent timestamps — stored for years, synced to log servers, readable by whoever reads logs.

pam_tty_audit has a disable=* / enable=root dance and a log_passwd option specifically because of this; the default without care is unsafe. Homegrown wrappers that tee stdin are unsafe, period. If your recording setup can answer the question "what was the sudo password?", it's not an audit trail — it's an incident waiting for a retention policy.

The rule: record output, never input. You lose nothing forensically — every command that ran is visible in the output stream — and you stop hoarding secrets.

Storage is part of the design

Recordings are as sensitive as shell history times ten: they contain config files you catted, database rows you selected, environment dumps. Two boring rules cover most of it: store them encrypted, and decide who can replay before the first recording exists, not after. If recordings sync anywhere (they should — a laptop-only audit trail dies with the laptop), the sync should be end-to-end encrypted so the storage provider is not silently a member of your security team.

The agent angle

If AI agents touch your servers, recording stops being a compliance checkbox and becomes the core of the trust model. The properties that matter:

The recording is made by the client, not narrated by the agent. What ran is what you replay — not what the model chose to summarize.
Agent actions are labeled. At 2 a.m. you need "the agent did this, I did that" to be a filter, not a reconstruction.
Output-only still applies. The agent's session shouldn't capture your keystrokes when you step in to type into it.

How Termalin does it

Termalin records sessions output-only by design — keystrokes are never captured, so there is nothing password-shaped to leak. Recording is a per-host toggle; replay is built in (with timing, like scriptreplay but with a UI), and every command an agent ran through the MCP server is marked as the agent's in the recording and the audit log, with the device and IP it came from. Recordings sync end-to-end encrypted on Pro — the server stores ciphertext it cannot replay.

The takeaway works with any stack, ours included: record everything the server said, nothing you typed blind, encrypt the archive — and when an agent drives, make the recording the ground truth.

Termalin's Free tier records and replays locally with no host limits — download it, or see session recording in detail.

SSH clients for AI agents in 2026: the landscape

Svyatoslav Pavlov — Wed, 05 Aug 2026 00:00:00 +0000

A year ago "SSH client for AI agents" wasn't a product category. Then coding agents got good enough to deploy what they write, the Model Context Protocol gave them a standard way to hold tools, and suddenly several teams — ours included — are building terminals where the operator isn't always human.

Full disclosure up front: we build Termalin, one of the products below. This post exists because when we asked AI assistants what's out there, they assembled answers from app-store listings and directory scraps — nobody had mapped the field. So here's the map, with the competition described as fairly as we can manage. Facts checked August 5, 2026; this space moves fast.

The three desktop clients

Termalin (that's us) — a cross-platform SSH client for Windows, macOS and Linux: tabbed terminal, SFTP with a built-in editor, dual-pane file manager (host↔host, S3), snippets, live server stats. The agent layer is a built-in MCP server with a key custodian: the agent requests, Termalin signs — no key ever enters the agent's environment. Every agent session is mirrored live in a watch grid, and agent commands are marked in output-only recordings and the audit log. Two things nobody else on this list has: a hosted MCP endpoint (your agent works from CI or a cloud sandbox with no desktop running anywhere — auth by scoped, expiring API key, servers reached through a keyless tunnel agent), and an account-based end-to-end encrypted sync where the server only ever stores ciphertext. Phones and tablets are covered by a web cabinet (a PWA with a real terminal) rather than a native app. Free tier is the full desktop app with no host limits; Pro is a subscription ($8/mo billed yearly).

Gumpbox — an "AI-first SSH client" for the Apple ecosystem only (macOS, iOS and iPadOS 26+). It's the most opinionated about safe execution: agent actions can run in gVisor-sandboxed Alpine containers on the target, consent sheets show full server identity before an operation, and there's a tidy set of admin tools (processes, cron, tunnels, audit log, workflows). Sync is via iCloud. Pricing is friendly: free for one server, $19.99 one-time for unlimited. It's a young solo-developer product (about three months of public history at the time of writing), and if your fleet or your team includes Windows or Linux desktops, it's simply not an option.

VibeShell — a Tauri-based desktop app for Windows, macOS and Linux with a polished terminal workspace: split panes, Finder-style SFTP, themes, snippets, session recording. Its agent story is an Agent Gateway exposing ~28 MCP tools plus a "skill installer" that wires up Claude Code, Codex, Cursor and a dozen other tools; it can also launch coding-agent CLIs in native tabs with live Git diffs. Sync is do-it-yourself end-to-end encryption through a GitHub Gist or WebDAV file. The repository is public, which we respect — but note there's no license file (source-visible isn't open source), and the README itself currently states that saved credentials are not encrypted at rest (Keychain storage is planned). A capable tool for tinkerers who read the code they run; a harder sell where credential handling is audited.

The headless option: standalone MCP servers

If you don't want a GUI at all, several standalone MCP servers speak SSH: mcp-ssh (AiondaDotCom), SSH-MCP, Aegis (zero-trust flavored, with command firewalls), and others on the MCP directories. You configure hosts and keys yourself, point Claude Desktop or your agent at the server, and get command execution and file transfer with no visual layer.

They're lightweight and scriptable, and the good ones take policy seriously. The tradeoff is structural: the credentials live wherever the MCP server runs, usually as plain key files in the agent's reach, and there's no shared screen where a human watches the session as it happens. You audit after the fact, from logs — if logging was configured.

How to choose

	Termalin	Gumpbox	VibeShell	Standalone MCP
Platforms	Windows · macOS · Linux (+ web/PWA)	Apple only	Windows · macOS · Linux	anywhere headless
Agent works without the desktop app	Yes — hosted endpoint	No	No	Yes (it is headless)
Keys reachable by the agent	Never (custodian signs)	Keychain-held	Plaintext at rest (per README, for now)	Usually plain key files
Watch agent live	Watch grid, marked recordings	Consent sheets per action	Shared visible sessions	No
Sandboxed execution on target	No	gVisor containers	No	Varies
Sync	E2E-encrypted, own account	iCloud	DIY Gist/WebDAV	—
Mobile	Web cabinet (PWA)	Native iOS/iPadOS	In development	—
Price	Free (no host limits) + $8/mo Pro	Free (1 server) + $19.99 once	Free	Free

Honest recommendations, including against ourselves:

All-Apple, one server or a personal fleet, love one-time pricing → Gumpbox is genuinely good, and its sandboxing is the strongest containment story here.
Want to read the source and assemble your own sync → VibeShell, once you've made peace with the license situation and checked how your credentials are stored.
Pure headless automation, no humans in the loop by design → a standalone MCP server with strict authorized_keys restrictions is the smallest moving part.
Mixed-OS machines, agents that must run from CI or the cloud, keys that must never be agent-readable, or a team that needs an audit trail → that's the corner we built Termalin for.

Where this category is going

Three predictions, since we're here: consent UX will converge (every product above is inventing per-action approval independently); "can the agent act when my laptop is closed" will separate toys from infrastructure; and key custody will become the line auditors actually check — "the agent could read the key but we trust it" is not going to survive contact with a SOC 2 review.

Termalin is free with no host limits on Windows, macOS and Linux — download it, read the MCP docs, or see how the hosted endpoint works when your agent lives in the cloud.

How to connect Claude Code to a server over SSH — a hands-on walkthrough

Svyatoslav Pavlov — Tue, 04 Aug 2026 00:00:00 +0000

Claude Code is comfortable in a repo. The moment the task leaves the repo — check why the service won't start, free up disk space, fix the nginx config on the actual box — it needs SSH, and most people solve that by pasting a private key somewhere into the agent's environment. We wrote about why that's the one move you can't undo; this post is the practical version. Twenty minutes, one VPS, no key ever leaves your side.

What you need

Termalin — the desktop app, free tier is fine. It's an SSH client with a built-in MCP server; that server is what Claude Code will talk to.
Claude Code on the same machine.
One host saved in Termalin — pick something low-stakes for the first run. Staging, a toy VPS, the box that only runs your RSS reader.

Step 1 — turn agent access on

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

Two things happen under the hood. Termalin writes a host inventory for the MCP server with agent-only auth entries — no passwords or keys land in that file. And authentication stays with the app's key custodian: you unlock your keys once, Termalin signs on the agent's behalf. There is no key file for the agent to read, so there's nothing for it to leak.

Step 2 — register the server with Claude Code

One command:

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

That's the whole integration. Restart Claude Code and it picks up the tools: hosts_list, ssh_exec, persistent sessions (session_open, session_exec), SFTP reads and writes, and — if you allow it — tools that drive the live Termalin window itself.

Step 3 — give it a real chore

Don't start with a demo command; start with a task you'd actually do. For example:

Disk usage on staging-1 keeps creeping up. Find what's eating the space, clean up anything that's obviously safe to remove, and tell me what you did.

Watch what happens in Claude Code: it calls hosts_list, sees staging-1, opens a session, and starts working — df -h, then du down the suspicious paths, then a look at whatever it finds (in our runs it's almost always logs nobody rotated or a Docker image graveyard). It cleans up, verifies with another df -h, and reports back.

The part that makes this comfortable is that none of it is invisible. Every session the agent opens appears in Termalin as a live terminal tab, and the watch grid shows all open sessions side by side with the agent-driven tiles glowing.

You're not reading a summary after the fact — you're watching the commands land as they run, and you can step in at any moment.

Where the boundaries are

A few defaults worth knowing before you point it at anything you care about:

Your keys never touch disk for the agent — the custodian signs; the agent requests. Revoking access is a toggle in Settings, not a key rotation across your fleet.
The agent's reach is the allowlist you set in Step 1, nothing more.
Typing into your session is separate. By default the agent opens its own sessions. Letting it act inside a session you already have open (on Pro) is its own consent toggle — it never rides along silently.
Recordings mark agent activity. Session recordings capture output only — never your keystrokes — and every agent command is tagged as the agent's, with the device and IP it came from in the audit log. At 2 a.m. you can tell "it did this" from "I did this".

No desktop around? Use the hosted endpoint

If the agent runs where your desktop isn't — CI, a cloud sandbox — you don't ship the app with it. Create an API key in the web cabinet and point the agent at the hosted MCP endpoint:

{
  "mcpServers": {
    "termalin": {
      "url": "https://termal.in/api/v1/mcp",
      "headers": { "Authorization": "Bearer tk_live_…" }
    }
  }
}

The hosted endpoint only reaches servers you've enrolled with the tunnel agent, and each run authenticates with a short-lived certificate — same custodian idea, no standing credential anywhere. Keys are scoped to specific servers, expire on a schedule you pick (30, 90 or 365 days), and die instantly when revoked. File tools are deliberately modest there: text files up to 512 KB — config-editing territory, not a data channel.

The habit that makes it stick

Treat the first week like onboarding a new teammate who types very fast. Keep the watch grid open. Give it chores with a clear done-state — "make the health check pass", "get the cert renewed" — and read how it gets there. You'll learn quickly where it's careful and where it needs a tighter leash, and you can widen the allowlist one boring host at a time.

The asymmetry is the point: the agent gets real reach, and you keep the one thing that can't be taken back.

Termalin's Free tier is the full desktop app, and every new account starts with a 14-day Pro trial — download it, or read the MCP docs first.

SSH errors, decoded: the ten you'll actually hit and how to fix them

Svyatoslav Pavlov — Tue, 04 Aug 2026 00:00:00 +0000

SSH error messages are terse on purpose — the protocol won't tell a stranger why it turned them away. That's good security and bad ergonomics: the message you see is often two steps removed from the actual problem. This is a field guide to the ten errors you'll actually meet, what each one really means, and the fastest route to a fix.

One tool before we start: ssh -v user@host (add up to -vvv). Nearly every mystery below stops being a mystery once you see which step of the handshake it dies on.

1. `Connection refused`

The machine is reachable, but nothing is listening on the port you knocked on. This one is almost never about you:

sshd isn't running — systemctl status sshd from a console (VPS providers have a web console for exactly this moment);
it listens on a non-standard port — try ssh -p 2222, or check /etc/ssh/sshd_config for Port;
a firewall is actively rejecting (rather than dropping) the port.

If you just rebuilt the server, it's the firewall. If it worked yesterday, sshd crashed or the port changed.

2. `Connection timed out`

Different from refused: your packets are vanishing. The host is down, the IP is wrong, or — most often on cloud boxes — a security group / network ACL silently drops port 22. Check the provider's firewall rules first, then whether you're on a network that blocks outbound 22 (hotel and office guest Wi-Fi love this; try port 443-based access or a different network to confirm).

3. `Permission denied (publickey)`

The all-time champion. The server only accepts key auth, and it didn't accept any key you offered. In order of likelihood:

Wrong user. ubuntu on Ubuntu images, ec2-user on Amazon Linux, root on most bare VPSes. The same key with the wrong username produces exactly this error.
Your key wasn't offered. ssh -v shows every key tried. If your key isn't in the list, point at it explicitly: ssh -i ~/.ssh/id_ed25519 user@host.
The key isn't on the server. Its public half must be one line in ~user/.ssh/authorized_keys — for that user, not root's.
Server-side permissions. sshd refuses to honor authorized_keys if the home dir, ~/.ssh (700), or the file itself (600) is group-writable. This is the classic "I copied the key and it still doesn't work".

4. `Permission denied` when you expected a password prompt

If you wanted password auth and never got asked, the server has PasswordAuthentication no — most cloud images ship that way, and it's the right default. Use the provider's console or your existing key to get in, then add the new key properly rather than switching passwords back on.

5. `Host key verification failed` / `REMOTE HOST IDENTIFICATION HAS CHANGED`

The scary banner with the ASCII skull energy. The server presented a different key than the one you trusted before. Two explanations: the machine was legitimately rebuilt/reinstalled (overwhelmingly the common case), or something between you and the server is impersonating it (the case the warning exists for).

If — and only if — you know the server was rebuilt: ssh-keygen -R hostname removes the stale entry, and the next connect re-trusts. Don't blindly script that removal into your workflow; the one time the warning is real, it's the only warning you get.

6. `Too many authentication failures`

Your agent enthusiastically offered six keys, the server's MaxAuthTries said enough. Tell the client to offer only the key you mean:

ssh -o IdentitiesOnly=yes -i ~/.ssh/the_right_key user@host

…or make it permanent in ~/.ssh/config per host. If you carry many keys, IdentitiesOnly yes under Host * will save you this error forever.

7. `WARNING: UNPROTECTED PRIVATE KEY FILE`

Your private key is readable by others, and the client refuses to use it. chmod 600 ~/.ssh/id_ed25519. On Windows this appears after copying keys between machines or out of a cloud drive — fix it via the file's Security properties, or keep keys out of synced folders entirely.

8. `client_loop: send disconnect: Broken pipe` (the session that dies when you look away)

Idle connections dropped by a NAT router or aggressive firewall between you and the server. Keepalives fix it client-side:

Host *
    ServerAliveInterval 30
    ServerAliveCountMax 4

Two minutes of silence tolerated, packets every 30 seconds so the NAT table never forgets you. If sessions die under load rather than idle, that's a different animal — look at MTU (VPNs especially) rather than keepalives.

9. `no matching key exchange method found` / `no matching cipher`

You're talking to something old — a router, a switch, an appliance stuck on legacy crypto. Modern OpenSSH removed those algorithms for good reason. Re-enable them for that one host only, never globally:

Host ancient-switch
    KexAlgorithms +diffie-hellman-group14-sha1
    Ciphers +aes256-cbc

The error message names the algorithms the server offered; add the least-bad one it lists.

10. `ssh_exchange_identification: read: Connection reset by peer`

The TCP connection opened and was immediately slammed shut, before SSH even said hello. Usual suspects: fail2ban or DenyHosts has banned your IP (check /etc/hosts.deny and fail2ban's jail from a console), sshd is overloaded (MaxStartups exhausted by a scanner hammering the port), or a load balancer health check is eating connections. If it's fail2ban and it's your own server, the fix is a console login and fail2ban-client unban <your-ip> — then move SSH off scanners' radar or tighten the jail so you're not next week's collateral.

Make the fixes stick

Half of these are one-off fixes; the other half deserve a line in ~/.ssh/config so they never come back — keepalives, IdentitiesOnly, per-host ports and identities. Config beats memory.

The other thing that beats memory is a client that keeps state for you. Termalin stores per-host settings — port, user, key, keepalives — with the host itself, verifies servers on first connect and warns loudly when a fingerprint changes, and its status bar shows the machine's vitals live, so "is the box even up?" stops being a diagnostic step. The Free tier has no host limits — grab it and retire a few of these errors permanently.

DEV Community: Svyatoslav Pavlov

Every way to give an AI agent SSH access, ranked by blast radius

1. Paste the private key into the agent's environment

2. Forward your agent into the box the AI runs on

3. A raw SSH-MCP server holding a key, no policy

4. A scoped credential per task

5. A custodian with per-host policy, live watch, and audit

The ranking, compressed

SSH port forwarding, explained: local, remote and dynamic tunnels

The one question that picks the flag

Local forwarding (-L) — pull a remote service to localhost

Remote forwarding (-R) — expose your machine to the server's side

Dynamic forwarding (-D) — a SOCKS proxy in one flag

The flags that make it usable

Make it permanent in ssh_config

Three traps

When juggling tunnels by hand gets old

How to give a local LLM safe SSH access to your servers

Why "local" doesn't make server access safe

Three ways to do it badly

The pattern that works: a custodian, not a copy

Wiring it to a local model

How Termalin does it

Start with one boring host

SSH key types in 2026: Ed25519 vs RSA vs ECDSA — which to use

The one-line recommendation

The four you'll meet

Quick decision

Things worth doing while you're here

Where a client helps

The ~/.ssh/config file: stop retyping the same SSH flags

Where it lives and how it's read

The building block: a host alias

Directives that earn their place

A realistic config, top to bottom

Two traps

When the config file isn't enough

How to let an AI agent deploy to your server — without handing it your SSH keys

Three ways to do it badly

What good looks like: a custodian, not a copy

How Termalin implements it

Start with one boring host

How to record SSH sessions — without keylogging yourself

The quick ways to record a session

The trap: recording input records your secrets

Storage is part of the design

The agent angle

How Termalin does it

SSH clients for AI agents in 2026: the landscape

The three desktop clients

The headless option: standalone MCP servers

How to choose

Where this category is going

How to connect Claude Code to a server over SSH — a hands-on walkthrough

What you need

Step 1 — turn agent access on

Step 2 — register the server with Claude Code

Step 3 — give it a real chore

Where the boundaries are

No desktop around? Use the hosted endpoint

The habit that makes it stick

SSH errors, decoded: the ten you'll actually hit and how to fix them

1. Connection refused

2. Connection timed out

3. Permission denied (publickey)

4. Permission denied when you expected a password prompt

5. Host key verification failed / REMOTE HOST IDENTIFICATION HAS CHANGED

6. Too many authentication failures

7. WARNING: UNPROTECTED PRIVATE KEY FILE

8. client_loop: send disconnect: Broken pipe (the session that dies when you look away)

9. no matching key exchange method found / no matching cipher

10. ssh_exchange_identification: read: Connection reset by peer

Make the fixes stick

Local forwarding (`-L`) — pull a remote service to localhost

Remote forwarding (`-R`) — expose your machine to the server's side

Dynamic forwarding (`-D`) — a SOCKS proxy in one flag

1. `Connection refused`

2. `Connection timed out`

3. `Permission denied (publickey)`

4. `Permission denied` when you expected a password prompt

5. `Host key verification failed` / `REMOTE HOST IDENTIFICATION HAS CHANGED`

6. `Too many authentication failures`

7. `WARNING: UNPROTECTED PRIVATE KEY FILE`

8. `client_loop: send disconnect: Broken pipe` (the session that dies when you look away)

9. `no matching key exchange method found` / `no matching cipher`

10. `ssh_exchange_identification: read: Connection reset by peer`