DEV Community: Rafi Bagaskara Halilintar

SSH Compression After OpenSSH 10.6: What Changed (2026)

Rafi Bagaskara Halilintar — Fri, 13 Nov 2026 03:20:38 +0000

If you have Compression yes in your ~/.ssh/config or type ssh -C out of habit, your transfers may have quietly grown. OpenSSH 10.6, released on October 6, 2026, disabled the LZ77 part of SSH compression to close a side channel. The Compression option still exists and still negotiates zlib@openssh.com, but it now does far less work.

We wanted to know how much less, so we built OpenSSH 10.5p1 and 10.6p1 from source and pushed the same files through both. This guide covers what changed in the code, the numbers we measured, why the change was made, and what to use for bulk transfers now.

Quick Summary: What You'll Learn

What OpenSSH 10.6 changed in SSH compression, straight from the source code.
Measured wire bytes for ssh -C on text, JSON logs and random data, 10.5 vs 10.6.
Why an older version number doesn't mean you still have the old behavior (Ubuntu 24.04 already backported it).
The side channel in plain terms, and when compression is still unsafe even after the fix.
What to use instead: rsync -z, zstd in a pipe, and how to check what a session negotiated.

Did OpenSSH 10.6 make SSH compression weaker?

Yes, on purpose. The 10.6 release notes list it under "Potentially-incompatible changes": "compression will be less effective as a result of the change noted below in the Security section." The security entry says ssh and sshd now "disable LZ77 dictionary coder to mitigate the side-channel leaks" described in a 2026 paper titled "Crossing the Streams: SSH Plaintext Recovery via a Common Compression Context in Multiplexed Channels."

In the code, the change is one call in packet.c. OpenSSH 10.5 started outgoing compression with zlib's deflateInit(stream, 6), which is regular gzip-style deflate at level 6. OpenSSH 10.6 calls:

deflateInit2(&ssh->state->compression_out_stream,
    Z_BEST_SPEED, Z_DEFLATED, 15, 8, Z_HUFFMAN_ONLY)

Z_HUFFMAN_ONLY is a zlib strategy that skips string matching entirely. Deflate normally does two things: LZ77 finds repeated strings and replaces them with short back-references to earlier data, then Huffman coding gives frequent symbols shorter bit codes. With Huffman only, the second step remains and the first is gone. Repetition, which is where most of deflate's gains come from on logs, JSON and source code, no longer helps.

The wire format is unchanged. Both ends still negotiate zlib@openssh.com, and a Huffman-only stream is a valid deflate stream, so an old client can decompress what a new server sends and the other way around. Nothing breaks. It just gets bigger.

How much bigger does ssh -C traffic get?

We measured it. The setup: OpenSSH 10.5p1 and 10.6p1 built from the official portable tarballs against the same zlib and OpenSSL 3.0.13, each used as a client to upload a file to a local sshd with Compression yes. Each run piped a file into ssh ... 'cat > /dev/null' and read two lines from ssh -v at exit: Transferred: sent N and compress outgoing: raw data X, compressed Y, factor F. Four test files:

text: 16.2 MB of roff man page source from /usr/share/man/man1.
seq: 22.9 MB from seq 1 3000000.
json: 7.1 MB of JSON log lines (60,000 lines, same keys, varying values).
random: 20 MB from /dev/urandom.

Bytes on the wire with ssh -C (the factor is compressed size divided by raw size):

text: 10.5 sent 4,338,600 bytes (factor 0.27). 10.6 sent 10,191,048 bytes (factor 0.63). That's 2.3 times more traffic.
seq: 10.5 sent 6,139,392 (0.27). 10.6 sent 9,257,960 (0.40).
json: 10.5 sent 449,860 (0.06). 10.6 sent 4,218,588 (0.60). More than 9 times more traffic.
random: both 1.00. Random data never compressed, and both runs sent a few kilobytes more than the uncompressed run.

The pattern matches the code change. Data with long repeated strings, like JSON logs where every line repeats the same keys, lost almost all of its benefit, going from 6% of the original size to 60%. Data with a skewed character distribution but less exact repetition, like digits and newlines, kept more. Already-compressed or encrypted data was never helped and still isn't.

Two caveats. These are single runs on one machine, so treat the byte counts as solid and anything about speed as anecdotal. And compression applies per direction: each side compresses what it sends, so a 10.6 client uploading to an older server is weaker on the upload and unchanged on the download, until the server side is patched too.

On loopback, where bandwidth is effectively free, ssh -C only costs CPU. In our runs the 10.6 upload of the text file took less time than the 10.5 one, because Huffman-only is cheaper to compute than full deflate. On a real network the tradeoff is the opposite: you spend less CPU and send more bytes.

Why doesn't the version number tell you which behavior you have?

Because distributions backport security fixes into older versions. Our test box runs Ubuntu 24.04, and its client still reports OpenSSH_9.6p1 Ubuntu-3ubuntu13.20. Uploading the same text file with that client gave a factor of 0.63, identical to 10.6. Downloading from the Ubuntu sshd gave 0.63 as well.

The package changelog explains it. The 1:9.6p1-3ubuntu13.20 security update, dated October 8, 2026, includes "SECURITY UPDATE: incorrect use of LZ77 dictionary coder" with the note "Disable LZ77 dictionary coder" in packet.c, tracked as CVE-2026-106582.

So ssh -V is not a reliable check here. Other distributions may ship the backport on a different schedule, or not at all for older releases. Measure instead, as shown in the next section, or read your package changelog:

zcat /usr/share/doc/openssh-client/changelog.Debian.gz | grep -n -i lz77

That path is Debian and Ubuntu specific. On RPM-based systems, look for a similar entry with rpm -q --changelog openssh-clients | grep -i lz77; we only verified the Ubuntu package.

How do you check what compression a session actually uses?

ssh -v prints the negotiated compression method for each direction during key exchange, and the achieved ratio when the connection closes:

ssh -v -C user@host exit 2>&1 | grep -E 'compression:|compress (outgoing|incoming)'

Output from our lab, trimmed:

debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: zlib@openssh.com
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: zlib@openssh.com
debug1: compress outgoing: raw data 123, compressed 140, factor 1.14
debug1: compress incoming: raw data 514, compressed 450, factor 0.88

compression: none means compression is off for that direction. zlib@openssh.com means compression starts after authentication, which is the only mode current OpenSSH servers allow.

The factor line is the useful one. For a quick test of your own path, push something repetitive through it and look at the outgoing factor:

seq 1 1000000 | ssh -v -C user@host 'cat > /dev/null' 2>&1 | grep 'compress outgoing'

For seq output, a pre-change client landed near 0.27 in our runs and a patched one near 0.40. For a real comparison, use a sample of the data you actually move.

What was the side channel, in plain terms?

LZ77 saves space by spotting text it has already seen and writing "copy 20 bytes from 300 bytes back" instead of the text itself. In SSH, all channels of one connection share a single compression context. That includes your shell, an scp transfer, and any port forward running over the same connection, including a ControlMaster-multiplexed one.

Now suppose an attacker can push data into one of those channels, for example through a forwarded port that serves web traffic they can influence. They send a guess at a secret that is flowing through another channel, like a token in your shell session. If the guess matches what the compressor saw recently, it compresses into a short back-reference and the encrypted packet is a little smaller. If it doesn't, the packet is a little larger. Encryption hides the content, not the length. By watching packet sizes and refining guesses, the attacker can recover the secret piece by piece.

If that sounds familiar, it's the same family as the CRIME and BREACH attacks on TLS compression. The OpenSSH release notes describe it as a chosen-plaintext attack in which "attacker-controlled input can recognizably reflect into the total length of transmitted ciphertexts." Removing the dictionary coder removes the back-references the attack relies on.

The man pages already warned about this before 10.6, and they still do. From ssh_config(5): "If untrusted traffic (such as an open port-forward) is permitted over the connection alongside trusted traffic, then compression may leak information about session contents. For this reason, it is not recommended to enable compression for connections that share trusted and untrusted traffic." That advice stands. Huffman-only coding still varies output size with the data, just much less, so don't treat 10.6 as a reason to turn compression back on for mixed-trust connections.

What should you use instead of ssh -C?

The release notes give the direction: "Users are encouraged to use application-level compression over the SSH protocol where possible, as this will typically be more effective and will be completely immune to this type of attack." It's immune because the compressor only ever sees your one stream, never another channel's data. In our lab it was also much smaller than old ssh -C ever was.

All numbers below use the 10.6 client with Compression=no, so the only compression is the application's own.

rsync -z

rsync compresses file data itself when you pass -z, and since rsync 3.2 both sides negotiate the algorithm from a list. Our rsync 3.2.7 build listed zstd lz4 zlibx zlib none, and plain -z picked zstd. Results for the 16.2 MB text file:

no compression: 16,156,275 bytes sent
-z (negotiated zstd): 2,522,169 bytes
--zc=zlib: 4,310,739 bytes
--zc=lz4: 7,990,462 bytes

rsync -az ./site/ user@host:/srv/site/
# force an algorithm (implies -z); both ends must support it
rsync -a --zc=zstd ./site/ user@host:/srv/site/

--zc is short for --compress-choice, and per the rsync man page it implies --compress unless you pass none. If the server's rsync is older and can't do the requested algorithm, it says so instead of silently falling back. Our SFTP vs rsync guide covers the rest of the rsync side, including the --delete trap.

zstd or gzip in a pipe

For one-off copies of a directory, compress the tar stream yourself and decompress on the other side:

tar -cf - ./logs | zstd -T0 -3 -c | ssh user@host 'zstd -d -c | tar -xf - -C /srv/archive'

-T0 uses all cores, -3 is zstd's default level, -c writes to stdout and -d decompresses. We ran this exact pipeline in the lab and compared the files with cmp: identical. Wire bytes for single files, piped with Compression=no:

text, gzip -6: 4,314,564 bytes. zstd -3: 2,788,524.
json, gzip -6: 449,068 bytes. zstd -3: 122,812.

gzip -6 lands almost exactly where pre-10.6 ssh -C did, which makes sense: same deflate algorithm, same level. zstd at its default level beat both by a wide margin. zstd has to exist on both ends. If it doesn't on the server, gzip and gunzip are everywhere.

The same idea works for database dumps and logs: compress where the data is produced.

ssh user@host 'pg_dump mydb | zstd -c' > mydb.sql.zst
ssh user@host 'journalctl -u nginx --since today | gzip -c' > nginx.log.gz

Turn compression off where it does nothing

If you have Compression yes under Host *, it now buys much less than it used to on most connections, and on fast links it never helped. The default is no. A tidy config keeps compression off globally and enables it only where it still earns its place:

Host slow-site-gw
    HostName gw.slow-site.example
    Compression yes

Host *
    Compression no

ssh uses the first value it finds for each option, so the specific Host block has to come before Host *. Our ssh config organization guide shows a layout that keeps that ordering readable.

When is ssh -C still worth it?

On genuinely slow links, a factor of 0.6 on text is still a 40% cut. The ssh(1) man page has always framed it this way: compression "is desirable on modem lines and other slow connections, but will only slow down things on fast networks." A shell session over a tethered phone, a satellite link or a congested VPN can still feel better with it. For anything bulk, application-level compression wins on both size and security.

Avoid it on connections that carry untrusted traffic next to trusted traffic. The usual cases are a jump host connection with port forwards for other people's traffic, or a multiplexed ControlMaster connection that mixes your shell with a forward to a public-facing service. If you route through a bastion, our ProxyJump setup guide shows how to keep hops separate.

On the server, sshd_config takes Compression yes, delayed (a legacy synonym for yes) or no, with yes as the default. A server that sets no turns compression off for every client (sessions simply negotiate none), which is a reasonable choice for a bastion that carries forwards.

Where does termique fit?

termique is a GUI SSH manager with its own SSH stack, so Compression lines in your ~/.ssh/config don't apply to it, and its docs don't list an SSH compression setting. The advice in this guide still applies inside termique's terminal: pipe through zstd or use rsync -z from the shell, and the compression happens in your application stream, not in the SSH layer.

What termique adds is the part around the session. Port forwards (local, remote and SOCKS5) are configured per host rather than living in a shell history, which makes it easier to see which connections carry forwarded traffic. Your SSH passwords and private keys are end-to-end encrypted before they sync between devices, so the sync server only stores ciphertext. Hosts, groups and snippets sync as plaintext metadata. The details are on our security page, and the wider hardening checklist is in our SSH security best practices guide.

FAQ

Is ssh -C slower after OpenSSH 10.6?

Not on CPU: Huffman-only coding is cheaper than full deflate, and in our loopback test the 10.6 upload finished faster than 10.5. What changes is size. Repetitive data like JSON logs sent several times more bytes in our test, so on a slow link transfers that relied on ssh -C take longer.

Does Compression yes in ssh config still do anything?

Yes. It still negotiates zlib@openssh.com and applies Huffman coding, which reduced our text sample to 63% of its size and the seq output to 40%. It no longer removes repetition, which was where most of the gain came from.

Is rsync -z or ssh -C better?

rsync -z. In our test it sent 2.5 MB for a 16.2 MB text file with negotiated zstd, against 10.2 MB for ssh -C on 10.6. It also compresses only rsync's own data, so it can't leak across SSH channels. Don't use both at once; compressing twice only costs CPU.

Does SSH support zstd compression?

Not in the SSH protocol as OpenSSH implements it. The only methods are zlib@openssh.com and none. To get zstd over SSH, compress in the application: rsync -z (which negotiates zstd when both ends have it) or a zstd pipe.

Why is my ssh -C transfer bigger on Ubuntu 24.04 when ssh -V still says 9.6?

Ubuntu backported the LZ77 change into its 9.6p1 package in the October 8, 2026 security update (1:9.6p1-3ubuntu13.20, CVE-2026-106582). The version string stays 9.6 while the compression behavior matches 10.6.

If you move files between more servers than you want to track by hand, try termique free: hosts and port forwards in one place, and credentials encrypted before they sync.

SSH Certificate Authentication with ssh-keygen (2026)

Rafi Bagaskara Halilintar — Wed, 11 Nov 2026 03:20:48 +0000

You have forty devices in the field, three people who need shell access, and an authorized_keys file on every one of them. Someone leaves, and you get to touch forty files. Someone gets a new laptop, and you get to touch forty files again. A device gets reflashed, and everyone's terminal shouts that the host key changed.

SSH certificate authentication fixes both directions of that problem with tools you already have. One CA key signs user keys, every server trusts that one CA, and a second CA signs host keys so clients stop asking "are you sure you want to continue connecting?". No extra daemon, no vendor, just ssh-keygen and two lines of sshd_config.

This guide is the hands-on version. If you're still deciding whether certificates are worth it for your team, read SSH certificate authorities vs public key auth for teams first. Every command below was run against OpenSSH 9.6 while writing this.

Quick Summary: What You'll Learn

How SSH certificate authentication works, in one paragraph.
How to create a user CA and sign a short-lived user certificate with ssh-keygen -s.
How to make sshd trust the CA with TrustedUserCAKeys and map roles with AuthorizedPrincipalsFile.
How host certificates replace the trust-on-first-use prompt with one @cert-authority line.
What "Certificate invalid: name is not a listed principal" means, in both places it shows up.
How to revoke a certificate early with a KRL, and how to roll this out without locking yourself out.

How does SSH certificate authentication work?

A user still has a normal key pair. Instead of copying the public key to every server, you sign it with a CA key. The signature produces a third file, id_ed25519-cert.pub, which contains the user's public key plus metadata: a key ID, a serial number, a list of principals (the account or role names it is valid for), a validity window and a set of permissions.

