SSH Keygen and SSH-Agent: Converting Signed Host Keys

To convert signed SSH host keys, you must first extract the raw public key from the server's /etc/ssh directory, sign it using a trusted Certificate Authority (CA) with ssh-keygen, and then deploy the resulting certificate file to the target hosts. This process replaces traditional fingerprint verification with cryptographic trust chains managed by ssh-agent.

Understanding Host Key Certificates

Standard SSH connections rely on verifying the server’s host key fingerprint manually or via known_hosts. However, in large infrastructure environments, this becomes unmanageable. SSH supports host certificates, which are essentially host keys signed by a central CA. When a client connects, it validates the signature against the CA’s public key rather than checking individual fingerprints. This allows administrators to revoke access instantly by removing the CA key or revoking specific certificates without touching every client machine. The primary benefit is centralized management of trust, reducing the risk of man-in-the-middle attacks caused by forgotten or incorrect fingerprints.

Extracting the Public Host Key

The first step is obtaining the current public key of the host you wish to certify. You typically find these files in /etc/ssh/ on Linux systems. Common filenames include ssh_host_rsa_key.pub, ssh_host_ecdsa_key.pub, or ssh_host_ed25519_key.pub. To ensure you have the correct format for signing, use the ssh-keygen utility to print the key in a standardized format. Run the following command on the target host:

ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub

This outputs the fingerprint and key type. If you need to copy the key content to your CA server, you can simply cat the file or use scp. Ensure that the private key corresponding to this public key remains secure on the host and is never transmitted to the CA server. Only the public key is required for the signing process.

Signing the Key with SSH-Keygen

Once you have the public key on your CA server, you use ssh-keygen to sign it. You need the CA’s private key for this operation. The syntax involves specifying the CA key, the type of certificate (host), and validity period. Use this command structure:

ssh-keygen -s /path/to/ca_private_key -I host_identity -h -n hostname.example.com /path/to/host_public_key.pub

Key flags include:

• -s: Specifies the CA private key used for signing.
• -I: Sets the identity string embedded in the certificate.
• -h: Indicates this is a host certificate (not a user certificate).
• -n: Defines the principal names (hostnames) allowed for this certificate.

After execution, a new file with the same name but the extension .cert.pub will be generated. This file contains the original public key along with the signature and metadata. Verify the certificate details using ssh-keygen -L -f /path/to/host_public_key.cert.pub to ensure the principals and validity dates are correct.

Deploying Keys via Ansible

For automated deployment across multiple servers, Ansible provides an efficient way to push these certificates. Create an Ansible playbook that copies the generated .cert.pub file to the /etc/ssh/ directory on each target host. You must also update the sshd_config to point to the new certificate file if necessary, although modern OpenSSH versions often auto-detect .cert.pub files alongside their private keys. Here is a simplified task example:

- name: Copy host certificate
  copy:
    src: ./server_host_cert.pub
    dest: /etc/ssh/ssh_host_ed25519_key.cert.pub
    owner: root
    group: root
    mode: '0644'

After copying, restart the SSH service to load the new certificate. Always test connectivity after deployment. If issues arise, check /var/log/auth.log for errors related to certificate validation. For further troubleshooting on connection issues, see our guide on Troubleshooting kex_exchange_identification Error in Linux SSH Connection.

Managing Trust on Client Side

Clients must trust the CA’s public key. Add the CA’s public key to /etc/ssh/ssh_known_hosts or ~/.ssh/known_hosts with the prefix @cert-authority. For example:

@cert-authority *.example.com ssh-rsa AAAA... [CA_PUBLIC_KEY]

This tells all clients that any host matching *.example.com presenting a valid signature from this CA should be trusted automatically. This eliminates the need for manual fingerprint verification during initial connections.

Handling Agent Forwarding

While host keys are static, user authentication often involves ssh-agent. Ensure that agent forwarding is configured correctly if you rely on it. Misconfigurations here can lead to security risks. Learn more about managing keys provided by the agent at List of ssh keys provided by ssh agent on a remote machine.

Frequently Asked Questions

Can I use the same CA for both user and host keys?

Yes, you can use a single CA key pair to sign both user and host certificates. However, it is considered a best practice to separate them for security reasons. Using distinct CAs limits the blast radius if one private key is compromised, preventing attackers from impersonating either users or servers.

What happens if the CA private key is compromised?

If the CA private key is leaked, an attacker can sign arbitrary host or user keys, effectively allowing them to impersonate any server or user trusted by that CA. Immediate action is required: revoke the old CA, generate a new one, redistribute the new public key to all clients, and re-sign all existing host keys.

How do I verify a host certificate on the client side?

You can verify the certificate locally using the ssh-keygen -L -f /path/to/cert.pub command. This displays the certificate’s principals, validity period, signing key, and extensions. It helps confirm that the certificate was issued by the expected CA and covers the correct hostname.

Do I need to restart SSH after deploying the certificate?

Yes, the SSH daemon must reload its configuration to recognize the new certificate file. On most Linux distributions, running systemctl restart sshd or service ssh restart is sufficient. Without a restart, the daemon continues to use the previous key pair until it is signaled to reload.

Why is my client still asking for fingerprint verification?

This usually occurs because the client does not have the CA’s public key in its known_hosts file with the @cert-authority tag. Ensure that the line starts with @cert-authority followed by the pattern and the CA’s public key. Also, verify that the host’s certificate includes the exact hostname the client is connecting to in its principals list.