SSH Agent Forwarding
ZestSSH supports SSH agent forwarding, allowing you to authenticate to additional servers from within an active SSH session without copying your private keys to the remote host. Agent forwarding is implemented using an in-memory agent built into ZestSSH.
Availability
Section titled “Availability”| Platform | Status |
|---|---|
| Android | Full support |
| iOS | Full support |
| Windows | Full support |
| macOS | Full support |
| Linux | Full support |
Quick Start
Section titled “Quick Start”- Open a connection in the connection editor.
- In the advanced settings section, toggle Agent Forwarding on.
- Ensure the connection has an identity with a public key assigned.
- Connect to the server.
- From the remote server, SSH to another server. The remote SSH client will use ZestSSH’s forwarded keys for authentication.
How It Works
Section titled “How It Works”In-Memory Agent
Section titled “In-Memory Agent”ZestSSH implements the SSH agent protocol using SSHKeyPairAgent, an in-memory agent handler. Unlike a system ssh-agent that runs as a separate daemon, ZestSSH’s agent exists within the app process and holds the same key pairs used to authenticate the current connection.
The flow works as follows:
- Connection Setup — When a connection has agent forwarding enabled and has key pairs loaded, ZestSSH creates an
SSHKeyPairAgentinstance containing those keys. - Agent Channel — The SSH client requests agent forwarding from the server (
[email protected]). If the server accepts, it sets up an agent channel. - Identity Requests — When the remote server’s SSH client (e.g., when you run
sshon the remote host) needs to authenticate, it sends an identity request through the agent channel. ZestSSH responds with the list of available public keys. - Sign Requests — When the remote server selects a key, it sends a signing request. ZestSSH signs the authentication challenge using the private key held in memory and returns the signature.
- Transparent Auth — The remote SSH client receives the signed response and uses it to authenticate with the next-hop server, without ever having access to the private key.
Per-Connection Toggle
Section titled “Per-Connection Toggle”Agent forwarding is configured individually per connection. This allows you to enable it only for connections that need it (e.g., a bastion/jump host) and leave it disabled for others.
The toggle is stored in the connection database and synced via cloud sync if enabled.
Algorithm Support
Section titled “Algorithm Support”The in-memory agent supports signing with:
- RSA — Signs using
rsa-sha2-256by default. If theSSH_AGENT_RSA_SHA2_256flag is set in the sign request, it uses SHA-256; ifSSH_AGENT_RSA_SHA2_512is set, it uses SHA-512. Falls back tossh-rsa(SHA-1) only when no flag is specified. - Ed25519 — Standard Ed25519 signing.
- ECDSA — P-256, P-384, P-521 signing.
Security Considerations
Section titled “Security Considerations”Agent forwarding is a powerful feature but introduces security risks. Understanding these risks is important before enabling it.
Trust the Remote Host
Section titled “Trust the Remote Host”When agent forwarding is enabled, the remote server can use your keys to authenticate as you on other servers. A compromised remote server could:
- Use your forwarded keys to access any server that trusts those keys.
- Silently open connections on your behalf while your session is active.
Only enable agent forwarding on servers you fully trust. Never enable it when connecting to shared or multi-tenant hosts.
Keys Are Not Exposed
Section titled “Keys Are Not Exposed”Despite the security considerations above, agent forwarding does not expose your private keys. The remote server can request signatures but never receives the private key material. Signing operations happen inside ZestSSH’s process on your device.
Session Lifetime
Section titled “Session Lifetime”The forwarded agent is active only while the SSH session is connected. Once you disconnect, the agent channel is closed and no further signing requests can be made.
Alternatives to Agent Forwarding
Section titled “Alternatives to Agent Forwarding”If you need to reach a second-hop server, consider these safer alternatives:
- Jump Host / ProxyJump — ZestSSH supports multi-hop SSH via jump hosts, which tunnels the connection without forwarding your agent. See SSH Connections.
- Dedicated keys — Deploy a separate key pair on the remote server for onward connections, limiting the blast radius if the remote server is compromised.
Limitations
Section titled “Limitations”- In-memory only — ZestSSH does not connect to the system’s
ssh-agentorpageant. Only keys loaded into the current ZestSSH identity are available for forwarding. - No key addition at runtime — You cannot add keys to the agent after the connection is established. The agent contains whatever key pairs were loaded at connection time.
- Requires key pairs — Agent forwarding only works when the connection’s identity uses public key authentication. Password-only identities have no keys to forward, and the feature is silently skipped.
- Single hop — The forwarded agent supports one level of forwarding. Chained agent forwarding (A -> B -> C using keys from A) depends on server configuration and is not guaranteed.
Troubleshooting
Section titled “Troubleshooting”Agent forwarding not working
Section titled “Agent forwarding not working”- Confirm the toggle is enabled in the connection’s advanced settings.
- Verify the connection has a public key identity assigned (not password-only).
- Check that the server allows agent forwarding:
AllowAgentForwarding yesinsshd_config. - The connection log shows
ssh_agent: Agent forwarding enabledif active, orssh_agent: Agent forwarding skipped (no keys)if no keys are available.
”Failed to request agent forwarding”
Section titled “”Failed to request agent forwarding””The server rejected the agent forwarding request. This typically means AllowAgentForwarding no is set in the server’s sshd_config.
Remote SSH command prompts for password despite agent
Section titled “Remote SSH command prompts for password despite agent”- Check that the next-hop server trusts the same public key that is loaded in ZestSSH.
- Verify agent forwarding is reaching the remote SSH client: run
ssh-add -lon the remote server. It should list your key. - If
ssh-add -lshows “Could not open a connection to your authentication agent,” the server may not be setting up the agent socket correctly.
Q: Is agent forwarding the same as ProxyJump? A: No. ProxyJump tunnels the entire connection through an intermediate host without exposing your keys to it. Agent forwarding lets the remote host use your keys for onward authentication but introduces a trust dependency. ProxyJump is generally safer.
Q: Can I forward my system ssh-agent keys through ZestSSH? A: Not currently. ZestSSH uses its own in-memory agent with keys from the configured identity. System agent passthrough is a potential future feature.
Q: Does agent forwarding work with Mosh connections? A: No. Mosh does not support SSH agent forwarding through its UDP protocol. Use SSH for connections that require agent forwarding.