How do I manage SSH keys and certs in one place?

A common way to manage SSH keys and SSH certificates in one place is to use an SSH Certificate Authority (CA) plus a central inventory/source of truth for users, devices, and policies.

The basic model

Instead of distributing long-lived public keys everywhere, you:

1. Keep private keys on the user or device
2. Store/manage the corresponding public keys centrally
3. Sign those keys with an SSH CA
4. Configure servers to trust the CA, not individual user keys

That gives you a single place to handle:

• who can access what
• key expiration
• revocation
• auditing
• rotation

Options for “one place”

1. Use an SSH certificate management platform

Good if you want an out-of-the-box workflow.

Examples:

• HashiCorp Vault SSH CA
• Teleport
• Smallstep step-ca
• Okta/Google-style identity-backed SSH solutions
• Azure AD / AWS IAM-integrated approaches, depending on environment

These typically provide:

• key enrollment
• cert issuance
• short-lived certs
• policy-based access
• audit logs

2. Use a central Git/CMDB + CA tooling

If you want something lightweight:

• store approved public keys or identities in a central repo or database
• use a CA like ssh-keygen, Vault, or step-ca
• automate signing and distribution with Ansible, Puppet, Chef, or Salt

This is simpler, but you build more of the workflow yourself.

Recommended architecture

For users

• User generates an SSH key pair locally
• Public key is uploaded to your central system
• Central system signs it into a short-lived SSH cert
• User connects with the cert
• Servers trust the CA and validate the cert

For servers

• Each server has:
  • host key pair
  • CA trust configured for user certs
• Optionally also issue host certificates to manage server identity centrally

Why certificates are better than plain keys

Plain keys:

• can live forever
• are hard to revoke everywhere
• require per-host authorized_keys management

Certificates:

• expire automatically
• are centrally issued
• can include principals, groups, and critical options
• reduce server-side key sprawl

What to store centrally

At minimum:

• user identity
• device identity
• public keys
• allowed principals/groups
• cert TTL/policy
• revocation list or cert serial history
• audit logs of issuance and login

Practical tools

Smallstep step-ca

Good for:

• SSH user certs
• SSH host certs
• short-lived certs
• simple CA workflows

HashiCorp Vault SSH secrets engine

Good for:

• organizations already using Vault
• integrated secrets and identity workflows

Teleport

Good for:

• access management, bastions, session recording, RBAC
• replacing much of traditional SSH key handling

If you want a simple starting setup

Use:

• step-ca or Vault as the SSH CA
• LDAP/SSO/OIDC as identity source
• Ansible for server trust distribution
• short-lived certs instead of static keys

Rule of thumb

If your goal is “manage SSH keys and certs in one place,” the best practice is:

Centralize identity and certificate issuance, not the private keys themselves.

If you want, I can also give you:

1. a recommended architecture diagram,
2. a step-by-step setup with step-ca or Vault, or
3. a comparison of tools for this use case.