SSH · XB Field Notes

Forwarding an SSH agent

Wed, 09 Feb 2028 00:00:00 +0000

Agent forwarding is not the agent itself. A local agent can answer authentication requests without sending the private key to the server. Forwarding additionally makes that service reachable through a socket on a remote host. Keeping key material local therefore does not mean keeping its authentication capability local.

That distinction matters when choosing a route through a bastion. If the task is simply to log into a private machine, use ProxyJump with forwarding disabled. Forwarding is useful when a program actually running on the remote machine needs your agent, such as a deliberately authorized second SSH connection.

The remote gets a capability

The forwarded socket is normally exposed through SSH_AUTH_SOCK. Processes with access to it, including a sufficiently privileged attacker on that host, can request operations from the originating agent. This is not permission for every unrelated account on the machine, and it is not an export of the private key.

An unconstrained loaded identity can nevertheless authorize unwanted logins while the forwarding channel remains available. Key lifetime, confirmation requirements, destination restrictions, and server authorization all affect what succeeds. Calling this unrestricted ownership of the key overstates the mechanism, but understating socket access is just as dangerous.

An earlier version cited an unexplained 88-byte signature as evidence. Signature length alone establishes neither the OpenSSH agent protocol nor a forwarded authentication exchange. The exercise below instead tests a narrow, observable property with the actual client: its effective forwarding configuration.

Forwarding follows effective configuration

Omitting -A does not turn forwarding off. A matching Host block, an included configuration file, or system configuration can already enable it. Conversely, -A explicitly enables forwarding even when a configuration file says ForwardAgent no. Use -a or an unambiguous -o ForwardAgent=no when disabling it for a connection.

ProxyJump supplies a TCP route to the destination; it does not reset the destination’s forwarding option. The target SSH connection and its authentication still originate locally, so ordinary jump access needs no forwarded agent. Inspect settings for the destination and jump hosts separately, because their configuration is not necessarily identical.

On a remote shell, a subsequent SSH client evaluates its own configuration. Count effective settings, not appearances of -A in command history. Also check connection multiplexing when diagnosing an existing session: printing configuration describes a proposed invocation, not every property of a previously established connection.

Limit the delegation

ssh-add -c requests confirmation through an askpass program; absence of a terminal alone does not explain whether approval works. ssh-add -t limits an identity’s lifetime. Destination constraints, available since OpenSSH 8.9, use known host keys and require cooperating client and server support along forwarded paths. Every cooperating hop must be allowed. A hostile hop can relay the socket again using other tools, while signing remains restricted to permitted destinations.

Server-side AllowAgentForwarding no disables OpenSSH’s built-in facility. It does not prevent a user with unrestricted shell access from arranging another forwarder. Keep that restriction, but do not mistake it for isolation from a hostile shell user.

When it breaks

A compromised bastion can misuse an accessible forwarded agent while the channel and relevant identity remain usable. Replacing the private-key file on disk does not unload the agent’s old identity. Respond by ending the forwarding connection and removing the affected loaded identity; revoke the corresponding server authorization if compromise warrants it. Already established remote sessions need separate handling.

Another failure is enabling forwarding in Host * and forgetting it. Prefer narrow host exceptions and an agent containing only the needed identities. Selecting IdentityFile for one login is not a filter over everything a forwarded agent exposes.

ProxyJump supplies a route; forwarding exposes signing capability. Effective configuration and cooperating destination restrictions need separate checks.

Check it quickly

This disposable configuration prints four settings for manual comparison; it opens no network connection or private key. It has no value assertions or failure/cleanup trap:

f=$(mktemp)
printf 'Host *\n ForwardAgent no\n' > "$f"
ssh -G -F "$f" target.invalid | grep '^forwardagent '
ssh -G -F "$f" -A target.invalid | grep '^forwardagent '
printf 'Host *\n ForwardAgent yes\n' > "$f"
ssh -G -F "$f" -J bastion.invalid target.invalid | grep '^forwardagent '
ssh -G -F "$f" -a -J bastion.invalid target.invalid | grep '^forwardagent '
rm "$f"

