Skip to content

SSH (Secure Shell)

ZestSSH implements the SSH 2.0 protocol via a custom-patched dartssh2 library, providing encrypted remote terminal access across all supported platforms. SSH is the default and recommended connection protocol for all remote server access.

PlatformStatus
AndroidFull support
iOSFull support
WindowsFull support
macOSFull support
LinuxFull support
  1. Tap the + button on the home screen (or use Ctrl+T on desktop).
  2. Enter the hostname or IP address of your server.
  3. Set the port (default: 22).
  4. Select or create an identity (username + authentication method).
  5. Tap Connect.

For quick one-off connections, use the Quick Connect bar and type user@host directly.

When you initiate an SSH connection, ZestSSH performs the following sequence:

  1. TCP Connection — Establishes a TCP socket to the target host and port with a 15-second timeout.
  2. Protocol Negotiation — Begins SSH-2.0 protocol handshake, exchanging supported algorithms for key exchange, encryption, host key verification, and MAC.
  3. Key Exchange — Negotiates a shared secret using the highest-priority mutually supported KEX algorithm.
  4. Host Key Verification — Presents the server’s host key fingerprint for verification. New hosts prompt for trust-on-first-use (TOFU); changed keys always trigger a warning.
  5. Authentication — Authenticates using the configured method: public key, password, or keyboard-interactive.
  6. Shell Session — Opens a PTY with xterm-256color terminal type and begins the interactive shell session.

ZestSSH offers the following algorithms during negotiation, listed in the order they are presented to the server (highest priority first).

CipherKey SizeModeAEAD
[email protected]512-bit (2x256)Stream + Poly1305Yes
aes128-ctr128-bitCTRNo
aes128-cbc128-bitCBCNo
aes256-ctr256-bitCTRNo
aes256-cbc256-bitCBCNo

The following ciphers are implemented in the core library but not included in the default negotiation list: [email protected], [email protected], aes192-ctr, and aes192-cbc. They can be enabled through custom algorithm configuration.

AlgorithmDigest
[email protected]SHA-256
ecdh-sha2-nistp521SHA-512
ecdh-sha2-nistp384SHA-384
ecdh-sha2-nistp256SHA-256
diffie-hellman-group-exchange-sha256SHA-256
diffie-hellman-group14-sha256SHA-256
diffie-hellman-group14-sha1SHA-1
diffie-hellman-group-exchange-sha1SHA-1
diffie-hellman-group1-sha1SHA-1

Curve25519 is preferred and negotiated first when the server supports it.

AlgorithmType
ssh-ed448Ed448 (Edwards curve)
ssh-ed25519Ed25519 (Edwards curve)
rsa-sha2-512RSA with SHA-512
rsa-sha2-256RSA with SHA-256
ssh-rsaRSA with SHA-1 (legacy)
ecdsa-sha2-nistp521ECDSA P-521
ecdsa-sha2-nistp384ECDSA P-384
ecdsa-sha2-nistp256ECDSA P-256

Used for integrity verification when a non-AEAD cipher is negotiated:

AlgorithmKey SizeNotes
hmac-sha2-256-96256-bitTruncated to 96 bits
hmac-sha2-512-96512-bitTruncated to 96 bits
[email protected]256-bitEncrypt-then-MAC
[email protected]512-bitEncrypt-then-MAC
hmac-sha1160-bitLegacy
hmac-sha2-256256-bitStandard
hmac-sha2-512512-bitStandard
hmac-md5128-bitLegacy, not recommended

When an AEAD cipher (ChaCha20-Poly1305 or AES-GCM) is negotiated, MAC algorithms are not used because authentication is built into the cipher.

ZestSSH supports three SSH authentication methods:

Each SSH connection supports the following configurable parameters:

ParameterDefaultDescription
Host(required)Hostname or IP address
Port22SSH server port
UsernameConfigured per identityLogin username
Keep-Alive Interval15 secondsInterval for sending keep-alive packets to prevent idle disconnects
Zlib CompressionOffEnable zlib payload compression for slow links
Agent ForwardingOffForward SSH keys to the remote host for onward connections
Jump HostNoneProxy the connection through another saved SSH connection
Environment VariablesNoneJSON map of variables to export on the remote shell

ZestSSH supports multi-hop SSH connections via jump hosts. When a connection has a “Connect Via” host configured:

  1. An SSH connection is established to the jump host first.
  2. A direct-tcpip channel is opened through the jump host to the target.
  3. The target SSH session runs through this tunnel.

Both the jump host and the target connection perform full host key verification independently.

  • The SSH library does not currently support OpenSSH certificates (*[email protected] key types). Standard public key and password authentication are fully supported.
  • FIDO2/WebAuthn (sk-*@openssh.com) key types are not yet supported. See FIDO2 Hardware Keys for current status.
  • There is no support for GSSAPI/Kerberos authentication.
  • Verify the host is reachable and the SSH service is running on the expected port.
  • Check that firewalls or security groups allow inbound traffic on the SSH port.
  • Try reducing the connection timeout or checking with a port scanner.

This means the server’s host key fingerprint differs from what ZestSSH previously recorded. This could indicate a legitimate server reinstall or a potential man-in-the-middle attack. Verify the new fingerprint with your server administrator before accepting.

  • Confirm the username and credentials are correct.
  • For public key auth, verify the key is in the server’s ~/.ssh/authorized_keys.
  • Check the server’s sshd_config for PubkeyAuthentication and PasswordAuthentication settings.

The server and ZestSSH do not share any common algorithms. This typically happens with very old or very hardened servers. Check the server’s sshd_config for Ciphers, KexAlgorithms, and MACs directives.

Q: Does ZestSSH support SSH-1? A: No. SSH-1 has known security vulnerabilities and has been deprecated for over a decade. Only SSH 2.0 is supported.

Q: Can I use a non-standard SSH port? A: Yes. Set the port to any value between 1 and 65535 in the connection editor.

Q: Does ZestSSH support zlib compression? A: Yes. Enable it per-connection in the advanced settings. This can improve performance over slow or high-latency links but adds CPU overhead.

Q: How does keep-alive work? A: ZestSSH sends SSH keep-alive packets at the configured interval (default 15 seconds). This prevents firewalls and NAT devices from closing idle connections and helps detect broken connections faster.