The server holds only the CA's public key. When a user connects with a certificate, sshd checks three things: the CA signature is valid, the certificate is inside its validity window, and one of its principals is allowed for the account being logged into. If all three pass, the user is in. No authorized_keys entry is involved.

Host certificates are the same idea in reverse. A host CA signs each server's host key, and clients trust the host CA instead of remembering individual host keys in known_hosts.

OpenSSH certificates are not X.509. The ssh-keygen man page calls them "a different, and much simpler, format". You don't need OpenSSL, a PKI team or a CRL server.

What do you need before you start?

OpenSSH on clients and servers. Certificate support has been in OpenSSH for well over a decade, so any supported distro is fine.
A machine to hold the CA private keys. Treat it like a root password: ideally offline or a locked-down signing host, never a server in the fleet.
A naming plan for principals. Principals are just strings. Roles work better than people: fleet-ops, deploy, readonly. You decide on each server which roles may log into which account.
One SSH session left open on a test server while you change sshd_config. You will want it if something goes wrong.

How do you create the SSH certificate authority keys?

Create two CA keys, one for users and one for hosts. Keeping them separate means a leak of one doesn't let an attacker forge the other kind of certificate.

ssh-keygen -t ed25519 -f user_ca -C "user-ca 2026"
ssh-keygen -t ed25519 -f host_ca -C "host-ca 2026"

Give both a strong passphrase when prompted. You now have user_ca and host_ca (private, stay on the signing machine) and user_ca.pub and host_ca.pub (public, go to servers and clients).

Ed25519 is a sensible default for a new CA. If you have very old devices that only understand RSA, check what they support before you pick; a CA nobody can verify is not much use.

How do you sign a user certificate with ssh-keygen -s?

The user generates a key pair as usual and sends you only the .pub file. You sign it:

ssh-keygen -s user_ca \
  -I ops-laptop-03 \
  -n fleet-ops,deploy \
  -V -5m:+8h \
  -z 1042 \
  ops_key.pub

What each flag does, per the ssh-keygen man page:

-s user_ca: sign with this CA private key.
-I ops-laptop-03: the key ID. It is written to the server's auth log on every login and can be used to revoke the certificate. Make it something you can trace back to a device or a request.
-n fleet-ops,deploy: the principals. Without at least one principal, sshd refuses the certificate when it is trusted via TrustedUserCAKeys.
-V -5m:+8h: valid from five minutes ago until eight hours from now. The five-minute back-dating absorbs small clock drift between the signing machine and your devices.
-z 1042: a serial number. It defaults to zero, so set it yourself; serials make revocation precise.

The result is ops_key-cert.pub, next to the key. Inspect any certificate with ssh-keygen -L:

$ ssh-keygen -L -f ops_key-cert.pub
ops_key-cert.pub:
        Type: ssh-ed25519-cert-v01@openssh.com user certificate
        Public key: ED25519-CERT SHA256:ohGkf96o...
        Signing CA: ED25519 SHA256:msQOMhsA... (using ssh-ed25519)
        Key ID: "ops-laptop-03"
        Serial: 1042
        Valid: from 2026-10-20T20:57:52 to 2026-10-21T05:02:52
        Principals:
                fleet-ops
                deploy
        Critical Options: (none)
        Extensions:
                permit-X11-forwarding
                permit-agent-forwarding
                permit-port-forwarding
                permit-pty
                permit-user-rc

Can you restrict what a certificate is allowed to do?

Yes, with -O. By default a user certificate permits X11 forwarding, agent forwarding, port forwarding, a PTY and ~/.ssh/rc. For a tighter certificate, clear everything and add back what you need:

ssh-keygen -s user_ca -I ops-laptop-03 -n fleet-ops -V +8h \
  -O clear -O permit-pty ops_key.pub

Two critical options are worth knowing for automation:

-O source-address=10.0.0.0/8: the certificate only works from these CIDR ranges.
-O force-command=/usr/local/bin/backup.sh: whatever the client asks for, this command runs instead. Useful for a backup job's certificate.

Order matters with clear: put it before the permit-* options, or it wipes them.

How do you configure sshd to trust the CA?

Copy user_ca.pub to each server and add this to /etc/ssh/sshd_config:

TrustedUserCAKeys /etc/ssh/user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

TrustedUserCAKeys tells sshd which CAs may sign user certificates. The file can hold more than one CA public key, one per line, which you will need when you rotate the CA.

AuthorizedPrincipalsFile maps principals to local accounts. %u expands to the username being logged into, so the file for the ops account is /etc/ssh/auth_principals/ops:

fleet-ops
deploy

Any certificate carrying fleet-ops or deploy as a principal can now log in as ops. Without an AuthorizedPrincipalsFile, the rule is stricter and less flexible: the certificate must list the literal username as a principal. That works for a single account, but role names scale better across a fleet where every device has the same ops and deploy users.

Validate the config before reloading, from the session you kept open:

sudo sshd -t && sudo systemctl reload ssh

The service is called ssh on Debian and Ubuntu and sshd on most other distros. Now open a second terminal and log in. Don't close the first one until the second works.

How does the client use the certificate?

Mostly, it just works. If the certificate sits next to the key with the -cert.pub suffix, ssh loads it automatically for any IdentityFile you use. You can also point at it explicitly in ~/.ssh/config:

Host *.fleet.example.com
    User ops
    IdentityFile ~/.ssh/ops_key
    CertificateFile ~/.ssh/ops_key-cert.pub

If you use ssh-agent, ssh-add picks up the certificate along with the key:

$ ssh-add ~/.ssh/ops_key
Identity added: /home/you/.ssh/ops_key (ops-laptop)
Certificate added: /home/you/.ssh/ops_key-cert.pub (ops-laptop-03)

When an eight-hour certificate expires, the key is still fine. The user gets a fresh signature and carries on. That renewal step is the part teams usually automate later, with a small signing service or a tool like step-ca, which the comparison post walks through.

How do host certificates get rid of the "authenticity of host" prompt?

On each device, sign its existing host public key with the host CA. Note the -h flag, which makes it a host certificate:

ssh-keygen -s host_ca \
  -I device-042 \
  -h \
  -n device-042.fleet.example.com,10.20.0.42 \
  -V +52w \
  /etc/ssh/ssh_host_ed25519_key.pub

For host certificates, principals are the names clients will connect with: hostnames and IPs. Then tell sshd to present it:

HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

On every client, one line in ~/.ssh/known_hosts (or /etc/ssh/ssh_known_hosts for all users) replaces forty individual entries:

@cert-authority *.fleet.example.com,10.20.0.* ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... host-ca 2026

Now a reflashed device with a new host key and a fresh certificate connects without a warning, and an impostor without a valid certificate still fails. If you want the background on why that first-connection prompt exists at all, see SSH host key verification explained.

Why does SSH say "Certificate invalid: name is not a listed principal"?

This message shows up in two different places, and they mean different things.

On the client, before login. The server presented a host certificate, but the name you typed isn't one of its principals. You signed the cert for device-042.fleet.example.com and connected to device-042 or to an IP you didn't list. OpenSSH prints the error and falls back to normal host key checking, so you get the old trust-on-first-use prompt again (or "Host key verification failed" if StrictHostKeyChecking is on). Fix: re-sign the host key with every name people actually use in -n.

In the server's auth log. The user certificate's principals don't include the account name, and there's no AuthorizedPrincipalsFile to map them. The client sees only Permission denied (publickey). Fix: add the username to the certificate's principals, or set up a principals file for that account.

If you do use an AuthorizedPrincipalsFile, the server-side wording changes. A certificate whose principals aren't in the file is logged as Certificate does not contain an authorized principal. Check the file for the account you're logging into, and check for typos; principals are exact string matches.

Two quick ways to see what's going on:

ssh-keygen -L -f ~/.ssh/ops_key-cert.pub   # what the cert actually says
ssh -v ops@device-042.fleet.example.com     # which cert the client offers

How do you revoke an SSH certificate before it expires?

Short validity is your first line of defense: an eight-hour certificate that leaks is useless by tomorrow. For anything longer lived, or when you can't wait, use a Key Revocation List (KRL).

Write a small spec file:

serial: 1042
id: ops-laptop-03

Generate the KRL with the CA public key:

ssh-keygen -k -f revoked.krl -s user_ca.pub krl.spec

To add more entries later, use -u to update instead of replacing. To check whether a given certificate is revoked, -Q exits non-zero if it is:

ssh-keygen -Q -f revoked.krl ops_key-cert.pub

Distribute revoked.krl to every server and reference it:

RevokedKeys /etc/ssh/revoked.krl

One warning from the sshd_config man page: if the RevokedKeys file is not readable, public key authentication is refused for all users. Deploy the file before the config line, and keep its permissions right.

How do you roll SSH certificates out to a fleet without locking yourself out?

Do it in an order where every step is reversible:

Push user_ca.pub, the principals files and the two sshd_config lines to a handful of devices. Leave authorized_keys alone. Both methods now work side by side.
Issue certificates to the people who need access and confirm they can log in with the certificate alone (ssh -o IdentitiesOnly=yes -i ~/.ssh/ops_key ... with no matching authorized_keys entry).
Roll the same config to the rest of the fleet with whatever you already use: Ansible, your image build, cloud-init.
Only then remove the old public keys from authorized_keys. Keep one break-glass key, stored offline, for the day the CA machine is unavailable.

For CA rotation later: add the new CA public key as a second line in TrustedUserCAKeys, start signing with the new CA, wait until every old certificate has expired, then remove the old line. With short-lived certificates, that wait is hours, not months. The same overlap pattern is covered in more detail in SSH key rotation best practices.

When is an SSH certificate setup overkill?

Honestly, for a lot of people. If you have five servers and two people, a well-kept authorized_keys and one key per device is fewer moving parts than a CA. You also take on new responsibilities: protecting the CA key, keeping clocks roughly in sync across the fleet (validity checks depend on it), and building a renewal habit so nobody is locked out at 2 AM because their certificate expired at midnight.

Certificates start paying off when one of these is true: the number of devices grows faster than you can edit files, people join and leave regularly, devices get reflashed often, or an auditor wants to know who logged in where. That last one is a quiet win: every login logs the key ID and serial, so "which certificate was used" is in the auth log by default. For the broader picture of team access, SSH key management for teams covers the options side by side.

Where does termique fit?

termique is a desktop and mobile SSH manager, so it sits on the client side of this picture, not the CA side. Its documentation covers key-pair authentication: generating ed25519 or RSA keys, importing existing keys in PEM or OpenSSH format, and storing private keys encrypted on your device before anything syncs. The docs don't describe certificate support, so for logins that depend on a -cert.pub file, use OpenSSH directly as shown above.

Where it helps around a certificate rollout:

A single host list with groups, synced across your devices. Free covers 3 hosts; a whole fleet needs Pro, which removes the host cap.
Keys and passwords for the hosts still on plain key auth, including your break-glass key, encrypted end to end so the sync server only stores ciphertext. Host entries, groups and snippets sync as plaintext metadata; the security page spells out exactly what is and isn't encrypted.
Per-host command logs on Pro, which pair well with the key ID in sshd's auth log when you need to answer "who ran what". The post on per-command audit logs for shared SSH access explains how that works.

Keep the CA private keys out of every day-to-day tool, termique included. They belong on the signing machine and nowhere else.

FAQ

What is the difference between an SSH certificate and an SSH key?

An SSH key is a key pair the server trusts because its public half is listed in authorized_keys. An SSH certificate is that same public key plus a CA signature, principals, a validity window and permissions. The server trusts the CA instead of each key, so adding or removing a user no longer means editing every server.

How long should an SSH user certificate be valid?

As short as your renewal process allows. A working day (-V -5m:+8h) is a common choice for people, because a stolen certificate expires before most incidents are even noticed. Automation that can renew itself can go shorter. Long-lived user certificates bring back the revocation problem certificates were meant to solve.

Do SSH certificates work with ssh-agent?

Yes. When you run ssh-add on a key that has a matching -cert.pub file next to it, the agent loads both, and ssh-add -l lists the key and the certificate as separate entries.

Can one certificate log into different usernames on different servers?

Yes, that's what principals plus AuthorizedPrincipalsFile are for. Give the certificate a role principal like fleet-ops, then list fleet-ops in /etc/ssh/auth_principals/ops on the devices where that role should be able to log in as ops.

Do I need step-ca or Vault to use SSH certificates?

No. Everything in this guide uses ssh-keygen and sshd alone. Tools like step-ca or Vault add automated issuance, short-lived certificates through SSO and an API, which matter once manual signing becomes a bottleneck.

Try termique

Certificates handle trust for the fleet. You still need a sane way to keep track of hosts, the keys that remain and what was run where. termique is a free, native SSH manager with end-to-end encrypted credentials, on desktop and mobile. Download termique and add your first hosts.

Permission Denied (publickey): How to Fix It (2026)

Rafi Bagaskara Halilintar — Fri, 06 Nov 2026 03:20:53 +0000

You added your key to the server, you run ssh, and you get one line back: Permission denied (publickey). No hint about which key, which file, or which side is wrong. That's on purpose. The server tells an unauthenticated client as little as possible, so the real reason sits in two places you have to go and read: the client's verbose output and the server's auth log.

This guide walks through both. Every error message below was reproduced on OpenSSH 9.6 against a throwaway sshd on localhost while writing this, so the strings match what you'll actually see. If your error says Connection refused or Connection timed out instead, you never reached authentication; start with connection refused vs timeout instead.

Quick Summary: What You'll Learn

What Permission denied (publickey) means, and the one thing it rules out.
How to read ssh -v to see which keys your client offered.
The sshd log lines that name the actual cause.
The usual fixes: wrong user, wrong key, file modes, a key ssh refuses to load, and old ssh-rsa signatures.
The GitHub, GitLab and Bitbucket version of the error.
A short checklist you can run top to bottom.

What does "Permission denied (publickey)" mean?

It means the connection worked, the SSH handshake worked, and authentication failed. The word in brackets is the list of methods the server still accepts. (publickey) alone means the server has password login turned off, so a key is the only way in, and none of the keys your client offered were accepted for that user.

That leaves a short list of causes:

You're logging in as the wrong user, so the server checks the wrong authorized_keys.
Your client offered a key, but not the one the server has.
The server has your key but refuses to read the file because of its permissions.
Your client never offered the key at all (it couldn't load it, or it skipped it).
The key type or signature algorithm isn't accepted on one side.

You find out which one in about a minute with ssh -v.

How do you see which key ssh actually offered?

Run the same command with -v:

ssh -v deploy@203.0.113.10

Skip the key exchange noise and look for the lines after Authentications that can continue. A successful login in our lab looked like this:

debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Will attempt key: good ED25519 SHA256:o7brbztlmr26oaVCi4sa6/VOiLZsMtjuTmXb/UsHdCE explicit
debug1: Offering public key: good ED25519 SHA256:o7brbztlmr26oaVCi4sa6/VOiLZsMtjuTmXb/UsHdCE explicit
debug1: Server accepts key: good ED25519 SHA256:o7brbztlmr26oaVCi4sa6/VOiLZsMtjuTmXb/UsHdCE explicit
Authenticated to 127.0.0.1 ([127.0.0.1]:2299) using "publickey".

And this is the same server with the wrong key:

debug1: Will attempt key: other ED25519 SHA256:R/2QZex7ZnX4f8qdaw07KYYfJHDWgSA88ufboBsdnMk explicit
debug1: Offering public key: other ED25519 SHA256:R/2QZex7ZnX4f8qdaw07KYYfJHDWgSA88ufboBsdnMk explicit
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
root@127.0.0.1: Permission denied (publickey).

Three patterns cover almost every case:

Offering public key followed by Authentications that can continue: the key was sent and the server said no. Either it's the wrong key, or the server can't read its file. Go to the server log.
No Offering public key line at all: your client never sent a key. Look for a warning above it (bad permissions, file not found) or a Skipping line.
Offering lines for keys you didn't expect: ssh is trying agent keys or defaults before the one you meant. Pin the key (see below), and if you see Too many authentication failures, that's the same problem with more keys.

Will attempt key lists every candidate in order, with its SHA-256 fingerprint. Keep that fingerprint; you'll compare it with the server side in a moment.

To check what your client will use before connecting, ssh -G prints the resolved config without opening a connection:

ssh -G deploy@203.0.113.10 | grep -E '^(user|hostname|port|identityfile|identitiesonly) '

With no IdentityFile configured, it lists the defaults it will look for (~/.ssh/id_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and a few more). If your key has any other filename, ssh won't find it unless you tell it.

Is the server checking the right user and the right file?

The client can't tell you why the server said no. The server's auth log can. On systemd distros:

sudo journalctl -u ssh -n 50     # Debian, Ubuntu
sudo journalctl -u sshd -n 50    # RHEL, Fedora, Alma, Rocky

Systems running rsyslog also write to /var/log/auth.log (Debian family) or /var/log/secure (RHEL family). If the box only accepts keys and yours doesn't work, you need console access or another account to read this; that's worth knowing before you lock yourself out of something.

These are the lines our lab produced, one per cause:

Failed publickey for root from 127.0.0.1 port 37630 ssh2: ED25519 SHA256:R/2QZex7...
Invalid user nosuchuser from 127.0.0.1 port 37646
Authentication refused: bad ownership or modes for file /.../authorized_keys

Wrong user

Invalid user means the account doesn't exist on that machine. The client still prints exactly the same Permission denied (publickey)., which is why this one wastes so much time. Cloud images are the usual trap: per the AWS docs, Amazon Linux and RHEL images use ec2-user, Ubuntu uses ubuntu, Debian uses admin. Logging into an Ubuntu instance as ec2-user fails with a perfectly good key. (If an EC2 connection hangs instead of being denied, that's a network problem; see debugging SSH timeouts on EC2.)

Set the user per host in ~/.ssh/config so you don't have to remember it:

Host web-prod
    HostName 203.0.113.10
    User ubuntu
    IdentityFile ~/.ssh/web-prod_ed25519
    IdentitiesOnly yes

IdentitiesOnly yes tells ssh to use only the configured identity files, even if your agent holds more keys. That keeps the offer list short and predictable.

Wrong key

Failed publickey ... ED25519 SHA256:... means the server read the file and the offered key isn't in it. Compare fingerprints. On the server:

ssh-keygen -lf ~/.ssh/authorized_keys

That prints one fingerprint per key line. On your machine, ssh-keygen -lf ~/.ssh/web-prod_ed25519.pub prints the fingerprint of your public key. If you only have the private key, ssh-keygen -y -f ~/.ssh/web-prod_ed25519 prints its public half, which you can paste into authorized_keys (one key per line, no line breaks inside the key).

Wrong file

sshd doesn't always read ~/.ssh/authorized_keys. The location comes from AuthorizedKeysFile, which can point elsewhere, list several files, or be overridden in a Match block. Ask sshd for its effective config instead of reading the file by eye:

sudo sshd -T | grep -iE '^(authorizedkeysfile|pubkeyauthentication|strictmodes) '

sshd -T is extended test mode: it validates the config and prints every setting as sshd will apply it.

Windows Server and Windows 10/11 OpenSSH have their own twist. For accounts in the Administrators group, Microsoft's docs say the key goes in C:\ProgramData\ssh\administrators_authorized_keys, not the file in your user profile, and that file's ACL must allow only Administrators and SYSTEM. Adding your key to C:\Users\you\.ssh\authorized_keys on an admin account is the classic "permission denied publickey windows" cause.

Why does sshd reject a key that's in authorized_keys?

This is the Authentication refused: bad ownership or modes line. With StrictModes yes, which is the default, sshd checks the ownership and modes of the user's files and home directory before accepting a login, and refuses if anything is writable by other users. In our lab, chmod 666 authorized_keys was enough: the key in the file was correct, the client printed Permission denied (publickey)., and only the server log said why.

The fix is the standard set of modes, run as the account owner:

chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Also check ownership with ls -ld ~ ~/.ssh ~/.ssh/authorized_keys. The files should belong to the account you log in as; if you created them with sudo, sudo chown -R deploy:deploy /home/deploy/.ssh puts them back.

Don't fix this by setting StrictModes no. It hides the symptom and leaves a writable file that decides who can log in.

What if ssh won't use your private key?

Sometimes the client is the one saying no. Two cases from the lab.

The private key is readable by other users:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for 'goodloose' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "goodloose": bad permissions
root@127.0.0.1: Permission denied (publickey).

chmod 600 on the private key fixes it. This happens a lot after copying keys from a USB stick, a Windows share, or a zip. One detail worth knowing: in this test the server log showed Accepted key ... found at .../authorized_keys:1 and then Connection closed. The client offered the matching .pub file, the server said that key is fine, and then the client couldn't produce a signature because it refused to load the private half. A server log that says "Accepted key" next to a failed login points at the client.

The key file doesn't exist at the path you gave:

Warning: Identity file doesnotexist not accessible: No such file or directory.

ssh warns and carries on with whatever other keys it can find, so the final error is the same. A typo in an IdentityFile path, or a key that only exists on your other laptop, is the usual suspect.

If your key has a passphrase and the prompt keeps rejecting it, that's a different failure with its own error text; see why your SSH key passphrase won't authenticate.

Why does an old RSA key suddenly fail?

OpenSSH 8.8 (September 2021) disabled RSA signatures using SHA-1, the ssh-rsa signature algorithm, by default. The key format didn't change: an existing RSA key still works with rsa-sha2-256 and rsa-sha2-512, which OpenSSH has supported since 7.2. Trouble starts when one side only speaks the old algorithm, usually an old appliance, an old embedded sshd, or a client config that pinned ssh-rsa.

In the lab we forced the client to sign only with SHA-1 against a 9.6 server, and ssh -v showed:

debug1: Skipping ssh-rsa key rsa - corresponding algorithm not supported by server
debug1: No more authentication methods to try.
root@127.0.0.1: Permission denied (publickey).

Note what's missing: no Offering public key line. The client skipped the key before sending it, so the server log only shows Connection closed by authenticating user.

For a legacy server you can't upgrade, the OpenSSH release notes give a per-host stopgap:

Host old-host
    HostkeyAlgorithms +ssh-rsa
    PubkeyAcceptedAlgorithms +ssh-rsa

Scope it to that one Host, never Host *. The real fix is a new Ed25519 key; our ssh-keygen guide covers generating one properly. If the RSA failure is on your own client, search your config for a pinned PubkeyAcceptedAlgorithms ssh-rsa (without the +), which replaces the whole default list.

How do you fix it for GitHub, GitLab and Bitbucket?

Git hosts produce the same error with a few extra causes. Per GitHub's troubleshooting docs:

Always connect as git. ssh -T your-username@github.com fails with Permission denied (publickey). The remote URL must be git@github.com:owner/repo.git. GitLab (git@gitlab.com) and Bitbucket (git@bitbucket.org) use the same git user.
Test the connection directly: ssh -T git@github.com should greet you by username. Add -v to see which key was offered.
Don't mix sudo and git. sudo git push runs as root and uses root's keys, not the ones you generated.
Check the key is loaded: ssh-add -l -E sha256 lists agent keys with SHA-256 fingerprints, and you compare them with the list under your account's SSH key settings.

If you have one key for work and one for personal repos, the host picks whichever key it sees first and that may belong to the other account. A host alias with its own IdentityFile and IdentitiesOnly yes fixes that; our post on managing multiple SSH keys across devices has the full config.

A checklist to run top to bottom

Run ssh -v and find the Offering public key lines. No offer means a client problem; offer then refusal means a server problem.
Confirm the username. Read the server log for Invalid user.
Compare the offered fingerprint with ssh-keygen -lf ~/.ssh/authorized_keys on the server.
Ask sshd where it reads keys: sudo sshd -T | grep -i authorizedkeysfile.
Fix modes: home not group/world-writable, ~/.ssh 700, authorized_keys 600, all owned by the user.
Fix the private key: chmod 600, correct path in IdentityFile.
On Windows admin accounts, use C:\ProgramData\ssh\administrators_authorized_keys.
For an old RSA setup, look for a Skipping ssh-rsa key line and prefer a new Ed25519 key over re-enabling SHA-1.
For Git hosts, connect as git and test with ssh -T.

Where does termique fit?

Most of this guide is about one question: which key is going to which host as which user. termique makes that explicit per host. Each saved host has its own username and auth type, and with key auth you pick the key from a dropdown, so there's no default key list being tried behind your back.

The SSH keys page shows each key's SHA-256 fingerprint, the same format ssh-keygen -lf ~/.ssh/authorized_keys prints on the server, so the "wrong key" check is a visual comparison. Keys can be generated (Ed25519 recommended, or RSA) or imported in OpenSSH or PEM format, and the private keys sync across your devices as end-to-end encrypted ciphertext. If a connection still fails, the built-in AI assistant can be asked about the error in the session.

termique is a free, native ssh manager we build, with end-to-end encrypted credentials. The free plan covers 3 hosts. It won't fix file modes on the server for you; that part is still chmod.

FAQ

Why do I get Permission denied (publickey) when my key is in authorized_keys?

Usually because sshd refuses to read the file. Check the server log for Authentication refused: bad ownership or modes, then set ~/.ssh to 700, authorized_keys to 600, and make sure the home directory isn't group or world writable. The other common cause is logging in as a different user than the one whose authorized_keys you edited.

How do I fix Permission denied (publickey) on GitHub?

Connect as git, not your username: ssh -T git@github.com. Make sure your key is loaded (ssh-add -l -E sha256) and listed in your GitHub SSH key settings, and don't run git with sudo.

What does "Permission denied (publickey,password)" mean?

Same failure, but the server also accepts passwords. Your keys were rejected and password login also failed or wasn't attempted. Read ssh -v the same way.

Why does Permission denied (publickey) happen on AWS EC2?

Most often the username doesn't match the image: ec2-user for Amazon Linux, ubuntu for Ubuntu, admin for Debian. Also check you're using the key pair the instance was launched with.

Is it safe to set StrictModes no to fix this?

No. It turns off the check that stops other users from editing the file that controls who can log in. Fix the permissions instead.

If you're juggling keys and usernames across a lot of servers, try termique free: one host entry per server, its key picked explicitly, its fingerprint on screen.

termique v0.9.0 - Agents that work on your servers

Rafi Bagaskara Halilintar — Wed, 04 Nov 2026 16:47:52 +0000

This is a feature release. The AI assistant in the terminal is gone, and Agents take its place: they work on your hosts over SSH, look into problems on their own and wait for your OK before changing anything.

Update from the app when the prompt appears, or grab a fresh build from the download page.

Features

Pick the engine. Choose termique AI, or Claude Code, Codex or OpenCode already on your computer.
Right next to your session. Agents sit next to Terminal and Files in each session.
On every plan. termique AI gives 15 prompts a day on Free and 100 on Pro, and shows how many are left.
Group rules. Allowed, Ask or Never for each kind of action, plus rules of your own.
sudo and updates always ask. sudo and system updates always wait for an OK.
Approve from anywhere. Approve from the Approvals page or your phone.
Host reports. Generate a report on a host.

Every agent follows the same rules and asks for the same approvals, whichever engine does the work, and everything it runs lands in the audit log.

The assistant answered questions about the terminal in front of you. Agents do the legwork on the host itself: they read the logs, metrics and files, follow the trail, and come back with what they found. When the next step changes something, it stops and waits for you.

Teams

Your rules travel with the host. People you share a host with follow your rules in the terminal and Files too.
One line, not a pop-up. A command that needs your OK waits in one line at the bottom of their terminal.
Trust for a while. Approve and trust someone for a while, or until their session ends.
A clear record. See what ran, who approved it and what was blocked.

The rules apply to the people you share with, not only to Agents. A teammate typing in the terminal or working in Files on your host meets the same Allowed, Ask and Never decisions an agent does.

Security

Agents can't get around a blocked command by spelling it differently.
Claude Code and Codex only get termique's tools on your hosts.
An approval runs its command once.

Bug fixes

A command pasted right after the prompt is read correctly.
Approval cards are no longer see-through.

Update from the app to get Agents, and tell us what you want them to do next.

Keep reading

SSH Keys on macOS with Touch ID: Secure Enclave Setup (2026)

Rafi Bagaskara Halilintar — Wed, 04 Nov 2026 03:20:57 +0000

A normal SSH key is a file. Anything that runs as you can read ~/.ssh/id_ed25519, and if the key has no passphrase, a copy of that file is a copy of your access. A Touch ID SSH key works differently: the private key is generated inside your Mac's Secure Enclave, it never leaves it, and every signature needs your fingerprint. Recent macOS versions can do this with two built-in tools, sc_auth and /usr/lib/ssh-keychain.dylib, without installing anything.

This guide covers the setup, how to make it survive a reboot, how to use it with GitHub and your own servers, and the part most write-ups skip: what you give up when a key can't be copied.

Quick Summary: What You'll Learn

What a Secure Enclave SSH key is and which Macs have one.
The three commands that create a Touch ID SSH key and load it into ssh-agent.
How to make it work after a reboot with ~/.ssh/config or SSH_SK_PROVIDER.
How it compares with Secretive and a YubiKey.
The tradeoffs: one key per Mac, no backup, and servers that need OpenSSH 8.2 or later.

How do you use Touch ID for an SSH key on macOS?

You create a non-exportable P-256 identity in the Secure Enclave with sc_auth, then tell OpenSSH to talk to it through Apple's security key provider, /usr/lib/ssh-keychain.dylib. OpenSSH treats the Secure Enclave like a FIDO security key, so the public key shows up as sk-ecdsa-sha2-nistp256@openssh.com, the same type a hardware key would give you.

The short version:

# 1. Create the identity (Touch ID prompt). Run once per Mac.
sc_auth create-ctk-identity -l ssh-key -k p-256-ne -t bio

# 2. Load it into ssh-agent. Press Enter at the PIN prompt.
ssh-add -K -S /usr/lib/ssh-keychain.dylib

# 3. Print the public key to paste into GitHub or authorized_keys.
ssh-add -L

After that, ssh and git over SSH trigger a Touch ID prompt whenever the key signs a login. The rest of this article explains each piece and the setup that doesn't need step 2 after every reboot.

A note on testing: we build termique on Linux and couldn't run the sc_auth steps on a Mac for this article. The macOS commands and outputs come from two public write-ups (linked in the sources) and Apple's man pages they cite. The OpenSSH side (flags, key type, server support) is checked against the OpenSSH manuals and tested on OpenSSH 9.6.

What is a Secure Enclave SSH key?

The Secure Enclave is a separate security subsystem inside Apple's chips. It has its own processor and protected memory, isolated from the main CPU, and it can generate and use keys that the operating system never sees in plain form. Apple lists it on all Macs with Apple silicon, Intel Macs with the T2 Security Chip, and the 2016 and 2017 MacBook Pro models with the T1 chip.