The retained OpenSSH 10.0p2 record reports no, yes, yes, no; this review did not rerun it. This verifies option handling, not socket permissions, signing, destination constraints, or a live multi-hop connection. For a trusted real configuration, inspect ssh -G destination and jump-host aliases; evaluating Match exec can run local commands and hostname canonicalization can invoke DNS. A forwarding value of yes should have a specific reason and a trusted recipient.

Sources

OpenBSD: ssh, command-line forwarding controls, jump connections, and configuration inspection, checked 2026-10-15.
OpenBSD: ssh_config, ForwardAgent, ProxyJump, and configuration precedence, checked 2026-10-15.
OpenBSD: ssh-agent, agent sockets and authentication without transferring private keys, checked 2026-10-15.
OpenBSD: ssh-add, askpass confirmation, lifetimes, and destination-constraint requirements, checked 2026-10-15.
OpenBSD: sshd_config, AllowAgentForwarding and the shell-access limitation, checked 2026-10-15.

ssh-agent remembers your decrypted keys while you work

Sat, 27 Feb 2027 00:00:00 +0000

An SSH agent provides signing operations for public-key authentication. For ordinary software keys, loading an encrypted private key unlocks material that the agent can then use without asking for the file passphrase on every connection. Clients receive public identities and signatures, not an exported private key through the normal agent protocol. Hardware-backed identities are different: the authenticator can retain the private key and require touch or verification.

The socket provides access to a service

OpenSSH normally discovers the agent through SSH_AUTH_SOCK, but IdentityAgent in client configuration can select a different socket or disable agent use. Knowing a pathname is not equivalent to having permission to connect. Socket and parent-directory permissions matter, while root and other processes running as the same user are important threats. Do not treat an environment variable itself as a secret that can replace operating-system isolation.

Agent access is also not an unconditional promise that every signing request succeeds. Key constraints, confirmation requirements, hardware presence, and protocol restrictions can refuse requests. Even a successful signature does not force a remote server to accept that key or grant access. Separate local signing capability from the server’s authorization decision.

Bound both the key and the delegation

ssh-add loads an identity, asking for its passphrase when needed. Other configured paths, such as AddKeysToAgent in ssh, can also load identities; ssh-add is not the only possible unlock path. The agent avoids repeatedly reading the encrypted key file, but does not guarantee that every copy of private material is absent from swap, dumps, backups, or other processes.

The -t option assigns a lifetime to an added identity. When that lifetime expires, the identity is removed; the option is not merely a reminder. The agent can supply a default lifetime; without either limit, an ordinary identity can remain until removed or the agent exits. Removing or replacing the disk file does not automatically replace a previously loaded copy.

The -c option requires confirmation through ssh-askpass. It is the helper’s successful exit status that approves use; a missing terminal on the remote host is not the determining test. Verify the local confirmation mechanism and reject unexpected requests. Confirmation reduces unattended use but does not replace understanding which host or operation a prompt represents.

Destination constraints, introduced in OpenSSH 8.9, further restrict allowed authentication paths using host keys. Forwarded use needs supporting clients and servers plus correct known-host data. A hostile hop can relay the socket again outside cooperating SSH, but signing remains limited to permitted destinations. These constraints are not a firewall; verify compatibility and keep OpenSSH patched.

When it breaks

Agent forwarding lets a remote host relay signing requests while the forwarding channel exists. An administrator or compromised process there may use that capability without extracting the private key. Prefer avoiding forwarding when it is unnecessary, and review the effective client configuration rather than assuming that omitting -A proves it is disabled.

Deleting an identity from the agent does not revoke a stolen private-key copy, remove a server’s authorized_keys entry, or necessarily terminate an already established SSH session. Conversely, removing server authorization can stop new logins while the agent still holds the key. A recovery plan must address each affected copy, authorization record, and active session separately.

Modern OpenSSH agents restrict remote provider loading and certain FIDO signatures; identifying remote clients relies on cooperating SSH forwarding. These safeguards reduce specific misuse, including using forwarded authenticators outside SSH. They are not a reason to expose the socket broadly or enable relaxed options without a reviewed need. Defaults and socket locations can vary across versions and platform integrations.

Socket access can delegate signing while private-key storage and server authorization remain separate. The retained fixture checks configuration selection only.

Check it quickly

Save as agent_config.py and run python3 agent_config.py with OpenSSH installed. The fixture creates a temporary configuration and evaluates it using ssh -G. It neither starts an agent nor reads a private key, opens a connection, changes an existing agent, or depends on a real socket. Its synthetic socket differs from the configuration. No example ran in this source review.

