What Are SSH Certificates?

Beyond Traditional SSH Keys

While standard SSH key-based authentication is vastly superior to passwords, it faces significant challenges when deployed at scale in enterprise environments. As your infrastructure grows to hundreds or thousands of servers and users, traditional SSH key management becomes unwieldy and potentially insecure.

SSH certificates provide an elegant solution to these challenges, leveraging a certificate authority (CA) model similar to TLS/SSL certificates for websites, but adapted specifically for SSH authentication.

The Problem with Traditional SSH Keys

To understand why SSH certificates are valuable, we first need to recognize the limitations of traditional SSH key pairs:

Key Distribution Challenges

• Manual key distribution: Each user's public key must be manually copied to each server they need access to
• Key distribution tracking: Difficult to maintain visibility into which keys are on which servers
• Revocation complexity: When access needs to be revoked, keys must be manually removed from all servers

Security Limitations

• No built-in expiration: SSH keys don't expire by default, creating potential security risks
• Limited metadata: Traditional SSH keys don't include information about their purpose or restrictions
• Trust on first use (TOFU): Initial server connections require users to manually verify server keys
• Key creep: Over time, authorized_keys files grow with stale and forgotten keys

Operational Inefficiencies

• Scaling issues: The N×M problem - with N users and M servers, key management complexity grows exponentially
• Audit challenges: Difficult to track who has access to what systems and when that access was granted
• Key rotation barriers: The complexity of key distribution makes regular rotation impractical

Understanding SSH Certificates

SSH certificates solve these problems by introducing a trusted third party—a Certificate Authority (CA)—that signs user and host keys, converting them into certificates with additional metadata and controls.

Core Components

• SSH CA: A trusted key pair that signs other keys to create certificates
• User certificates: Signed versions of user public keys that authenticate users to servers
• Host certificates: Signed versions of server public keys that authenticate servers to users
• Principals: Identities (usernames, hostnames, or groups) authorized by a certificate
• Validity period: Explicit certificate start and end times, enforcing automatic expiration
• Extensions and critical options: Additional restrictions and capabilities attached to certificates

How SSH Certificates Work

1. CA setup: An organization establishes an SSH CA (or multiple CAs for different environments)
2. One-time server configuration: Each server is configured to trust the CA for user authentication
3. Certificate issuance: When a user needs access, the CA signs their public key, creating a certificate
4. Authentication: The user connects to any server that trusts the CA, presenting their certificate
5. Verification: The server verifies the certificate against the CA's public key
6. Authorization: The server grants access based on the certificate's principals and options

Setting Up an SSH Certificate Authority

Now let's walk through the basic process of setting up and using an SSH certificate authority:

1. Creating the CA Key Pair

      
        
# Create a directory with restricted permissions
      mkdir -p ~/.ssh/ca
      chmod 700 ~/.ssh/ca
      
      # Generate the CA key pair
      ssh-keygen -t ed25519 -f ~/.ssh/ca/user_ca -C "User SSH CA"
      
      # Optional: Generate a separate CA for host certificates
      ssh-keygen -t ed25519 -f ~/.ssh/ca/host_ca -C "Host SSH CA"

      
    

The CA private key should be treated with the utmost security, potentially using hardware security modules or air-gapped systems for high-security environments.

2. Configuring Servers to Trust the CA

On each server, configure the SSH daemon to trust the user CA's public key:

      
        
# Copy the CA public key to the server
      scp ~/.ssh/ca/user_ca.pub admin@server:/etc/ssh/
      
      # Add the CA public key to the SSH daemon configuration
      echo "TrustedUserCAKeys /etc/ssh/user_ca.pub" | sudo tee -a /etc/ssh/sshd_config
      
      # Restart the SSH daemon
      sudo systemctl restart sshd

      
    

With this configuration, the server will now trust any user certificate signed by your CA, subject to the constraints encoded in the certificate.

3. Signing User Keys to Create Certificates

When a user needs access, you sign their public key to create a certificate:

      
        