sc_auth is the macOS command for smart card and CryptoTokenKit identities. With the key type p-256-ne, it asks the Secure Enclave to generate a P-256 key pair where the private half is non-exportable (that's what -ne means). Signing happens inside the enclave. Your Mac asks for Touch ID, the enclave signs the login challenge, and only the signature comes out.

That gives you three things a key file can't:

No file to steal. There's no private key on disk to copy, back up by accident, or leak in a dotfiles repo.
A prompt per use. With -t bio, every signature needs a fingerprint, so malware that reaches your ssh-agent can't silently log in somewhere.
Nothing to forget to encrypt. There's no passphrase to skip, because there's no key file to protect with one.

It does not protect you from everything. If you approve a Touch ID prompt for a login you didn't start, that login goes through. And it doesn't stop someone who can get your enrolled finger onto the sensor, same as any other Touch ID action.

How do you create the identity with sc_auth?

sc_auth create-ctk-identity -l ssh-key -k p-256-ne -t bio

-l ssh-key is a free-form label so you can recognise it later.
-k p-256-ne is the key type. The write-ups report p-256, p-384, p-521, p-256-ne and p-384-ne as accepted values. Use p-256-ne: OpenSSH's security key types are ecdsa-sk (P-256) and ed25519-sk, so P-384 won't work for SSH, and the variants without -ne are exportable.
-t bio requires biometrics for each use. -t none still keeps the key inside the enclave but lets programs use it without a prompt. Pick none only if you'd rather trade the per-use check for fewer interruptions (frequent git fetch can get tiring).

Check that it exists, and see its SSH fingerprint:

sc_auth list-ctk-identities
sc_auth list-ctk-identities -t ssh

The second form prints the key hash as an SSH-style SHA256: fingerprint, which is what you'll compare against the server side later. To remove an identity, use its hash from the list:

sc_auth delete-ctk-identity -h <public-key-hash>

Run man sc_auth on your Mac before you start. If create-ctk-identity isn't in it, your macOS version doesn't have this feature. The original write-up describes it on macOS Tahoe, and later reports say it works on Sequoia too.

How do you load the Touch ID key into ssh-agent?

ssh-add -K -S /usr/lib/ssh-keychain.dylib

In the OpenSSH manual, -K means "load resident keys from a FIDO authenticator" and -S sets the provider library to use instead of the built-in USB support. Here the provider is Apple's ssh-keychain.dylib, which answers on behalf of the Secure Enclave. ssh-add will ask for a PIN because it assumes a USB security key; press Enter. You should see Resident identity added: ECDSA-SK SHA256:....

If you've used macOS for a while, ssh-add -K may look familiar for a different reason. Older Apple guides used it to store a key's passphrase in the macOS Keychain. Apple moved that behaviour to --apple-use-keychain. In this article, -K is the upstream OpenSSH flag for resident keys.

Two details that save confusion:

The agent remembers which provider loaded each key, so plain ssh host works afterwards without extra options.
ssh-agent only loads provider libraries from allowed paths, /usr/lib/* and /usr/local/lib/* by default. Use the system path as is; don't copy the dylib somewhere else.

ssh-add -L prints the public key. Use the line that starts with sk-ecdsa-sha2-nistp256@openssh.com. If the agent also holds other keys, ssh-add -l lists them with fingerprints so you can tell which is which (more on that in our ssh-agent forwarding post, which matters here: a forwarded agent hands remote hosts a way to ask for signatures).

How do you make the Touch ID key survive a reboot?

The agent forgets everything when it restarts, so the ssh-add step comes back after every reboot. There are two ways around that.

Option 1: write a key handle to disk with ssh-keygen -K

cd ~/.ssh
ssh-keygen -K -w /usr/lib/ssh-keychain.dylib -N ""

ssh-keygen -K downloads resident keys and writes the public and private key files to the current directory, which is why you cd ~/.ssh first. You get id_ecdsa_sk_rk and id_ecdsa_sk_rk.pub. The "private" file is only a reference to the credential in the Secure Enclave, not key material, which is why -N "" (no passphrase) is fine here. Copying it to another Mac gives that Mac nothing it can sign with.

Then point ssh at it in ~/.ssh/config:

Host *
    SecurityKeyProvider /usr/lib/ssh-keychain.dylib
    IdentityFile ~/.ssh/id_ecdsa_sk_rk

SecurityKeyProvider is a standard ssh_config option: the library ssh uses for FIDO-style keys instead of its built-in USB support. If you already keep a large config, put this in a narrower Host block for the servers that should use the Touch ID key (our ssh config organization post covers splitting it up).

If you created several identities with sc_auth, check that ssh-keygen -K wrote a file for each of them. One public report describes an older build that saved only one, fixed in a later macOS beta.

Option 2: set SSH_SK_PROVIDER for your shell

# in ~/.zprofile
export SSH_SK_PROVIDER=/usr/lib/ssh-keychain.dylib

ssh, ssh-add and ssh-keygen all read SSH_SK_PROVIDER, so after this, ssh-add -K and ssh-keygen -K work without the long path. It only applies to programs started from that shell, though. GUI apps that run ssh on their own won't see it, which is one reason to prefer the config file.

To label the key so you can tell it apart in lists later, change the comment on the handle file:

ssh-keygen -c -C "macbook-air secure enclave" -f ~/.ssh/id_ecdsa_sk_rk

Does a Secure Enclave key work with GitHub and your servers?

Yes, as long as the other end accepts security key types.

GitHub accepts sk-ecdsa-sha2-nistp256@openssh.com keys. Paste the ssh-add -L line into your SSH keys settings and test with ssh -T git@github.com. You'll get the Touch ID prompt before the greeting.
GitLab lists ECDSA_SK as supported and notes it needs OpenSSH 8.2 or later on both the client and the GitLab server.
Your own Linux servers: OpenSSH's sshd accepts sk-ecdsa-sha2-nistp256@openssh.com by default. On our OpenSSH 9.6 test box, sshd -T lists it in pubkeyacceptedalgorithms with no config change. Add the public key line to ~/.ssh/authorized_keys as usual.

To check you pasted the right key, compare fingerprints. On the server:

ssh-keygen -lf ~/.ssh/authorized_keys

A Secure Enclave key shows up as 256 SHA256:... (ECDSA-SK). That fingerprint should match the one from ssh-add -l or sc_auth list-ctk-identities -t ssh on your Mac.

Where it can fail: servers running OpenSSH older than 8.2, network appliances with their own SSH implementation, and hardened environments with a fixed list of approved algorithms that leaves out the sk- types. Check before you make it your only key for a box.

Secure Enclave via ssh-keychain.dylib vs Secretive vs a YubiKey

These solve the same problem in different ways, and each has a real strength.

Built-in (sc_auth + ssh-keychain.dylib): nothing to install, uses the standard OpenSSH agent and config. The downside is documentation: the provider interface isn't documented by Apple in any detail, and the original write-up notes there's no attestation to prove a key really lives in the enclave.
Secretive is an open-source macOS app built for exactly this: keys in the Secure Enclave, Touch ID or Apple Watch approval, and a notification each time a key is used. If you want a UI and access notifications, it's the more polished option, and it has been around longer than the built-in route. Install with brew install secretive. Its README is blunt about the same limit: keys can't be backed up or moved to a new Mac.
A YubiKey or other FIDO2 key (ssh-keygen -t ed25519-sk, see our ssh-keygen best practices) is portable. One key works on your Mac, a Linux desktop and a work laptop, and survives your Mac dying. It costs money, and you have to carry it.

A common pattern is a hardware key as the portable or break-glass key, and a Secure Enclave key for day-to-day use on the laptop.

What are the tradeoffs of a non-exportable SSH key?

The thing that makes this key safe is also what makes it awkward: it exists on one Mac and nowhere else.

One key per Mac. A new Mac means a new identity, and re-registering it on GitHub and every server. That's the one key per device model enforced by hardware, which is good practice, but you need a list of where each key is authorized.
No backup. If the Mac dies, is wiped, or the logic board is replaced, the key is gone. Before you remove other keys from a server, make sure you have a second way in: another key, a hardware key, or console access from your provider.
Exportable variants exist, with caveats. sc_auth can create exportable keys (p-256 without -ne) protected by the enclave, and export-ctk-identity can write them out. Public reports on moving them between Macs are mixed, and an exportable key gives up the main guarantee. If you want portability, a hardware key is the cleaner answer.
Prompts add up. With -t bio, every signature asks for Touch ID. Scripts and cron jobs that ssh as you will stop and wait. Use a separate, narrowly authorized key for automation.
Mac only. It doesn't help on your phone or a Linux box, and apps that don't support security key types can't use it.
Revocation is still your job. If the Mac is lost, remove its public key from every authorized_keys and Git host. Our key rotation post has a process for that.

Where does termique fit with a Touch ID SSH key?

It's a different tradeoff, and you may want both.

A Secure Enclave key is bound to one Mac on purpose. termique goes the other way for the keys you keep in it: you generate an ed25519 or rsa key, or import an existing OpenSSH or PEM private key, and the private key is encrypted on your device before it syncs, so the server only stores ciphertext. That's how the same key reaches your other devices, including iOS. termique's SSH keys docs list ed25519 and RSA generation and OpenSSH/PEM import; they don't mention security key (sk-) types, so treat a Touch ID key as something you use from Terminal and plain ssh, not from termique.

In practice that can look like this: a Touch ID key on your laptop for the access that matters most, like pushing to production repos or a bastion, and a synced key in termique for the everyday servers you reach from more than one device. termique also shows each key's SHA-256 fingerprint in Settings, so you can line it up with ssh-keygen -lf on the server the same way. Be precise about what's encrypted: credentials and private keys are end-to-end encrypted, while host names, groups and snippets sync as plain metadata. The details are on our security page.

FAQ

Can I use Touch ID for SSH on a Mac without installing anything?

On recent macOS versions, yes. sc_auth create-ctk-identity creates the key in the Secure Enclave and /usr/lib/ssh-keychain.dylib lets the built-in OpenSSH use it. Check man sc_auth for create-ctk-identity to confirm your version has it.

Can I export or back up a Secure Enclave SSH key?

Not a p-256-ne key. It's generated inside the enclave and can't leave it. Plan for that with a second key or a hardware key that can still get you in if the Mac is lost.

Why does ssh-add ask for a PIN?

ssh-add assumes a USB security key, which may have a PIN. The Secure Enclave uses Touch ID instead, so press Enter at the prompt.

Is a Secure Enclave key an Ed25519 key?

No. It's ECDSA on the P-256 curve, shown as sk-ecdsa-sha2-nistp256@openssh.com. It's widely supported, but older servers that predate OpenSSH 8.2 won't accept it.

Do I have to run ssh-add after every reboot?

Only if you load the key through the agent. Write a key handle with ssh-keygen -K and add SecurityKeyProvider and IdentityFile to ~/.ssh/config, and ssh picks it up on its own.

If you manage keys for more servers than you can keep in your head, try termique free: keys generated or imported once, encrypted before they sync, with fingerprints you can check against the server.

SSH Port Forwarding: -L, -R, -D Examples and Config (2026)

Rafi Bagaskara Halilintar — Fri, 30 Oct 2026 03:20:36 +0000

Your database listens on localhost:5432 on a server, which is exactly how it should be. Now you need to open it in a GUI client on your laptop, and the options look bad: open port 5432 in the firewall, install a VPN for one query, or copy a dump around. SSH port forwarding is the fourth option, and it's usually the right one. You already have an SSH connection to the server; port forwarding carries other TCP traffic through it.

This guide covers the three kinds of SSH port forwarding (local -L, remote -R, dynamic -D), how to keep tunnels in ~/.ssh/config so you stop retyping them, how to combine them with a jump host, and the failure modes that make a tunnel silently not work. Every command and error message below was run on OpenSSH 9.6 against a throwaway sshd on localhost while writing this.

Quick Summary: What You'll Learn

What SSH port forwarding is, and which of -L, -R and -D you need.
A local forward to reach a database or admin panel that only listens on the server.
A remote forward to expose a port from your machine on the server, and why it binds to loopback by default.
A SOCKS proxy with -D for reaching many internal hosts at once.
LocalForward, RemoteForward and ExitOnForwardFailure in ~/.ssh/config, including through a jump host.
The exact messages you see when a port is taken or the server forbids forwarding.

What is SSH port forwarding?

SSH port forwarding makes one end of an SSH connection listen on a TCP port and send whatever connects to it through the encrypted connection, where the other end opens a new connection to a destination you choose. The application on either side talks plain TCP and doesn't know SSH is involved.

There are three forms, and the letter tells you where the listening port lives:

Local forward, -L: the port opens on your machine (the client). Connections go to the server, and the server connects onward. Use it to reach something that only the server can reach.
Remote forward, -R: the port opens on the server. Connections come back to your machine, and your machine connects onward. Use it to let the server reach something only you can reach.
Dynamic forward, -D: the port opens on your machine as a SOCKS proxy. Each connection says where it wants to go, and the server connects there. Use it when you need many destinations behind the server, not one.

The flag everyone pairs with these is -N: "Do not execute a remote command. This is useful for just forwarding ports." Without it, you also get a shell, which is fine for one-off use but awkward for a tunnel you want to leave running.

How do I forward a remote port to my local machine with -L?

This is the "ssh port forwarding from remote to local" case: a service listens on the server's loopback interface, and you want it on a port on your laptop.

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

Read the argument as local_port:destination_host:destination_port. Your machine listens on 5433. When something connects to it, the connection is carried to db.example.com, and the server connects to localhost:5432. In a second terminal:

psql -h localhost -p 5433 -U app appdb

Two details catch people out.

localhost in the middle is resolved on the server, not on your laptop. The destination is looked up from the server's side. That's what makes this useful: you can also point it at a host only the server can see, for example a managed database on a private network:

ssh -N -L 5433:10.0.12.7:5432 deploy@bastion.example.com

The local port binds to loopback by default. In our test, -L 9000:localhost:8080 produced listeners on 127.0.0.1:9000 and [::1]:9000 only, so other machines on your network can't use your tunnel. The man page says the local port is bound according to GatewayPorts, which defaults to no. You can override it with a bind address (-L 0.0.0.0:5433:localhost:5432 or -g), but think twice: anyone who can reach your laptop then reaches the server's database.

Ports below 1024 on your side need root, so pick something like 5433, 8443 or 9000 instead of 443.

How do I forward multiple ports at once?

Repeat the flag. One SSH connection can carry as many forwards as you like:

ssh -N \
  -L 5433:localhost:5432 \
  -L 6380:localhost:6379 \
  -L 9090:localhost:9090 \
  deploy@app.example.com

That gives you Postgres, Redis and a Prometheus UI on three local ports over a single authenticated connection.

How does remote port forwarding (-R) work?

A remote forward is the mirror image. The server listens, and connections travel back to your machine:

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

Now anything on the server that connects to port 8080 reaches localhost:3000 on your laptop: a dev server, a webhook receiver you're debugging, a service you want a teammate on the box to try. In our test, a curl on the server side to the forwarded port returned the page served on the client.

Why can't anyone else reach my -R port?

By default, sshd binds remote forwards to the server's loopback address. The -R documentation is explicit: "By default, TCP listening sockets on the server will be bound to the loopback interface only," and specifying a remote bind address "will only succeed if the server's GatewayPorts option is enabled."

What "will only succeed" looks like in practice is worth knowing. We ran ssh -N -R 0.0.0.0:9201:localhost:8080 against an sshd with default settings. There was no error and no warning. The listener came up on 127.0.0.1:9201 and [::1]:9201 only. If you're wondering why your public URL doesn't work while the tunnel looks healthy, this is the first thing to check.

To let other hosts connect, the server needs GatewayPorts in sshd_config:

no (the default): remote forwards are available to the server itself only.
yes: remote forwards always bind to the wildcard address, reachable from anywhere the firewall allows.
clientspecified: the client picks the bind address, so -R 0.0.0.0:9201:... actually means 0.0.0.0.

Use clientspecified over yes if you need this at all, so a plain -R 8080:... stays private. A remote forward on a public interface is a hole into your laptop, so put a reverse proxy with auth in front of it, or keep it on loopback and let a proxy on the server reach it there.

If you leave out the destination (-R 1080), ssh acts as a SOCKS proxy for clients on the server side and connects out from your machine. That's niche, but it's in the man page and occasionally handy for giving a locked-down server temporary outbound access through your connection.

When should I use dynamic port forwarding (-D)?

A local forward maps one port to one destination. When you need a dozen internal dashboards behind the same server, a SOCKS proxy is simpler:

ssh -N -D 1080 deploy@bastion.example.com

Your machine now runs a SOCKS4/SOCKS5 server on port 1080. Point a browser profile or a tool at it, and each connection is opened from the server's side:

curl --socks5-hostname localhost:1080 http://grafana.internal:3000/

Use --socks5-hostname rather than --socks5 so the name is resolved on the server too. With --socks5, curl resolves grafana.internal locally, which fails for internal-only DNS names. In our test the SOCKS proxy returned the page from a service that only listened on the server's loopback.

The tradeoff: SOCKS only helps applications that speak SOCKS. Browsers and curl do; most database clients and CLIs don't, so for those a plain -L is still the answer.

How do I keep SSH port forwarding in my ssh config?

Retyping -L flags gets old fast. ~/.ssh/config has a directive for each kind of forward, and you can give a tunnel its own host alias:

Host db-tunnel
  HostName db.example.com
  User deploy
  LocalForward 5433 localhost:5432
  LocalForward 6380 localhost:6379
  ExitOnForwardFailure yes
  SessionType none

Now ssh db-tunnel opens both forwards and nothing else. The directives map to the flags like this:

LocalForward 5433 localhost:5432 is -L 5433:localhost:5432. Note the space between the listen port and the destination instead of a colon.
RemoteForward 8080 localhost:3000 is -R 8080:localhost:3000.
DynamicForward 1080 is -D 1080.
SessionType none is the config form of -N ("same as the -N option").
ExitOnForwardFailure yes makes ssh quit if it can't set up a forward. More on why that matters below.

You can confirm what ssh will actually use with ssh -G, which prints the resolved config without connecting:

ssh -G db-tunnel | grep -iE 'localforward|exitonforward|sessiontype'

On our test host that printed localforward 5433 [localhost]:5432, exitonforwardfailure yes and sessiontype none.

Keep a tunnel alias separate from the alias you use for a shell on the same box. That way ssh db gives you a prompt and ssh db-tunnel gives you ports, and neither surprises you. If your config is getting long, our guide to organizing your ssh config covers splitting it with Include and ordering Host blocks so the specific ones win.

How do I run a tunnel in the background?

Add -f, which sends ssh to the background after authentication:

ssh -f -N -o ExitOnForwardFailure=yes -L 5433:localhost:5432 deploy@db.example.com

Pairing -f with ExitOnForwardFailure is the documented way to make it reliable: with that option set, "a client started with -f will wait for all remote port forwards to be successfully established before placing itself in the background." In other words, a backgrounded tunnel that couldn't bind its ports exits with an error instead of sitting there doing nothing. In our test, the command above returned 0 and the forwarded port answered right away. Stop the tunnel later with kill on that ssh process, or use connection multiplexing (next section) so you can control it by name.

Can I add a forward to a connection that's already open?

Yes, if you use connection multiplexing. With a control socket (ControlMaster and ControlPath in your config), ssh -O sends commands to the running master connection:

ssh -O forward -L 9500:localhost:8080 db-tunnel
ssh -O cancel  -L 9500:localhost:8080 db-tunnel

In our test, -O forward added the port to a live tunnel without re-authenticating, the page was reachable on 9500, and after -O cancel the same curl got "connection refused". That's handy when you realize mid-debugging that you need one more port. In an interactive session without multiplexing, the ~C escape opens a command line where you can add a forward too, but current OpenSSH disables it by default: you need EnableEscapeCommandline yes in your config first.

How do I forward a port through a jump host?

Combine the forward with ProxyJump. The jump host carries the SSH connection; the forward is set up on the final host:

Host bastion
  HostName bastion.example.com
  User deploy

Host app-db
  HostName 10.0.12.20
  User deploy
  ProxyJump bastion
  LocalForward 5433 localhost:5432
  SessionType none

ssh app-db now connects through the bastion to the private host and gives you its Postgres on local port 5433. On the command line, the same thing is:

ssh -N -J bastion -L 5433:localhost:5432 app-db

Both versions worked in our test. One gotcha from the man page: options given on the command line generally apply to the destination, not the jump host, so put the jump host's user, key and port in its own Host block rather than in -o flags. Our bastion host and ProxyJump guide covers the bastion side in detail.

There's a second way to do this: forward from the bastion to the private host directly (ssh -N -L 5433:10.0.12.20:5432 bastion). That only needs SSH access to the bastion, but the last hop from the bastion to the database travels unencrypted inside your network, and the database sees the bastion as the client. ProxyJump keeps SSH end to end.

Why is my SSH port forwarding not working?

Most broken tunnels fall into one of these, and the messages are specific enough to tell them apart.

"Address already in use"

Something on your machine already listens on the local port, often a previous tunnel you forgot about. With an explicit bind address, ssh printed:

bind [127.0.0.1]:9100: Address already in use
channel_setup_fwd_listener_tcpip: cannot listen to port: 9100
Could not request local forwarding.

Here's the trap: without ExitOnForwardFailure, ssh prints that and keeps running. You have a connected session and no tunnel. With ExitOnForwardFailure yes, the same command exited with status 255, which is what you want in scripts. Find the old listener with ss -ltnp | grep 9100 (Linux) or lsof -iTCP:9100 -sTCP:LISTEN (macOS) and stop it, or pick another port.

One subtlety we hit while testing: with no bind address (-L 9100:...), ssh tries both 127.0.0.1 and ::1. When only the IPv4 side was taken, the IPv6 listener still came up, so ssh didn't count it as a failure even with ExitOnForwardFailure yes. Clients that connect to 127.0.0.1 still hit the other program. If you see the bind warning, don't trust the tunnel until you've checked which process owns the port.

"administratively prohibited: open failed"

The server refuses forwarding. With AllowTcpForwarding no in sshd_config, the tunnel connected fine, and the error only appeared when something used the port:

channel 2: open failed: administratively prohibited: open failed

The server log recorded refused local port forward with the target host and port. A remote forward against the same server failed up front instead: Error: remote port forwarding failed for listen port 9601. AllowTcpForwarding can also be local or remote to allow only one direction, and PermitOpen / PermitListen restrict which destinations and listen ports are allowed, so a forward to one port can work while another is refused. If it's not your server, ask the admin; don't route around the policy.

For admins, the sshd_config man page adds an honest caveat: "disabling TCP forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders." Turning it off is a policy signal and a speed bump, not a wall. Agent forwarding is a separate setting with its own risks; see SSH agent forwarding security risks.

The tunnel is up but the destination refuses

If your client's connection closes immediately and the ssh window prints this, ssh did its part and the server couldn't reach the destination:

channel 2: open failed: connect failed: Connection refused

Check that the service listens where you pointed it (ss -ltn on the server), and remember the destination is resolved from the server: localhost there is the server itself, and a service bound to a Docker bridge or a private IP won't answer on localhost. ExitOnForwardFailure doesn't cover this case; the man page notes it "does not apply to connections made over port forwardings."

The tunnel dies when idle

A tunnel that carries no traffic looks idle to NAT gateways and firewalls, which drop idle connections. Set ServerAliveInterval on the client so ssh sends keepalives, or use autossh if the tunnel must come back on its own.

Is SSH port forwarding secure?

The traffic between your machine and the SSH server is encrypted and authenticated like any SSH session, so a local forward to a database is a reasonable replacement for exposing the database port. The risks come from what you open on either end:

A forward bound to 0.0.0.0 (via -g, GatewayPorts, or an explicit bind address) is reachable by anyone who can reach that interface. Keep forwards on loopback unless you mean otherwise.
A remote forward with GatewayPorts yes exposes a service running on your laptop to the server's network.
On a multi-user server, any local user can connect to a loopback port you forwarded there.
Forwarding is allowed by default in OpenSSH. If your hardening checklist doesn't mention it, decide on purpose; our complete guide to SSH security covers where it fits.

Where termique fits

If you jump between a few servers every day, the tunnels pile up in your shell history. termique lists port forwarding as part of its Free plan, alongside SSH sessions, SFTP and snippets (see pricing). Hosts and groups sync across your devices, and credentials and private keys sync end-to-end encrypted, so the keys behind your tunnels aren't stored in plaintext on our servers. The ssh commands in this guide stay useful either way: they're what you reach for on a box where nothing is installed.

termique is a free, native SSH manager we build, with end-to-end encrypted credentials.

FAQ

What is the difference between -L and -R in SSH?

-L opens the listening port on your machine and connects onward from the server. -R opens the listening port on the server and connects onward from your machine. Ask "where does the port I connect to live?" and that's your answer: local means -L, remote means -R.

What does -N do in ssh port forwarding?

It tells ssh not to run a remote command or shell, so the connection exists only to carry your forwards. In ~/.ssh/config the same setting is SessionType none.

How do I set up SSH port forwarding in the ssh config file?

Use LocalForward 5433 localhost:5432, RemoteForward 8080 localhost:3000 or DynamicForward 1080 inside a Host block. Add ExitOnForwardFailure yes so ssh exits instead of running without the tunnel, and check the result with ssh -G <host>.

Can I forward multiple ports over one SSH connection?

Yes. Repeat -L (or LocalForward) once per port. All forwards share the one authenticated connection.

Why does my remote forward only listen on 127.0.0.1?

Because the server's GatewayPorts setting defaults to no, which binds remote forwards to loopback even if you ask for 0.0.0.0. Set GatewayPorts clientspecified in sshd_config if other hosts must reach it, and protect what you expose.

Try termique

Tunnels are one part of working across servers. termique keeps the rest in one place: your host list on every device, end-to-end encrypted credentials, SFTP and saved snippets. Download termique and add your first hosts.

Post-Quantum SSH Warning: What It Means, How to Fix (2026)

Rafi Bagaskara Halilintar — Thu, 29 Oct 2026 03:20:46 +0000

Since OpenSSH 10.1, ssh prints a three-line warning when a connection falls back to a key exchange that a future quantum computer could break. If you just saw it for the first time, nothing is broken and nobody is attacking you. The post quantum ssh warning means one thing: this session's encryption keys were agreed with classical cryptography only, so someone who records the traffic today could, in principle, decrypt it years from now.

This guide shows what the warning means, how to check which key exchange your sessions actually use, and how to fix it on the server, on the client, or both. Every command below was run against a local OpenSSH 9.6 server and against github.com, gitlab.com and bitbucket.org on October 26, 2026.

Quick Summary: What You'll Learn

What "connection is not using a post-quantum key exchange algorithm" means and why OpenSSH added it.
One command that shows which key exchange a session negotiated, and one that shows what the server offers.
Why the fix is sometimes on your laptop, not the server (GitLab and Bitbucket are a live example).
How to fix KexAlgorithms on a server without locking yourself out.
How to silence the warning for one host without breaking older ssh clients.

What does "connection is not using a post-quantum key exchange algorithm" mean?

This is the exact warning, as published by the OpenSSH project:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html

It means your client and the server could not agree on either of the two post-quantum key exchange algorithms OpenSSH supports, mlkem768x25519-sha256 or sntrup761x25519-sha512, and fell back to a classical one such as curve25519-sha256 or an ecdh-sha2-nistp* curve.

The connection still works, and it's still encrypted with strong ciphers. What changes is the threat model. The key exchange decides the session keys, and if an attacker can break the key exchange, they can decrypt the whole recorded session. Classical Diffie-Hellman and elliptic-curve exchanges are the kind of math a large enough quantum computer is expected to solve. Nobody has built one that can do it yet, but traffic captured now can be stored and decrypted later. That's the "store now, decrypt later" attack the warning names.

The warning exists to push the long tail of servers to upgrade. OpenSSH has offered a post-quantum key exchange by default since 9.0 (April 2022) and switched the default to mlkem768x25519-sha256 in 10.0 (April 2025). Most current OpenSSH pairs already negotiate a post-quantum algorithm without anyone touching a config file.

Which OpenSSH versions support post-quantum key exchange?

The timeline, from the OpenSSH release notes:

OpenSSH 9.0 (2022): sntrup761x25519-sha512@openssh.com (Streamlined NTRU Prime + X25519) becomes the default key exchange.
OpenSSH 9.9 (2024): adds mlkem768x25519-sha256 (ML-KEM, standardized by NIST as FIPS 203, + X25519) and the unsuffixed name sntrup761x25519-sha512.
OpenSSH 10.0 (April 2025): mlkem768x25519-sha256 becomes the default.
OpenSSH 10.1 (October 2025): the client warns on non-post-quantum key exchange. A new WarnWeakCrypto option in ssh_config controls it.
OpenSSH 10.6 (October 2026): sshd_config gets WarnWeakCrypto too, on by default, so servers log clients that use a non-post-quantum key exchange.

Both algorithms are hybrids. Each combines a post-quantum scheme with X25519, so even if the post-quantum half turned out to be broken, the session is no weaker than plain curve25519-sha256. That's why there's no real downside to preferring them.

One detail that matters in practice: a client and a server both need to support the same post-quantum algorithm. An OpenSSH 9.6 client, for example, only knows sntrup761x25519-sha512@openssh.com. That's the version on Ubuntu 24.04, which is what we tested from:

$ ssh -V
OpenSSH_9.6p1 Ubuntu-3ubuntu13.20, OpenSSL 3.0.13 30 Jan 2024
$ ssh -Q kex | grep -E 'mlkem|sntrup'
sntrup761x25519-sha512@openssh.com

How do you check which key exchange an SSH session uses?

Run the connection in verbose mode and grep for the negotiated algorithm. This is the same check GitHub gives in its announcement:

ssh -v git@github.com exit 2>&1 | grep 'kex: algorithm:'

The output looks like this:

debug1: kex: algorithm: sntrup761x25519-sha512@openssh.com

If you see mlkem768x25519-sha256 or sntrup761x25519-sha512 (with or without @openssh.com), the session is post-quantum. If you see curve25519-sha256, any ecdh-sha2-* or any diffie-hellman-*, it isn't.

To see what the server is willing to offer, which is what you need when deciding who has to change, go one level more verbose and read the server's proposal:

ssh -vvv user@host exit 2>&1 | grep -A2 'peer server KEXINIT' | grep 'KEX algorithms'

Two more checks that don't need a connection:

ssh -Q kex lists every key exchange your client binary supports.
ssh -G host | grep -i kexalgorithms prints the list your client will actually offer to that host after reading ~/.ssh/config.
On the server, sudo sshd -T | grep -i kexalgorithms prints the effective server list after all includes and Match blocks.

Why do some Git hosts still negotiate classical key exchange?

Here's what we got on October 26, 2026, connecting from the OpenSSH 9.6 client above:

github.com offers mlkem768x25519-sha256, sntrup761x25519-sha512 and the @openssh.com name. Negotiated: sntrup761x25519-sha512@openssh.com. Post-quantum.
gitlab.com offers mlkem768x25519-sha256 but no sntrup761. Negotiated: curve25519-sha256. Classical.
bitbucket.org offers mlkem768x25519-sha256 but no sntrup761. Negotiated: curve25519-sha256. Classical.

GitLab and Bitbucket aren't the problem here. Both offer ML-KEM. Our 9.6 client doesn't speak ML-KEM, so the only overlap left is classical. A client on OpenSSH 9.9 or newer would get a post-quantum key exchange with all three, and 10.0 or newer prefers mlkem768x25519-sha256.

This is the part the warning text can mislead you on. It says "the server may need to be upgraded", and it's printed by a client that is new enough to know ML-KEM, so for that client the server usually is the gap. But if you have older clients around (CI runners on an LTS image, a jump host nobody has upgraded, a vendor appliance), they will quietly negotiate classical key exchange with servers that are fully post-quantum ready, and they'll never warn you, because the warning only exists from 10.1 on.

GitHub's own announcement has one more exception worth knowing: GitHub Enterprise Cloud with data residency in the US region doesn't offer sntrup761, because only FIPS-approved cryptography may be used there and that algorithm isn't FIPS-approved. If you're in a FIPS environment, expect your options to differ.

How do you fix the warning on a server you control?

There are two causes, and they need different fixes.

1. The server's OpenSSH is too old. Anything before 9.0 has no post-quantum key exchange at all. Check the version from the outside with ssh -v user@host 2>&1 | grep 'remote software version', or on the box with sshd -V (OpenSSH 9.2 and later) or your package manager. Distribution packages often carry an older upstream version number with security fixes backported, so read the number as "which features exist", not "is it vulnerable". If the version is below 9.0, the fix is a distribution upgrade or a newer OpenSSH package, not a config change.

2. The server is new enough, but KexAlgorithms strips the post-quantum algorithms. This is common on servers hardened with an older guide that pinned an explicit list. We reproduced it on OpenSSH 9.6 with one line:

KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org

With that line, every client negotiates curve25519-sha256, even ones that support post-quantum algorithms. Find it:

sudo sshd -T | grep -i kexalgorithms
sudo grep -rni kexalgorithms /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

The cleanest fix is to delete the pinned line and let the OpenSSH default apply, which already puts the post-quantum algorithms first. If you must keep an explicit list, put a post-quantum algorithm in it. On 9.6 that means:

KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org

On 9.9 or newer, add mlkem768x25519-sha256 (and sntrup761x25519-sha512) as well. Only list algorithms your ssh -Q kex output on the server shows; an unknown name is a config error.

Then apply it the safe way. Test the config, reload, and keep your current session open while you check from a second terminal:

sudo sshd -t && sudo systemctl reload ssh   # the unit is "sshd" on RHEL-family systems
# from a NEW terminal, keep the old session open:
ssh -v user@host exit 2>&1 | grep 'kex: algorithm:'

sshd -t matters more than usual here. If a config line is wrong, a restart can leave sshd not running, and the open session you kept is your way back in.

If your server sits behind a bastion, remember each hop is its own SSH connection with its own key exchange. With ProxyJump, check both the jump host and the target; our bastion host and ProxyJump guide covers how the hops connect.

How do you fix it from the client side?

Upgrade the client. If your client is older than 9.9, you can't negotiate ML-KEM, and some servers (like GitLab and Bitbucket in our test) only offer ML-KEM as their post-quantum option. On a laptop that usually means a newer OS release or a newer OpenSSH package. On CI runners, it means a newer base image.

Check your own ~/.ssh/config. A pinned KexAlgorithms line on the client has the same effect as one on the server. ssh -G host | grep -i kexalgorithms shows what you'll offer.

Require post-quantum for hosts that matter. You can make the client refuse classical key exchange for a specific host, instead of just warning about it:

Host git.internal.example.com
    KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com

Use only names your ssh -Q kex knows (on 9.6, only the @openssh.com sntrup name). If the server can't match, the connection fails instead of falling back. This is the error we got from a 9.6 client forcing sntrup against a server limited to curve25519:

Unable to negotiate with 127.0.0.1 port 2299: no matching key exchange method found. Their offer: curve25519-sha256,curve25519-sha256@libssh.org,ext-info-s,kex-strict-s-v00@openssh.com

That's a loud failure by design. Use it for hosts where you've confirmed post-quantum support, not as a global default. If you keep a large config, our ssh config organization guide shows how to group these per-host rules so they don't sprawl.

How do you silence the post-quantum warning safely?

Sometimes you can't fix the other end: a network switch, an embedded device, a vendor appliance with its own SSH server. OpenSSH recommends turning the warning off selectively, not globally:

Match host unsafe.example.com
    WarnWeakCrypto no-pq-kex

no-pq-kex disables only the post-quantum warning. WarnWeakCrypto no disables all of these warnings, including any OpenSSH adds later, so avoid it.

There's a trap here if you share one ~/.ssh/config across machines, or check it into a dotfiles repo. Clients older than 10.1 don't know WarnWeakCrypto and refuse to run. On OpenSSH 9.6:

config: line 2: Bad configuration option: warnweakcrypto
config: terminating, 1 bad configuration options

That breaks every ssh command on that machine, not just the one host. Put this at the very top of the file, before any Host or Match block:

IgnoreUnknown WarnWeakCrypto

IgnoreUnknown only applies to options that appear after it, which is why it has to come first.

The same trap exists on servers, with no IgnoreUnknown escape hatch. WarnWeakCrypto in sshd_config is new in 10.6. On our 9.6 server, sshd -t rejected it with Bad configuration option: WarnWeakCrypto. Don't push it to a fleet of mixed versions through one shared config template.

Do you also need post-quantum SSH keys?

Not urgently. The key exchange protects the secrecy of the traffic, and that's what "store now, decrypt later" targets. Your SSH keys (user keys and host keys) are used for signatures, which prove who you are at connection time. A future quantum computer could forge signatures for keys that are still trusted then, but it can't use that to decrypt sessions you recorded in the past.

OpenSSH has started on post-quantum signatures anyway. OpenSSH 10.6 enabled the hybrid ssh-mldsa44-ed25519 algorithm, and keys generated with the earlier experimental version have to be regenerated. Server and client support is still thin, so for most people the right move today is to keep using Ed25519 and plan to rotate when your servers and Git hosts accept the new type. Our ssh-keygen best practices guide covers where mldsa44-ed25519 stands and what to generate now.

Order of work, if you're auditing a fleet: key exchange first (it protects traffic recorded today), signatures later.

Where does termique fit?

A GUI SSH client uses its own SSH library, so your ~/.ssh/config KexAlgorithms and WarnWeakCrypto lines don't apply to it. That's true for termique too. termique's docs don't currently list which key exchange algorithms its connections negotiate, so for a connection where post-quantum key exchange is a requirement, verify it with ssh -v from a terminal against the same host.

What termique does handle is the part around the session. It saves each host's key on first connect and blocks the connection, before sending any credential, if a host later presents a different key, showing the new key's SHA256: fingerprint so you can compare it with the server. Our host key verification guide explains why that check matters. Your SSH passwords and private keys are end-to-end encrypted before they sync between devices, so the sync server only stores ciphertext; host names, groups and snippets sync as plain metadata. The details are on our security page.

For the wider checklist (key types, password auth, hardening, auditing), see the SSH security best practices guide.

FAQ

Is the post-quantum SSH warning an attack?

No. It means your session negotiated a classical key exchange. The connection is still encrypted and authenticated. The risk is long term: recorded traffic could be decrypted once a large enough quantum computer exists.

How do I check if my SSH connection is post-quantum?

Run ssh -v user@host exit 2>&1 | grep 'kex: algorithm:'. If it shows mlkem768x25519-sha256 or sntrup761x25519-sha512, it's post-quantum. Anything else is classical.

Does GitHub support post-quantum SSH?

Yes. GitHub added sntrup761x25519-sha512 on September 17, 2025, and in our October 2026 test github.com also offered mlkem768x25519-sha256. GitHub Enterprise Cloud with US data residency is the exception, because only FIPS-approved algorithms are used there.

How do I turn off the post-quantum warning for one server?

Add Match host that.server.example with WarnWeakCrypto no-pq-kex under it, and put IgnoreUnknown WarnWeakCrypto at the top of your config so clients older than 10.1 don't fail on the unknown option.

Which is better, mlkem768x25519-sha256 or sntrup761x25519-sha512?

Both are hybrids with X25519 and both protect against "store now, decrypt later". OpenSSH made mlkem768x25519-sha256 the default in 10.0; it's NIST-standardized and faster. Use whichever both ends support; with a recent OpenSSH you don't have to choose.

If you juggle more servers than you can track by hand, try termique free: hosts in one place, host keys checked before credentials are sent, and credentials encrypted before they sync.

How to Use ssh-agent on Linux, macOS and Windows (2026)

Rafi Bagaskara Halilintar — Mon, 26 Oct 2026 03:20:48 +0000

You gave your SSH key a passphrase, which is the right call. Now you type it forty times a day, or you quietly removed it last week because it got in the way. ssh-agent exists so you don't have to pick between those two. It holds your decrypted key in memory, signs authentication requests for ssh, git and scp, and never hands the key itself to anyone.

This guide covers how to use ssh-agent on each platform, the handful of ssh-add flags worth knowing, the two errors people actually hit, and the settings that keep a running agent from becoming a liability.

Quick Summary: What You'll Learn

How to start ssh-agent and add a key on Linux, macOS and Windows 11.
How to list, test and remove keys with ssh-add.
How to fix "unable to start ssh-agent service, error :1058" on Windows.
Why an agent full of keys causes "Too many authentication failures", and the two-line fix.
ssh-agent best practices: key lifetimes, confirmation, destination constraints and locking.

How do you use ssh-agent?

Three steps, the same on every platform:

Make sure an agent is running and that your shell knows where its socket is (the SSH_AUTH_SOCK environment variable on Linux and macOS, a Windows service on Windows).
Add your key with ssh-add. You type the passphrase once.
Connect as usual. ssh finds the agent through SSH_AUTH_SOCK and asks it to sign the login challenge. The private key never leaves the agent process.

On Linux, in a shell where no agent is running yet:

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

ssh-agent -s prints Bourne-shell commands that set SSH_AUTH_SOCK and SSH_AGENT_PID; eval runs them in your current shell. Use -c instead of -s if you live in csh or tcsh. ssh-add -l should print one line with the key's SHA256 fingerprint.

If you run ssh-add without a file name, it tries the default identities: ~/.ssh/id_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519, ~/.ssh/id_ed25519_sk, and on current OpenSSH also ~/.ssh/id_mldsa44_ed25519.

What does ssh-agent actually protect?

It keeps the decrypted key out of files and out of the processes that use it. Your passphrase-protected key stays encrypted on disk; only the agent holds the plaintext version, in memory. Clients talk to it over a Unix socket that only your user can open.

What it does not protect against is someone who can open that socket. The ssh-agent man page is blunt about it: the socket "is accessible only to the current user, but is easily abused by root or another instance of the same user." Anyone who can reach the socket can't copy your key, but they can use it to log in wherever the key works. Keep that in mind for the best-practice section below.

How do you start ssh-agent automatically on Linux?

Most desktop sessions (GNOME, KDE and others) already start an agent or an agent-compatible keyring at login. Check before adding another one:

echo "$SSH_AUTH_SOCK"
ssh-add -l

ssh-add exits with status 2 when it can't reach an agent at all, and 1 when the agent is running but holds no keys (it prints "The agent has no identities."). That difference is useful in scripts.

On a server or a minimal desktop with no agent, running eval "$(ssh-agent -s)" in every new terminal gives you one agent per shell, each with its own keys. A cleaner pattern is one agent per login on a fixed socket path, reused by every shell:

# in ~/.bashrc or ~/.zshrc
export SSH_AUTH_SOCK="$HOME/.ssh/agent.sock"
ssh-add -l >/dev/null 2>&1
if [ $? -eq 2 ]; then
  rm -f "$SSH_AUTH_SOCK"
  eval "$(ssh-agent -s -a "$SSH_AUTH_SOCK" -t 8h)" >/dev/null
fi

-a binds the agent to a socket path you choose, so every shell finds the same agent. The rm -f clears a stale socket left over from a crash, because ssh-agent won't bind to a path that already exists. -t 8h sets a default lifetime for every key added to this agent; more on that below.

Where does the socket live if you don't pick one? Recent OpenSSH releases create it under ~/.ssh/agent/ with a random s.* name. Older releases, which many distributions still ship, use a random directory under /tmp instead. Either way, SSH_AUTH_SOCK tells you the real path.

How do you use ssh-agent on macOS?

macOS starts an agent for your login session through launchd, so SSH_AUTH_SOCK is usually set already and you skip the eval step. Apple's build of ssh-add adds one option the upstream tool doesn't have: it can store your key's passphrase in the macOS Keychain.

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

To have keys loaded on first use instead of by hand, add this to ~/.ssh/config:

Host *
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/id_ed25519

Two things to know:

UseKeychain only exists in Apple's OpenSSH. If you also use Homebrew's ssh, or share this config file with Linux machines, add IgnoreUnknown UseKeychain above it so other builds don't fail with "Bad configuration option: usekeychain".
Before macOS Monterey (12.0), the flags were -K and -A instead of --apple-use-keychain and --apple-load-keychain. Old blog posts that tell you to run ssh-add -K are describing that older syntax.

How do you use ssh-agent on Windows 11?

Windows ships OpenSSH as a system component, and its agent runs as a Windows service called ssh-agent. Microsoft's docs note that the service is disabled by default. Enable and start it from an elevated PowerShell:

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

The last line should show Running. Then, from a normal (non-admin) PowerShell, add your key:

ssh-add $env:USERPROFILE\.ssh\id_ed25519
ssh-add -l

Unlike the Unix agent, the Windows service stores added keys under your Windows account, so they are still there after a reboot. Microsoft's guide goes as far as suggesting you back up the key file and delete it locally once it's in the agent. If you do that, make sure the backup really exists first: the agent will not give the private key back to you.

How do you fix "unable to start ssh-agent service, error :1058"?

Error 1058 is Windows saying the service can't be started because it is disabled. That's the default state of ssh-agent, so this error almost always means nobody ran the Set-Service line above. Open PowerShell as administrator, run:

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

and try ssh-add again. Use -StartupType Manual instead if you'd rather start the service yourself each time.

Why does Git on Windows keep asking for my passphrase?

Git for Windows can bring its own ssh.exe (from its MSYS2 environment). That binary doesn't talk to the Windows ssh-agent service, so the key you added in PowerShell is invisible to git push. Point Git at the system OpenSSH client:

git config --global core.sshCommand "C:/Windows/System32/OpenSSH/ssh.exe"

Or reinstall Git for Windows and pick the "Use external OpenSSH" option.

How do you list, test and remove keys with ssh-add?

The day-to-day flags, all from the ssh-add man page:

ssh-add -l lists fingerprints of every key the agent holds. ssh-add -L prints the full public keys instead, handy for pasting into authorized_keys.
ssh-add -T ~/.ssh/id_ed25519.pub tests whether the agent can actually sign with the private key behind that public key.
ssh-add -d ~/.ssh/id_ed25519 removes one key. It wants the public key file; if you pass the private key path, it appends .pub and tries again.
ssh-add -D removes every key. Good habit at the end of the day or before you hand your laptop to someone.
ssh-add -x locks the agent with a password, ssh-add -X unlocks it. While locked, the keys stay loaded but can't be used.
ssh-add -v (up to -vvv) prints debug output when something doesn't load.

ssh-add also refuses to load a key file that other users can read. If it complains about permissions, chmod 600 ~/.ssh/id_ed25519 fixes it.

Why does ssh-agent cause "Too many authentication failures"?

When ssh connects, it offers the server every key the agent holds, one after another, before it gets to the one you meant. Each rejected key counts as a failed attempt. The server's MaxAuthTries defaults to 6, so once six keys that are wrong for this server have been offered, you get disconnected with "Too many authentication failures" before the right key is ever tried. With a handful of project keys loaded, that happens sooner than you'd think.

The fix is to tell ssh which key belongs to which host, and to stop it from offering the rest:

Host prod-db
  HostName 10.0.4.12
  User deploy
  IdentityFile ~/.ssh/id_ed25519_prod
  IdentitiesOnly yes

With IdentitiesOnly yes, ssh only uses the identity files named in the config or on the command line, even if the agent offers more. The agent still does the signing, so you keep the no-retyping benefit. Our post on managing multiple SSH keys across devices has a naming scheme that makes these blocks easier to maintain, and ssh config file organization covers how to keep the file readable once it grows.

What are ssh-agent best practices in 2026?

An agent that holds every key forever, for every host, is convenient and a decent target. These settings cut the risk without bringing back the passphrase prompts.

Give keys a lifetime

By default a key stays in the agent until the agent exits. Set a limit, either for the whole agent or per key:

ssh-agent -s -t 8h        # default lifetime for every key added
ssh-add -t 1h ~/.ssh/id_ed25519_prod   # this key only, overrides the default

Times use the sshd_config format: plain seconds, or units like 30m, 8h, 1h30m. The same works from ~/.ssh/config, which is the least effort option:

Host *
  AddKeysToAgent 4h

AddKeysToAgent accepts no (the default), yes, ask, confirm (optionally followed by a time), or a time interval on its own. With a time interval, a key is added the first time you use it and removed after that interval.

Confirm each use for your most sensitive key

ssh-add -c ~/.ssh/id_ed25519_prod

With -c, the agent asks for confirmation through an ssh-askpass program every time the key is used. AddKeysToAgent confirm does the same from the config file. This needs a working askpass program on the machine running the agent, which most Linux desktops have and minimal servers usually don't. It's the strongest guard if you ever forward the agent, because a hijacked socket can't use the key without you clicking yes.

Restrict where a key can be used

Since OpenSSH 8.9, ssh-add -h attaches destination constraints to a key:

ssh-add -h git@github.com ~/.ssh/id_ed25519_github

That key can now only be used from this machine to github.com as user git. Hosts are identified by their host keys from your known_hosts files, so a typo-squatted or spoofed host doesn't match. Constraints also apply across forwarded agents, as long as each hop's client and server support them.

Don't forward the agent by default

ForwardAgent is no by default for good reason: anyone with root on the remote host can use your forwarded agent to authenticate as you while you're connected. Use ProxyJump to reach hosts behind a bastion instead. Our post on ssh agent forwarding security risks walks through the attack and the alternatives.

Keep a passphrase on the key file anyway

The agent is the reason a passphrase stops being annoying, not a reason to drop it. If the laptop is stolen while powered off, the agent is empty and the key on disk is still encrypted. ssh-keygen best practices for 2026 covers the key type and -a rounds to pick when you generate it. If an existing key keeps rejecting its passphrase, see ssh key passphrase not working.

Clear it when you step away

ssh-add -D before you leave, or ssh-add -x to lock without unloading. On Linux you can also send the agent SIGUSR1, which deletes all loaded keys.

Where does termique fit?

ssh-agent solves the "type the passphrase once" problem for command-line tools. termique, the SSH client we build, takes a different route for the keys you store in it.

Keys live in an encrypted vault. Private keys you generate or import in termique are encrypted with a data key that is unlocked by your master password, and only ciphertext is stored or synced. Details are on the security page.
One key per host, by design. When you add a host, you set the auth type to key and pick which key it uses. That's the same idea as IdentitiesOnly yes: no client offering every key to every server.
Locking clears the data key from memory. Locking the app drops it from memory until you unlock again, which is the same habit as ssh-add -D at the end of the day.
Passphrase-protected keys can be imported, so you don't have to strip the passphrase to move a key in.

termique doesn't replace ssh-agent for your terminal, git or CI. Keep the agent setup above for those, and use termique for interactive sessions across your machines.

FAQ

How do I check if ssh-agent is running?

Run ssh-add -l. Exit status 2 (with a "Could not open a connection to your authentication agent" message) means no agent is reachable from this shell. Exit status 1 with "The agent has no identities." means it's running but empty. On Windows, Get-Service ssh-agent shows whether the service is running.

How do I list the keys in ssh-agent?

ssh-add -l prints fingerprints; ssh-add -L prints the full public keys.

How do I remove a key from ssh-agent?

ssh-add -d path/to/key.pub removes one key, ssh-add -D removes all of them.

Is it safe to leave keys in ssh-agent?

It's reasonably safe on a single-user machine you control, and much safer with a lifetime (-t or AddKeysToAgent 4h). The risk is anyone who can reach the agent socket, which includes root on that machine and root on any host you forward the agent to.

Why does ssh-agent forget my keys after a reboot on Linux but not on Windows?

The OpenSSH agent on Linux and macOS keeps keys only in memory, so they're gone when it exits. The Windows ssh-agent service stores added keys under your Windows account, so they persist until you remove them with ssh-add -d or ssh-add -D.

Try termique free

If you juggle keys across several machines and want one key per host without maintaining the config by hand, download termique and import the keys you already use. Keep ssh-agent running for your terminal and Git; the two work side by side.

PHP2Shell: Find and Patch Every PHP Server You Run (2026)

Rafi Bagaskara Halilintar — Thu, 22 Oct 2026 19:13:23 +0000

On October 21, 2026, the PHP project shipped emergency releases for PHP2Shell, two critical bugs in the PHP engine itself, tracked as CVE-2026-109618 and CVE-2026-109619. They allow unauthenticated remote code execution and remote reads of worker memory, and they don't depend on your application code. A "Hello World" script on an affected version is enough. This guide is the practical part: how to find every PHP runtime you're actually serving traffic with, patch it, confirm the old workers are gone, and look for signs someone got there first.

Quick Summary: What You'll Learn

What PHP2Shell is and which setups are at risk
Why php -v can lie to you about what's serving requests
How to patch on Debian/Ubuntu, RHEL-family, Docker and FrankenPHP
Temporary mitigations if you can't patch today, and their limits
Log signals worth checking for exploitation

What is PHP2Shell, and is my server affected?

PHP2Shell is the name Wiz Research gave to a set of memory-safety bugs in how PHP handles fatal errors, mostly out-of-memory errors, while it processes a request. An interrupted request can leave corrupted internal state behind, and a later request handled by the same worker reuses it. Wiz chained these into pre-authentication RCE against the latest WordPress, Drupal and Joomla container images, and separately showed that an attacker can read chunks of worker memory, which can include passwords, tokens and API keys from other requests.

Per the PHP security advisory:

Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
At risk: every PHP installation serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team rates mod_php as highest risk, because the demonstrated exploit fires before any application code runs.
PHP 8.1 and older get no upstream release. Your distribution or LTS vendor may ship a backport; the PHP team also published minimal source backports for 7.4, 8.0 and 8.1 for people building from source.
Affected range: Wiz reports every release back to PHP 5.4 is hit by at least one of the bugs.

If you run anything on PHP, assume you're affected until you've checked.

How do I find which PHP versions are actually serving traffic?

This is where most patch rounds go wrong. The CLI binary, the FPM binary and the Apache module are separate packages with separate config, and they can be on different versions. Checking php -v over SSH tells you about the CLI only.

Start by finding what's running:

ps -eo pid,user,args | grep -E '[p]hp-fpm|[p]hp-cgi|[f]rankenphp|[l]sphp'
apachectl -M 2>/dev/null | grep -i php

The first line shows FPM masters and pools, CGI, FrankenPHP and LiteSpeed processes. The second shows whether Apache has mod_php loaded.

For PHP-FPM, ask the running binary directly rather than whatever php is on your PATH:

FPM=$(readlink /proc/$(pgrep -o php-fpm)/exe)
echo "$FPM"
"$FPM" -v

pgrep -o picks the oldest matching process, which is the FPM master. If readlink prints a path ending in (deleted), the binary on disk was replaced by an update but the old master is still running the previous code. That server is not patched yet, whatever the package manager says.

For containers, check inside each one:

docker ps --format '{{.Names}}\t{{.Image}}'
docker exec <container> php -v

For FrankenPHP, the PHP version is embedded in the binary. A small script run through its CLI mode tells you which one:

echo '<?php echo PHP_VERSION, PHP_EOL;' > /tmp/phpver.php
frankenphp php-cli /tmp/phpver.php

Distro packages: why the version number isn't the whole answer

Debian, Ubuntu and RHEL often backport security fixes into the version they already ship instead of moving to upstream 8.3.36 or 8.2.35. A package can be fixed while php -v still prints an older-looking number. Check the package changelog for the CVE instead:

# Debian / Ubuntu
apt-get changelog php8.3-fpm | grep -E 'CVE-2026-10961[89]'

# RHEL / Alma / Rocky
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]'

Swap the package name for whatever you run (libapache2-mod-php8.3, php8.2-cgi, and so on). No match means your vendor hasn't shipped the fix for that package yet, or you're on a repo that doesn't track it.

One specific warning from the PHP advisory: if you rely on the volunteer-run rpms.remirepo.net, it did not have updates on disclosure day. The advisory recommends switching to distribution packages or building from source so you can patch immediately.

How do I patch PHP for PHP2Shell?

The patch itself is ordinary. The part people skip is restarting every worker.

On Debian or Ubuntu:

sudo apt update
sudo apt install --only-upgrade 'php8.3*'
sudo systemctl restart php8.3-fpm

On RHEL-family systems:

sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm

If you use mod_php, restart Apache (systemctl restart apache2 or httpd), since the module lives inside the Apache workers. For Docker, pull or rebuild the image on a fixed tag and redeploy. If you pin images by digest, the old digest stays vulnerable until you update it. For FrankenPHP, upgrade the binary or image to a release built on a fixed PHP version and restart the service. If you followed our Laravel with FrankenPHP guide, that means replacing the binary and restarting the systemd unit.

Then re-run the checks from the previous section. You're done with a host when the running binary reports a fixed version (or the changelog shows the CVE), readlink no longer shows (deleted), and the master process started after the update:

ps -o lstart= -p $(pgrep -o php-fpm)

What can I do if I can't patch today?

The PHP team is explicit that these measures reduce exposure to specific attack paths and do not make an installation safe. Use them to buy hours, not weeks.

Disable session upload progress. Set session.upload_progress.enabled=0 in php.ini, the FPM pool or the server config, then restart every worker. Setting it with ini_set() or a .user.ini file does not help, because the bug fires during request parsing, before those apply.
Lower request size limits. post_max_size = 8M if the app takes no uploads, 32M if it does, with upload_max_filesize below it. Enforce limits on request body size, multipart part count and header count at the proxy too.
Remove the controllable memory-limit failure. The advisory suggests memory_limit=-1, set where applications can't override it, plus a container or cgroup memory limit as the availability boundary. Don't use RLIMIT_AS or RLIMIT_DATA for this; those can trigger the vulnerable allocation failure.
On PHP 8.5, set fatal_error_backtraces=0 and restart workers.

In an FPM pool, php_admin_* values can't be overridden by the application:

; /etc/php/8.3/fpm/pool.d/www.conf
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M

Remember the CLI has its own php.ini on most distros (/etc/php/8.3/cli/ vs /etc/php/8.3/fpm/ on Debian). Checking php -i from the shell doesn't tell you what FPM loaded.

Several CDNs and WAF vendors, including Cloudflare and Fastly, announced rules for PHP2Shell. That's a useful layer, but it only covers traffic that actually goes through them. Anything reachable directly by IP bypasses it.

How do I check whether a server was already exploited?

Wiz notes these bugs fire below the application layer, so application logs may show very little. The signals they recommend looking for:

Unusual multipart requests followed by memory-limit errors or repeated HTTP 500s
Unexpectedly large or malformed PHPSESSID cookies in responses
Unexplained PHP worker churn

A first pass on a typical nginx + FPM box:

grep -h 'Allowed memory size' /var/log/php*-fpm.log /var/log/nginx/error.log 2>/dev/null | tail -50
grep -h 'exited on signal' /var/log/php*-fpm.log 2>/dev/null | tail -50
awk '$9 == 500' /var/log/nginx/access.log | wc -l

The first finds out-of-memory fatals, the second finds workers that crashed (segfaults are worth a closer look), and the third counts 500s in the current access log, assuming the default combined format. None of these proves exploitation on its own. A cluster of all three around the same multipart POSTs is what deserves an incident.

If anything looks wrong, treat it as a compromise of everything that process could read: rotate database passwords, API keys and session secrets the app uses, and invalidate active sessions. The memory disclosure bug means secrets can leak without any code execution. Then check the host itself, including authorized_keys, cron entries and new users, as you would after any RCE. The complete guide to SSH security covers what to look at on the access side.

Where termique fits

None of this needs special tooling, but it gets tedious past a handful of servers. If you manage your hosts in termique, a few things help. Save the version checks above as snippets and run them in each session instead of retyping them. Snippets sync as plaintext, which is fine for commands like these but not for anything containing a secret. On Pro, incident investigation can run read-only commands across several selected hosts and assemble the results into a report, which suits the log checks in the last section; anything that changes the system still asks you first. And on shared hosts with command logging turned on, you get a record of who ran the patch and when, which is the question someone will ask later. More on that in what a per-command audit log actually catches.

FAQ

Is updating WordPress, Drupal or Laravel enough?

No. The bugs are in PHP itself, not in the CMS or framework. You need a fixed PHP build, and every worker running it, regardless of what the application is.

I'm on PHP 8.1 or older. What now?

There's no upstream release for 8.1 and older. Check whether your distribution or LTS vendor shipped a backport (the changelog check above), build from the PHP team's source backports for 7.4 to 8.1, or use this as the push to move to a supported version.

Does `php -v` tell me if I'm patched?

Only for the CLI, and only if you're on upstream version numbers. Check the running FPM, CGI or Apache module binary, and on distro packages check the changelog for the CVE IDs.

Is a WAF or CDN enough protection?

It reduces exposure for traffic routed through it. It does not protect a server that's reachable directly, and the PHP team's position is that updating is the only complete fix.

Do I need to rotate secrets even if I patched quickly?

If your servers were exposed and you see the log signals above, yes. The memory disclosure path can leak credentials without leaving the kind of trace an RCE would. If logs are clean and you patched early, rotation is a judgment call; for internet-facing apps that handle payments or auth, it's cheap insurance.

If you're juggling a lot of servers this week, termique is free to try.

termique v0.7.0 – a redesigned workspace

Rafi Bagaskara Halilintar — Mon, 19 Oct 2026 12:30:40 +0000

termique v0.7.0 is a big one. The whole workspace is rebuilt around one content panel, the investigation page is redesigned, and underneath that sits a long list of reliability, privacy and accessibility fixes.

Update from the in-app updater when the prompt appears, or grab a fresh build from the download page.

Features

A redesigned workspace. A top bar and an Explorer sidebar now frame a single content panel, replacing the old sidebar and tab strip. Empty and success states get new illustrations.
Calmer lists. Each list's views now sit in one dropdown next to its title instead of a row of controls.
Monitoring at a glance. The monitoring detail view shows live resources as one strip instead of donut charts.
A redesigned investigation page. Commands are grouped into one step list you can skip, edit or run inline, next to a case file that shows the status, the hosts involved and the report verdict.
Investigations always reach their report. A failed turn can be retried without retyping it, and a step that doesn't name a host asks which host to run on.
Command logging is off by default for new hosts. The share dialog offers to turn it on when it's off.
Recover from a changed host key. When a host's key has changed, you can forget the old key and reconnect, behind a clear warning and a confirmation.
Keyboard resizing. Split panes, the Files view and the assistant panel can be resized from the keyboard.
Smaller minimum window size, so the app fits small laptop screens and scaled displays.

Command logging is now a choice you make per host. Hosts you already have keep their current setting, and when you share a host without logging, the share dialog tells you and lets you turn it on.

A changed host key is either a server rebuild or something you should stop and look at. The new flow doesn't skip that decision, it just stops you from having to edit known_hosts by hand once you've made it. If you're not sure which case you're in, compare the new fingerprint with the server's before you confirm. Host key verification explained walks through how to check.

Improvements

The master password lockout can no longer be reset by restarting the app.
Commands proposed by the assistant are checked more strictly before they run automatically.
The AI assistant no longer receives your hosts' addresses or ports, only each host's label and user.
Share recipients are looked up without putting their email address in a URL.
Assistant messages no longer load remote images.
Credentials are removed from command logs before upload.
Error reports no longer contain IP addresses, host names, email addresses or tokens.
Faster startup: each page now loads the first time you open it, and charts and message formatting load only when needed.
An upgraded SSH engine that fixes several security issues.
If your system's web view is too old to draw the new interface, the app now tells you what to update.

Your server addresses now stay on your machine when you use the assistant. It only sees the name you gave a host and the user you log in as.

Two of these are worth calling out. Labels are often less sensitive than addresses, so if your host labels contain internal hostnames or IPs, the assistant will still see those; rename them if that matters to you. And command logs are stored on termique's backend without end-to-end encryption, which is why stripping credentials before upload, plus logging being opt-in for new hosts, matters. If you're deciding whether to turn logging on for a shared host, what a per-command audit log actually catches covers the tradeoff.

Bug fixes

Fixed SSH sessions hanging or blocking each other when one channel is slow, and connections left open after a failed connect.
Fixed shared hosts disappearing after a background refresh, and save conflicts when editing a host.
Fixed terminal scrollback being lost when tabs are merged or the app locks.
Commands that the assistant or an investigation runs on a shared host now appear in the owner's activity log.
Fixed the window freezing during database, keychain and file operations.
Rounded window corners now stay when the window is maximized on macOS.
The command palette, Explorer controls and previously unlabelled buttons now work properly with the keyboard and screen readers.

Update to v0.7.0 to get the new workspace and these fixes.

Keep reading

ssh-keygen Best Practices for 2026: Keys, Rounds, FIDO

Rafi Bagaskara Halilintar — Mon, 19 Oct 2026 12:17:38 +0000

Quick Summary: What You'll Learn

The one ssh-keygen command most people should run in 2026, and what each flag in it does.
How to choose between Ed25519, RSA, FIDO-backed -sk keys and the new post-quantum hybrid mldsa44-ed25519 type that OpenSSH 10.6 enabled.
Why -a (KDF rounds), a real comment and a passphrase matter more than key size.
The file permissions, ~/.ssh/config lines and fingerprint checks that keep a good key from becoming a bad habit.

Most ssh-keygen best practices guides stop at "use Ed25519". That's still the right default in 2026, but it's only one decision out of five. The key type, the passphrase, the KDF rounds that protect that passphrase, the comment that tells you which laptop the key came from, and where the private key ends up afterwards all decide whether a stolen file is a non-event or an incident. OpenSSH also shipped changes this year that affect new keys, so some older advice is out of date. Every flag below is checked against the current OpenBSD ssh-keygen(1) manual and the OpenSSH release notes.

What is the best ssh-keygen command to run in 2026?

For a personal key on a laptop or workstation, this is a sane default:

ssh-keygen -t ed25519 -a 100 -C "you@laptop-2026-10" -f ~/.ssh/id_ed25519_laptop

What each part does:

-t ed25519 picks the key type. Since OpenSSH 9.5 (October 2023), Ed25519 is what ssh-keygen generates when you pass no -t at all, so this flag is mostly there to be explicit in scripts and docs.
-a 100 sets the number of bcrypt_pbkdf rounds used to encrypt the private key with your passphrase. The manual's default is 32. Higher means slower passphrase checks and slower offline cracking if the file is stolen. More on choosing a number below.
-C "you@laptop-2026-10" sets the comment. The default is user@host, which tells you almost nothing two years later. Put the device and the date in it.
-f ~/.ssh/id_ed25519_laptop names the file, so the key doesn't silently overwrite an existing id_ed25519.

When it prompts for a passphrase, give it one. The manual's own guidance is that good passphrases are 10 to 30 characters, not simple sentences, with mixed character classes. A random phrase from a password manager is easier than inventing one.

Which SSH key algorithm should you choose?

ssh-keygen -t accepts ecdsa, ecdsa-sk, ed25519, ed25519-sk, mldsa44-ed25519 and rsa in the current manual. In practice, the choice looks like this:

Ed25519: the default for new keys. Small public keys, fixed length (-b is ignored), and supported by OpenSSH since 6.5 (January 2014). Pick this unless something below applies.
RSA: only for systems that can't do Ed25519 (some network gear, older appliances, a few hosted services). The manual's default size is 3072 bits and it calls 3072 "generally sufficient". Many teams use -b 4096 anyway; that's fine, just slower.
ECDSA: no strong reason to choose it over Ed25519 for user keys today. -b selects the curve (256, 384 or 521); other values fail.
Ed25519-SK / ECDSA-SK: keys backed by a FIDO authenticator (a hardware security key). The private part never leaves the hardware. Best choice when you have the token and your servers run a modern OpenSSH.
mldsa44-ed25519: a hybrid signature that combines ML-DSA-44 (a post-quantum scheme) with Ed25519. Read the next section before adopting it.

One thing people still mix up: OpenSSH 8.8 disabled the old ssh-rsa signature algorithm (RSA with SHA-1) by default. That did not make RSA keys obsolete. The same RSA key signs with rsa-sha2-256 or rsa-sha2-512, and the release notes say exactly that. If an old RSA key stopped working against a new server, the usual culprit is a client or server too old to negotiate SHA-2 signatures, not the key itself.

To see which key types your local OpenSSH supports:

ssh -V
ssh -Q key

Is the post-quantum mldsa44-ed25519 key ready to use?

OpenSSH 10.4 (July 2026) added mldsa44-ed25519 as an experimental, off-by-default composite signature scheme. OpenSSH 10.6 (released 2026-10-06) enabled it as a standard algorithm and dropped the @openssh.com suffix the experimental version used. The release notes are explicit that keys generated with the experimental support must be regenerated.

ssh-keygen -t mldsa44-ed25519 -a 100 -C "you@laptop-2026-10-pq" -f ~/.ssh/id_mldsa44_laptop

Practical guidance for now:

Both ends need an OpenSSH release that understands the new algorithm name. A server on an older release won't accept the key, so check with ssh -Q key on the server side too.
If you generated one of these during the experimental 10.4/10.5 window, regenerate it on 10.6 rather than debugging why it stopped matching.
Keep an Ed25519 key alongside it. Post-quantum key exchange already protects session traffic against record-now-decrypt-later attacks in recent OpenSSH releases; the signature side matters for a future attacker forging authentication, which is a slower-moving risk. There's no rush to make the hybrid key your only key.
Third-party clients, libraries and hosted git services may not parse it yet. Test before you depend on it.

How many -a rounds should you use?

The -a value only matters for keys that have a passphrase. It controls how much work it takes to test one passphrase guess against a stolen private key file. The man page states the default (32) and that higher numbers mean slower verification and more resistance to brute force; it doesn't prescribe a value.

A workable way to pick one: generate a throwaway key with a candidate value, then time how long unlocking it takes on your slowest machine.

ssh-keygen -t ed25519 -a 100 -N 'test-only-passphrase' -f /tmp/kdf-test -q
time ssh-keygen -y -P 'test-only-passphrase' -f /tmp/kdf-test > /dev/null
rm /tmp/kdf-test /tmp/kdf-test.pub

-y reads the private key and prints the public key, so it has to decrypt the file first. If it takes a fraction of a second, you can go higher. If it's annoying on every connection, an agent (below) means you only pay it once per session. Don't type real passphrases on the command line like this; -N and -P end up in shell history. It's fine for a throwaway test key only.

You don't need a new key to raise the rounds on an existing one. Changing the passphrase re-encrypts the file and accepts a new -a value (you can keep the same passphrase):

ssh-keygen -p -a 100 -f ~/.ssh/id_ed25519_laptop

Should every SSH key have a passphrase?

For keys that live on a laptop or a phone, yes. A passphrase turns "someone copied my ~/.ssh folder" from an immediate compromise into "they have an encrypted file and a lot of guessing ahead of them". The manual is blunt about the downside: there is no way to recover a lost passphrase. If you lose it, you generate a new key and replace the public key everywhere. Store it in your password manager.

The exceptions are keys that a machine has to use unattended: host keys (the manual says these must have an empty passphrase), and automation keys on CI runners or deploy boxes. For those, compensate on the server side instead. Restrict what the key can do in authorized_keys (a from= source address and a forced command, for example), or use short-lived certificates so a leaked key expires on its own. Our comparison of SSH certificates vs plain public keys covers when certificates are worth the setup.

To stop typing the passphrase on every connection, let ssh-agent hold the decrypted key for the session. In ~/.ssh/config:

Host *
    AddKeysToAgent yes

With AddKeysToAgent yes, the key and passphrase are added to a running agent the first time the key is loaded from a file. If you hit "incorrect passphrase supplied to decrypt private key" along the way, our passphrase troubleshooting guide walks through the usual causes.

When should you use a FIDO hardware key with ssh-keygen?

When the key protects something you'd hate to lose, and you already carry a security key. With ed25519-sk, the file in ~/.ssh is only a key handle. The actual private key sits inside the authenticator and can't be exported, so copying the file without the hardware gets an attacker nothing.

ssh-keygen -t ed25519-sk -O resident -O verify-required -C "you@yubikey-2026-10"

-O resident stores the key handle on the authenticator itself, so you can load it on another computer with ssh-keygen -K (or ssh-add -K). The manual notes the tradeoff: storing both parts on the device makes a stolen authenticator more useful to an attacker. Resident keys typically require a PIN on the token.
-O verify-required requires user verification (currently a PIN) for each signature, not just a touch. Not every authenticator supports it.
By default every signature needs a physical touch. -O no-touch-required turns that off, and sshd refuses such signatures unless the authorized_keys entry explicitly allows it. Leave the touch requirement on.

The caveats: the server needs a modern OpenSSH to accept -sk keys, and you should register a second authenticator as a backup, because losing the only token locks you out the same way a lost passphrase does.

How should you name, store and check SSH keys?

Generating the key well is half of it. These habits keep it manageable later.

One key per device. If a laptop is lost, you revoke one public key instead of rotating a key that lives on four machines. The comment is how you tell them apart in authorized_keys, which is why -C "you@laptop-2026-10" beats the default. Our guide to managing multiple SSH keys across devices has a naming scheme that scales past three machines.

Fix a bad comment without regenerating:

ssh-keygen -c -C "you@laptop-2026-10" -f ~/.ssh/id_ed25519_laptop

Permissions. ssh(1) ignores a private key file that other users can read, and recommends that ~/.ssh itself is accessible only by you:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519_laptop
chmod 644 ~/.ssh/id_ed25519_laptop.pub

Point each host at the right key. Without this, ssh offers every key in your agent in turn, which can trip a server's MaxAuthTries before it reaches the right one:

Host prod-bastion
    HostName bastion.example.com
    User deploy
    IdentityFile ~/.ssh/id_ed25519_laptop
    IdentitiesOnly yes

IdentitiesOnly yes tells ssh to use only the configured identity files, even when the agent holds others.

Install the public key, and only that one:

ssh-copy-id -i ~/.ssh/id_ed25519_laptop.pub deploy@bastion.example.com

-i makes sure only the key you named gets installed, with the comment from the .pub file, rather than everything in your agent.

Check fingerprints. When you add a key to a server or a git host, compare fingerprints instead of eyeballing base64:

ssh-keygen -lf ~/.ssh/id_ed25519_laptop.pub

SHA-256 is the default fingerprint hash. If you lost the .pub file, regenerate it from the private key with ssh-keygen -y -f ~/.ssh/id_ed25519_laptop > ~/.ssh/id_ed25519_laptop.pub.

Plan the rotation now. Put the year in the comment and you'll know which keys are overdue. Our SSH key rotation best practices post covers how often to rotate and how to do it without locking anyone out, and the team key management guide covers offboarding.

What ssh-keygen advice is outdated in 2026?

"Generate RSA 2048." Still accepted by sshd (the RequiredRSASize default is 1024 bits), but there's no reason to create new 2048-bit RSA keys when Ed25519 is available.
"DSA is fine for old systems." OpenSSH 10.0 removed DSA support entirely. Any remaining id_dsa key needs replacing.
"You must pass -t ed25519 or you get RSA." Not since OpenSSH 9.5; Ed25519 is the default.
"Use -o for the new key format." The OpenSSH private key format has been the default for years, and current ssh-keygen doesn't list -o in its synopsis at all. Use -m PEM only when an old tool insists on PEM.
"Post-quantum SSH keys aren't a thing yet." As of OpenSSH 10.6 they are, as a hybrid. They're just early.

Where does termique fit into SSH key management?

termique is a free, native ssh manager we build, with end-to-end encrypted credentials. On the key side, it does a few specific things:

Generate or import. You can generate ed25519 (recommended) or rsa keys in Settings → SSH keys, or import an existing private key in OpenSSH or PEM format, including passphrase-protected keys. For FIDO -sk keys and the new mldsa44-ed25519 type, generate with ssh-keygen as shown above.
Encrypted before it's stored. Private keys are encrypted on your device with a key derived from your master password before they're written locally or synced. The sync backend stores ciphertext only. Hosts, groups and snippets sync as plaintext metadata, so don't put secrets in host names or snippets. The security page has the full model.
Same keys on desktop and phone. Keys sync across macOS, Windows, Linux and iOS, so the key you use from your laptop is available in the mobile app without emailing a private key to yourself.

That last point is a real tradeoff against the one-key-per-device advice above. A synced key is one key on several devices: convenient, and protected by end-to-end encryption, but a lost phone means rotating that key everywhere it's authorized. If your policy is strictly one key per device, generate a separate key on each device instead; termique handles both, and the comment you set still tells you which is which.

FAQ

What is the most secure SSH key algorithm in 2026?

For everyday use, Ed25519 backed by a FIDO authenticator (ed25519-sk), because the private key can't be copied off the hardware. Without a hardware key, plain Ed25519 with a strong passphrase. The mldsa44-ed25519 hybrid adds post-quantum resistance to signatures, but needs OpenSSH 10.6 on both ends and isn't widely supported outside OpenSSH yet.

Is RSA 4096 better than Ed25519?

Not in any way that matters for most users. RSA 4096 is secure, but keys and signatures are much larger and slower. The manual considers 3072-bit RSA sufficient. Use RSA only for systems that can't handle Ed25519.

How do I add a passphrase to an existing SSH key?

Run ssh-keygen -p -f ~/.ssh/your_key. It prompts for the old passphrase (press Enter if there is none) and the new one twice. Add -a 100 to raise the KDF rounds at the same time.

Should I use the same SSH key on every computer?

Usually not. One key per device means a lost laptop costs you one revocation instead of a rotation across every server. Syncing one key across devices with end-to-end encryption is a valid choice for convenience, as long as you accept that losing any of those devices means rotating it.

What does the -C flag do in ssh-keygen?

It sets the key's comment, which is stored in the private key file and appended to the public key line in authorized_keys. It has no security effect, but a comment like you@laptop-2026-10 tells you which device and year a key belongs to when you audit a server.

Try termique free

If you want your keys, hosts and snippets on every machine you use, with private keys end-to-end encrypted before they leave the device, download termique and start on the free plan.

Alright my first weekly challenge on Hacktoberfest!

Rafi Bagaskara Halilintar — Fri, 02 Oct 2026 20:20:47 +0000

Rafi Bagaskara Halilintar

Oct 2

Kas Rumah: a receipt-reading expense tracker for my wife that never leaves our laptop

#devchallenge #weekendchallenge #hf26challenge

5 min read