import os
from pathlib import Path
import subprocess
import tempfile

with tempfile.TemporaryDirectory(prefix='agent-config-') as directory:
 work = Path(directory)
 alternate = str(work / 'alternate.sock')
 config = work / 'config'
 config.write_text(f'''Host chosen-agent
 HostName example.invalid
 IdentityAgent {alternate}
Host no-agent
 HostName example.invalid
 IdentityAgent none
''')
 env = {'PATH': os.defpath, 'SSH_AUTH_SOCK': str(work / 'environment.sock')}
 for host, expected in [('chosen-agent', alternate), ('no-agent', 'none')]:
 result = subprocess.run(['ssh', '-G', '-F', str(config), host],
 env=env, cwd=work, text=True, capture_output=True, check=True)
 fields = dict(line.split(' ', 1) for line in result.stdout.splitlines())
 if fields.get('identityagent') != expected:
 raise RuntimeError('unexpected IdentityAgent')
 print(host, 'identityagent=', fields['identityagent'])
 if (work / 'alternate.sock').exists() or (work / 'environment.sock').exists():
 raise RuntimeError('the fixture must not create an agent socket')
 print('PASS: explicit socket overrides environment; none disables agent use')

The first result selects the explicit alternate socket despite SSH_AUTH_SOCK. The second selects none. PASS confirms these configuration expectations only: ssh -G does not test socket access, signing, expiry, confirmation, or remote authentication. IdentityAgent none disables agent use for that invocation; it does not disable authentication using files or other mechanisms.

In a separate authorized test session, inspect loaded fingerprints and test lifetime and confirmation with a disposable identity. Do not run ssh-add -D against a shared everyday agent merely to reproduce an article: it removes all loaded identities and can interrupt other work. Keep the observation exercise separate from changes to credentials or live sessions.

Sources

OpenBSD: ssh-agent, signing service, socket access, provider and FIDO restrictions, checked 2026-10-15.
OpenBSD: ssh-add, lifetime, confirmation, removal, and destination constraints, checked 2026-10-15.
OpenBSD: ssh_config, IdentityAgent, AddKeysToAgent, and forwarding configuration, checked 2026-10-15.
OpenSSH: agent restriction, host-key binding and forwarding compatibility, checked 2026-10-15.

SSH host keys are part of the deployment record

Tue, 28 Jul 2026 00:00:00 +0000

In public-key authentication, a client proves possession of its private key; it does not tell the client which server it reached. The server’s host key and the local known_hosts database provide that second half of the identity check.

SSH server identity depends on comparing the observed host key with a separately trusted reference. Strict checking rejects unknown or changed keys. Trust on first use and a network key scan do not independently authenticate first contact.

Separate first contact from rotation

With StrictHostKeyChecking=yes, SSH refuses unknown hosts and changed keys. That is the safest default for a fixed production endpoint, provided the expected key is installed through a trusted channel. accept-new is a narrower convenience for a fleet where new hosts are expected: it accepts a never-seen key but still refuses a changed key.

Host production-site
HostName www.example.test
User deploy
IdentityFile ~/.ssh/site_ed25519
StrictHostKeyChecking yes
UserKnownHostsFile ~/.ssh/known_hosts

Do not “fix” a warning by adding StrictHostKeyChecking=no to a deployment script. It permits connections despite changed host keys, subject to client restrictions; warnings may still be printed, but the intended fail-closed identity check has been weakened. If a host is rebuilt, record the replacement fingerprint and review why the old key is no longer valid.

Make the fingerprint reviewable

Obtain the fingerprint from the host owner or console before the first connection, then compare it with what the client sees. A key change should have a ticket, maintenance note, or other explanation that another operator can inspect.

The same rule applies to automation: the known-hosts file is configuration with security consequences, not disposable cache data. Back it up with the deployment record, but do not publish private keys or copied credentials with the site artifact.

accept-new is trust on first use, not independent proof that the first server was genuine. ssh-keyscan can collect a candidate public key, but fetching it over the same untrusted network does not authenticate it. Compare its fingerprint with the separately trusted value before installing it.

