Skip to content

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.

PlatformStatus
AndroidFull support
iOSFull support
WindowsFull support
macOSFull support
LinuxFull support
  1. Open a connection in the connection editor.
  2. In the advanced settings section, toggle Agent Forwarding on.
  3. Ensure the connection has an identity with a public key assigned.
  4. Connect to the server.
  5. From the remote server, SSH to another server. The remote SSH client will use ZestSSH’s forwarded keys for authentication.

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:

  1. Connection Setup — When a connection has agent forwarding enabled and has key pairs loaded, ZestSSH creates an SSHKeyPairAgent instance containing those keys.
  2. Agent Channel — The SSH client requests agent forwarding from the server ([email protected]). If the server accepts, it sets up an agent channel.
  3. Identity Requests — When the remote server’s SSH client (e.g., when you run ssh on the remote host) needs to authenticate, it sends an identity request through the agent channel. ZestSSH responds with the list of available public keys.
  4. 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.
  5. 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.

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.

The in-memory agent supports signing with:

  • RSA — Signs using rsa-sha2-256 by default. If the SSH_AGENT_RSA_SHA2_256 flag is set in the sign request, it uses SHA-256; if SSH_AGENT_RSA_SHA2_512 is set, it uses SHA-512. Falls back to ssh-rsa (SHA-1) only when no flag is specified.
  • Ed25519 — Standard Ed25519 signing.
  • ECDSA — P-256, P-384, P-521 signing.

Agent forwarding is a powerful feature but introduces security risks. Understanding these risks is important before enabling it.

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.

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.

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.

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.
  • In-memory only — ZestSSH does not connect to the system’s ssh-agent or pageant. 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.
  • 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 yes in sshd_config.
  • The connection log shows ssh_agent: Agent forwarding enabled if active, or ssh_agent: Agent forwarding skipped (no keys) if no keys are available.

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 -l on the remote server. It should list your key.
  • If ssh-add -l shows “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.