Venafi SSH Protect

1. When Native OpenSSH Isn't Enough

You can absolutely run SSH certificates with just OpenSSH. We covered that in our SSH Certificate Authority Setup guide.

But at some point, the DIY approach breaks down:

2. What Venafi SSH Protect Does

Venafi SSH Protect is an enterprise platform for SSH certificate lifecycle management. It sits between your users/automation and your SSH CA:

┌─────────────┐     ┌─────────────────────┐     ┌─────────────┐
│   Users     │     │   Venafi SSH        │     │   Servers   │
│   CI/CD     │────▶│   Protect           │────▶│   (trust    │
│   Automation│     │                     │     │    Venafi   │
└─────────────┘     │  • Policy engine    │     │    CA)      │
                    │  • CA management    │     └─────────────┘
                    │  • Audit logging    │
                    │  • Approval flows   │
                    └─────────────────────┘

Core capabilities:

3. Architecture Options

Venafi SSH Protect offers flexibility in how it manages your SSH CA:

4. Key Features Deep Dive

Policy Engine

Define rules that every certificate must follow:

Policy: "production-servers"
├── Max validity: 8 hours
├── Allowed principals: [deploy, monitoring, oncall]
├── Required extensions: [permit-pty]
├── Forbidden extensions: [permit-port-forwarding]
├── Source address: required (must specify)
└── Approval: required for "oncall" principal

Policies are enforced automatically. A user can't request a 30-day certificate if the policy says 8 hours max.

On the host side, this policy is enforced via sshd_config:

# /etc/ssh/sshd_config (on each server trusting the Venafi CA)
TrustedUserCAKeys /etc/ssh/venafi_user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

Inventory and Discovery

Venafi can discover existing SSH keys and certificates across your infrastructure:

• • Scan servers for authorized_keys files
• • Identify unmanaged SSH access
• • Find certificates issued outside Venafi
• • Track expiration dates across everything

→ See our Certificate Discovery guide for discovery concepts.

Just-in-Time Access

Instead of long-lived certificates, users request access when needed:

CI/CD Integration

Automation gets certificates too:

# GitHub Actions example
- name: Get SSH certificate
  run: |
    vcert ssh getcred \
      --url https://venafi.example.com \
      --token ${{ secrets.VENAFI_TOKEN }} \
      --key-id "github-actions-${{ github.run_id }}" \
      --principal deploy \
      --validity 1h \
      --public-key ~/.ssh/id_ed25519.pub \
      --output ~/.ssh/id_ed25519-cert.pub

Certificate is issued for just this pipeline run, with minimal permissions.

The runner's ~/.ssh/config can then use the cert automatically:

Host prod-*.example.com
  User deploy
  IdentityFile ~/.ssh/id_ed25519
  CertificateFile ~/.ssh/id_ed25519-cert.pub

5. Comparison: DIY vs. Venafi

6. Integration Points

Venafi SSH Protect connects to your existing infrastructure:

7. Deployment Models

Typical deployment timeline (ballpark estimates):

Actual timelines depend on environment complexity, team size, and change management requirements.

8. Migration Path

Already have SSH certificates? Here's how to migrate:

9. When to Choose Venafi vs. Alternatives

Venafi SSH Protect vs OpenSSH, Vault, step-ca, Teleport

Venafi isn't the only option for enterprise SSH certificate management. Here's how to decide:

10. Talking to Your Security Team

If you're advocating for SSH certificates internally, here's what security teams care about:

11. Getting Started

If you're evaluating Venafi:

If you're not ready for Venafi:

Start with native OpenSSH certificates:

• → SSH Certificate Authority Setup - Build your own CA
• → SSH User Certificates - Eliminate authorized_keys
• → SSH Host Certificates - Eliminate TOFU

You can always migrate to Venafi later when scale or compliance demands it.

FAQ

Related Guides

→ Explore all SSH topics in our Guide Collection