# Sign a user's public key with a 24-hour validity
      ssh-keygen -s ~/.ssh/ca/user_ca -I "[email protected]" \
        -n "alice,admin" -V +24h \
        -z 1 ~/.ssh/id_ed25519.pub

      
    

Let's break down this command:

• -s ~/.ssh/ca/user_ca: The path to the CA private key
• -I "[email protected]": A unique identifier for this certificate
• -n "alice,admin": The principals (usernames) this certificate is valid for
• -V +24h: Certificate validity period (24 hours from now)
• -z 1: Serial number for tracking/auditing
• ~/.ssh/id_ed25519.pub: The public key to sign

This will create a certificate file ~/.ssh/id_ed25519-cert.pub that the user can use to authenticate.

4. Signing Host Keys

Similarly, you can sign host keys to eliminate trust-on-first-use warnings:

      
        
# On the server, capture the host key
      sudo cp /etc/ssh/ssh_host_ed25519_key.pub /tmp/
      
      # On the CA machine, sign the host key
      ssh-keygen -s ~/.ssh/ca/host_ca -I "server.example.com" \
        -h -n "server.example.com,192.168.1.10" \
        -V +52w /tmp/ssh_host_ed25519_key.pub
      
      # Copy the certificate back to the server
      scp /tmp/ssh_host_ed25519_key-cert.pub admin@server:/etc/ssh/
      
      # Configure the server to use the certificate
      echo "HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub" | \
        sudo tee -a /etc/ssh/sshd_config
      
      # Restart the SSH daemon
      sudo systemctl restart sshd

      
    

5. Configuring Clients to Trust Host Certificates

On each client machine, configure SSH to trust the host CA:

      
        
# Add the host CA public key to the user's SSH configuration
      mkdir -p ~/.ssh
      echo "@cert-authority * $(cat ~/.ssh/ca/host_ca.pub)" >> ~/.ssh/known_hosts

      
    

Advanced Certificate Features

SSH certificates support a rich set of options to control access with fine-grained precision:

Certificate Extensions

Extensions modify the behavior of the certificate:

• permit-X11-forwarding: Allow X11 forwarding
• permit-agent-forwarding: Allow SSH agent forwarding
• permit-port-forwarding: Allow port forwarding
• permit-pty: Allow allocation of a pseudo-terminal
• permit-user-rc: Allow execution of user RC files

Critical Options

Critical options add restrictions to the certificate:

• force-command: Force a specific command to run instead of the user's shell
• source-address: Restrict the client IP addresses that can use the certificate

Here's an example of signing a key with extensions and critical options:

      
        
# Sign with restrictions
      ssh-keygen -s ~/.ssh/ca/user_ca -I "[email protected]" \
        -n "deploy" -V +12h \
        -O force-command="/usr/local/bin/deploy-app" \
        -O source-address="10.0.0.0/8" \
        -O no-port-forwarding \
        -z 2 ~/.ssh/id_ed25519.pub

      
    

This certificate allows the user to authenticate as "deploy", but they can only run the specified command, can only connect from IPs in the 10.0.0.0/8 range, and cannot use port forwarding.

Implementing Just-in-Time (JIT) Access

One of the most powerful capabilities enabled by SSH certificates is just-in-time access, where credentials are issued for short durations only when needed.

JIT Access Workflow

1. Access request: A user requests access to a server or group of servers for a specific duration
2. Approval flow: Optionally, the request is approved by a supervisor or automated based on policies
3. Certificate issuance: A short-lived certificate (minutes to hours) is issued
4. Access granted: The user accesses the systems within the validity period
5. Automatic expiration: When the certificate expires, access is automatically revoked

Benefits of JIT Access

• Minimized standing privileges: Users only have access when they need it
• Automatic revocation: Access expires without administrative action
• Clear audit trail: Each access request is logged and traceable
• Reduced time window: Limits the time an attacker can use a compromised credential

Basic JIT Implementation with Scripts