Inspect the effective configuration without connecting, using a standalone copy of the example saved as deploy.conf:

ssh -G -F ./deploy.conf production-site | \
 grep -E '^(hostname|user|stricthostkeychecking|userknownhostsfile) '

Expect the configured host, user, known-hosts path, and strict checking (true or yes, depending on client output). This parses configuration only; it does not test an actual handshake. For a nonstandard port, known-hosts entries normally use [hostname]:port. Keep public-key fingerprints with the private operational release record, not the public website; hostnames can reveal internal topology even though host public keys are not secrets.

Sources

OpenBSD ssh_config, StrictHostKeyChecking and UserKnownHostsFile, checked 2026-07-28.
OpenSSH ssh-keygen manual, fingerprint inspection, checked 2026-07-28.
OpenSSH ssh-keyscan, unverified collected keys do not prevent man-in-the-middle attacks, checked 2026-10-15.
OpenSSH ssh, -G prints evaluated client configuration without opening a session, checked 2026-10-15.

SSH key hygiene is mostly limiting where a key works

Mon, 06 Jul 2026 00:00:00 +0000

SSH key hygiene starts with knowing which credential grants which access, who owns it, and how that access ends. A key comment helps people maintain an inventory, but it is not an authenticated owner record or an authorization rule. Track fingerprints alongside accountable owners, intended accounts, permitted operations, and a removal plan. Generating a modern key is only the beginning.

Scope the server-side permission

A public key in authorized_keys normally authorizes access to an account, subject to the server’s other controls. For automation, combine a narrowly privileged account with deliberately selected options. A forced command can restrict the executed operation, while from can limit source addresses. Neither magically confines the process to a working directory or makes an unsafe wrapper safe.

The restrict option disables forwarding, PTY allocation, and ~/.ssh/rc, but explicit companion options can re-enable individual facilities. It does not itself forbid shell or command execution, so an unattended job often also needs a carefully implemented forced command. A no-agent-forwarding option only blocks agent forwarding; it is not evidence that the key lacks general shell access. principals has a special meaning for trusted certificate-authority entries, not arbitrary ordinary keys.

Review the effective server configuration and alternative authorization sources. AuthorizedKeysCommand, certificate authorities, account privileges, and Match rules can change the result beyond one file. An inventory tool that sees an option name should report that observation, not issue a blanket “restricted and safe” verdict. Source restrictions also depend on the addresses actually seen by the server, including proxies and jump hosts.

Separate key types from signatures

An RSA public key line still uses the ssh-rsa key-type label even when authentication uses rsa-sha2-256 or rsa-sha2-512 signatures. OpenSSH 8.8 disabled the SHA-1 ssh-rsa signature scheme by default, not every RSA key. Inspect key size and actual negotiated signature support rather than labeling every RSA entry obsolete from its first word. DSA and weak or unsupported configurations require their own migration plan.

For new credentials, choose supported algorithms and suitable protection for the actual environment. A passphrase protects an encrypted private-key file against immediate use after copying, while hardware-backed keys can add different protections. Neither substitutes for a secure workstation, controlled agent access, and server-side scope. Automation that cannot prompt needs an explicit credential-storage and renewal design.

When it breaks

Rotation that only appends a new public key leaves the old credential authorized. Remove retired entries from every relevant authorization source, verify the replacement, and consider existing sessions separately. Ordinary raw public keys do not carry an automatic expiry. Enforce expiry through supported server options, SSH certificates, or deliberate lifecycle management; writing a date in a comment does nothing.

Permissions are another boundary, but the exact claim matters. Private keys should be owner-only, commonly mode 0600; a private directory commonly uses 0700. Public authorized_keys contents are not secret, and mode 0644 can be acceptable when ownership and write protections satisfy the server’s checks. A stricter 0600 policy is reasonable without pretending every other mode proves compromise. ACLs, parent directories, and platform rules need separate inspection.

Naively splitting authorized_keys on whitespace breaks commands containing quoted spaces. Escaped quotes and commas make a homemade parser especially easy to misread. Use OpenSSH to inspect key fingerprints, and review option semantics independently. A fingerprint match establishes which public key is present, not whether its restrictions are effective or its private half has a passphrase.

Inventory identifies a key; real authorization defines where it works. Key labels, negotiated signatures and retirement are distinct checks.

