OpenSSH Certificates
OpenSSH certificates provide an alternative to the traditional authorized_keys model by using a Certificate Authority (CA) to sign user and host keys. This page documents the current status of certificate support in ZestSSH.
Current Status: Not Implemented
Section titled “Current Status: Not Implemented”ZestSSH does not currently support OpenSSH certificate-based authentication. The SSH library (dartssh2) does not parse or produce the *[email protected] key types. Certificate support is planned for a future release.
What Are OpenSSH Certificates?
Section titled “What Are OpenSSH Certificates?”Traditional SSH authentication requires deploying each user’s public key to every server’s authorized_keys file. OpenSSH certificates simplify this by introducing a trust hierarchy:
- A Certificate Authority (CA) generates a signing key pair.
- The CA’s public key is configured as trusted on each server (in
sshd_config). - User keys are signed by the CA, producing a certificate that encodes the user’s public key plus metadata (principals, validity period, extensions).
- When a user connects, the server trusts the user’s certificate because it was signed by the trusted CA — no
authorized_keysentry is needed.
OpenSSH defines these certificate key types:
[email protected][email protected][email protected][email protected][email protected][email protected][email protected]
Benefits of Certificate Authentication
Section titled “Benefits of Certificate Authentication”- Centralized access control — Add or revoke users at the CA level without touching individual servers.
- Time-limited access — Certificates can have expiration dates, providing automatic access revocation.
- Principal-based authorization — Certificates encode which usernames (principals) the holder is authorized to use.
- No authorized_keys management — Servers only need the CA public key, not every user’s individual key.
- Audit trail — Certificate serial numbers provide a natural audit mechanism.
Why It Matters
Section titled “Why It Matters”Organizations using tools like HashiCorp Vault, Smallstep, or custom CA infrastructure for SSH certificate management cannot currently use ZestSSH as their SSH client for those workflows. Users in these environments must use a traditional key pair and deploy it to authorized_keys on their servers.
Technical Requirements for Implementation
Section titled “Technical Requirements for Implementation”Supporting certificates in ZestSSH would require:
1. Certificate Parsing
Section titled “1. Certificate Parsing”The SSH library needs to parse the certificate wire format, which extends the standard public key format with:
- Nonce (random bytes)
- Serial number
- Certificate type (user or host)
- Key ID string
- Valid principals list
- Validity period (not-before, not-after)
- Critical options
- Extensions
- CA public key
- CA signature
2. Certificate-Aware Authentication
Section titled “2. Certificate-Aware Authentication”During the SSH authentication handshake, the client must present the certificate (not just the raw public key) as the identity. The server validates the CA signature, checks the validity period and principals, then proceeds with the standard signature verification using the user’s private key.
3. Certificate Storage
Section titled “3. Certificate Storage”ZestSSH would need to store both the certificate file and the corresponding private key for each identity. The certificate is not secret (it contains only public information and the CA signature), but it must be presented alongside the private key during authentication.
4. Host Certificate Verification
Section titled “4. Host Certificate Verification”For host certificate verification, ZestSSH would need to store trusted CA public keys and verify server host certificates against them, as an alternative to the current TOFU (Trust On First Use) model.
Workarounds
Section titled “Workarounds”Use a Standard Key Pair
Section titled “Use a Standard Key Pair”If your organization issues OpenSSH certificates, you likely also have the underlying key pair. You can import the private key into ZestSSH and add the raw public key to authorized_keys on the target servers as a fallback.
Short-Lived Certificate Workflow
Section titled “Short-Lived Certificate Workflow”Some organizations use short-lived certificates alongside permanent authorized_keys entries. Deploy your ZestSSH public key to servers where you need access, and use certificates from other clients when available.
Q: Can I import an OpenSSH certificate into ZestSSH? A: No. The current identity system only accepts private keys (PEM format) and does not parse or use certificate files. The certificate would be ignored.
Q: Will certificate support be added? A: It is under consideration but there is no firm timeline. The primary blocker is SSH library support for the certificate wire format and authentication flow.
Q: Can I use ZestSSH with HashiCorp Vault SSH? A: Not with the certificate signing workflow. You can use Vault’s “OTP” (One-Time Password) backend with ZestSSH by entering the OTP as a password, or configure a permanent key pair as a fallback.
Q: Are host certificates supported for server verification? A: No. ZestSSH uses the standard TOFU (Trust On First Use) model for host key verification, with support for known hosts storage and changed-key warnings.