Here's a basic example of a JIT access script that could be used in a small organization:

      
        
#!/bin/bash
      # request-access.sh
      
      USER_ID="$USER@$(hostname)"
      PUBLIC_KEY="$HOME/.ssh/id_ed25519.pub"
      DURATION=4h
      CERT_FILE="$HOME/.ssh/id_ed25519-cert.pub"
      
      # Request certificate from CA server
      ssh ca-admin@ca-server "ssh-keygen -s /etc/ssh/ca/user_ca \
        -I \"$USER_ID\" -n \"$USER\" -V +$DURATION \
        -z $(date +%s) -f -" < "$PUBLIC_KEY" > "$CERT_FILE"
      
      echo "Access granted for $DURATION. Certificate saved to $CERT_FILE"
      echo "Certificate details:"
      ssh-keygen -L -f "$CERT_FILE"

      
    

For more complex environments, a number of open-source and commercial tools can manage this workflow at scale.

Enterprise SSH Certificate Management

Several open-source and commercial tools exist to help manage SSH certificates at scale:

Popular Certificate Management Tools

• HashiCorp Vault: Provides an SSH certificate signer as part of its secrets management capabilities
• Netflix BLESS: A Lambda function that issues short-lived SSH certificates
• Teleport: A comprehensive access management platform with SSH certificate support
• Facebook's besshctl: Facebook's open-sourced SSH certificate management tool
• Smallstep SSH: An SSH certificate authority and client tool

Certificate Integration with Identity Providers

For enterprise environments, you can integrate SSH certificates with existing identity systems:

• LDAP/Active Directory: Use existing directory services to authorize certificate issuance
• OIDC/OAuth: Integrate with identity providers like Okta, Google, or Azure AD
• SAML: Leverage enterprise single sign-on for certificate requests

SSH Certificates vs. TLS Certificates

While SSH certificates and TLS (HTTPS) certificates share similar concepts, they have important differences:

Handling Certificate Compromise

One challenge with SSH certificates is that, unlike TLS certificates, there's no standard revocation mechanism. Here are strategies to handle compromise:

CA Key Compromise

If a CA key is compromised:

1. Generate a new CA key pair immediately
2. Update all servers to trust the new CA and remove trust in the compromised CA
3. Issue new certificates to all users
4. Monitor for any unauthorized access using the compromised CA

User Certificate Compromise

If a user certificate is compromised:

1. Since certificates are short-lived, wait for expiration or...
2. Implement certificate revocation through a custom solution:
   • Configure servers to check a revocation list
   • Use security automation to update AuthorizedPrincipalsFile or similar
   • In extreme cases, temporarily disable the compromised principal across all systems

Implementing SSH Certificates with Secure Mail Client

Secure Mail Client integrates with SSH certificate workflows to enhance your overall security posture:

SSH Certificate Management

• Certificate request interface: Request new SSH certificates directly from the application
• Certificate tracking: Monitor active certificates and expiration dates
• Integrated SSH agent: Automatically use certificates for authentication
• Secure certificate storage: Store certificates with strong encryption and access controls

Configuring Secure Mail Client for SSH Certificates

1. Navigate to Settings > Security > SSH Certificate Management
2. Enter the SSH certificate authority endpoint
3. Configure authentication methods for certificate requests
4. Set certificate request templates for different access types
5. Enable automatic certificate renewal (optional)

Conclusion

SSH certificates solve many of the scalability, security, and management challenges associated with traditional SSH keys. By centralizing trust through certificate authorities, they enable sophisticated access controls, just-in-time permissions, and significantly improved operational efficiency.

As your infrastructure grows, transitioning from traditional SSH keys to certificate-based authentication is a foundational step toward more secure, manageable, and auditable server access. It enables modern security practices like zero standing privileges and just-in-time access that are essential for today's threat landscape.

In the next module, we'll explore multi-factor authentication strategies that can further enhance your security posture, including how to combine SSH certificates with additional authentication factors.