Check it quickly

Save as ssh_hygiene.py and run python3 ssh_hygiene.py with OpenSSH installed. It generates throwaway Ed25519 and 3072-bit RSA keys inside a temporary directory. Their empty passphrases are only for this disposable exercise. The script does not read or change your real SSH files, contact a host, or load an agent.

from pathlib import Path
import os
import stat
import subprocess
import tempfile


def run(*args):
 return subprocess.run(args, text=True, capture_output=True, check=True,
 env={'PATH': os.defpath}).stdout.strip()


with tempfile.TemporaryDirectory(prefix='ssh-hygiene-') as directory:
 work = Path(directory)
 # Throwaway, passphrase-less keys for this isolated fixture only.
 ed = work / 'demo_ed25519'
 rsa = work / 'demo_rsa'
 run('ssh-keygen', '-q', '-t', 'ed25519', '-N', '', '-C', 'fixture-ed', '-f', str(ed))
 run('ssh-keygen', '-q', '-t', 'rsa', '-b', '3072', '-N', '', '-C', 'fixture-rsa', '-f', str(rsa))
 public = ed.with_suffix('.pub').read_text().strip()
 auth = work / 'authorized_keys'
 auth.write_text('restrict,command="printf \\"two words\\"" ' + public + '\n')
 auth.chmod(0o600)
 parsed = run('ssh-keygen', '-l', '-f', str(auth))
 original = run('ssh-keygen', '-l', '-f', str(ed.with_suffix('.pub')))
 if parsed.split()[1] != original.split()[1]:
 raise RuntimeError('quoted options changed the key fingerprint')
 rsa_public = rsa.with_suffix('.pub').read_text().split()[0]
 if rsa_public != 'ssh-rsa':
 raise RuntimeError('unexpected RSA public key type')
 signatures = set(run('ssh', '-Q', 'key-sig').splitlines())
 if not {'rsa-sha2-256', 'rsa-sha2-512'} <= signatures:
 raise RuntimeError('client does not advertise RSA SHA-2 signatures')
 modes = {p.name: oct(stat.S_IMODE(p.stat().st_mode)) for p in (ed, rsa, auth)}
 if any(stat.S_IMODE(p.stat().st_mode) & 0o077 for p in (ed, rsa)):
 raise RuntimeError('fixture private key permissions are too broad')
 print('quoted authorized_keys fingerprint:', parsed)
 print('RSA key label:', rsa_public, '; SHA-2 signature algorithms supported')
 print('fixture modes:', modes)
 print('PASS: native key parsing, fingerprint agreement, RSA distinction, private modes')

Expect a matching Ed25519 fingerprint despite the quoted command, an ssh-rsa public-key label alongside advertised RSA SHA-2 algorithms, owner-only private-key modes, and PASS. Fingerprints and temporary paths change on each run. The context manager attempts to remove generated files on exit; this is not secure erasure. No private key contents are printed, and this source review generated no keys or reran this fixture.

The client algorithm query reports local capability, not a server’s accepted configuration. Likewise, ssh-keygen’s fingerprint parsing is not an end-to-end test of the forced command or every option. For a real audit, map each fingerprint to its owner, verify actual server authorization and command behavior in an isolated environment, and distinguish observed facts from controls that remain untested.

Sources

OpenBSD: sshd, authorized_keys format, options, and file ownership checks, checked 2026-10-15.
OpenSSH 8.8 release notes, RSA keys versus deprecated SHA-1 signatures, checked 2026-10-15.
OpenBSD: ssh-keygen, key generation and fingerprint inspection, checked 2026-10-15.
NIST IR 7966, SSH access inventory and lifecycle management, checked 2026-10-15.

SSH · XB Field Notes

Forwarding an SSH agent

The remote gets a capability

Forwarding follows effective configuration

Limit the delegation

When it breaks

Check it quickly

Sources

ssh-agent remembers your decrypted keys while you work

The socket provides access to a service

Bound both the key and the delegation

When it breaks

Check it quickly

Sources

SSH host keys are part of the deployment record

Separate first contact from rotation

Make the fingerprint reviewable

Sources

SSH key hygiene is mostly limiting where a key works

Scope the server-side permission

Separate key types from signatures

When it breaks

Check it quickly

Further reading

Sources