Architecture and operating model
With static SSH keys, each server recognizes allowed public keys in authorized_keys or through a central lookup. Offboarding requires removing the key from every target. With SSH certificates, a short-lived user key is signed by a trusted certificate authority with identity, principals, validity and critical options. Servers trust the CA public key instead of every individual user key.
Certificates centralize authentication but do not eliminate authorization. The mapping from certificate principals to Unix accounts or access policy must be explicit. Host certificates can also reduce management of large known-host key sets. User and host CAs need not share a key; separating them creates narrower trust boundaries.
A short lifetime is not a complete security design. Access to the signing service, protection of the CA private key, clock synchronization, serial numbers and audit records all matter. Emergency revocation may require a Key Revocation List or an access-layer cutoff in addition to short validity. Static keys can remain simpler for small, stable environments; lifecycle advantages of certificates grow with people, servers and temporary assignments.
- 1User key
- 2Identity and policy check
- 3Short-lived SSH certificate
- 4Server principal decision
Design parameters
- Validity
- Keep human access close to task duration; separately test renewal and outage behavior for automation identities.
- Principal design
- Map stable roles or accounts deliberately instead of assuming an email address is a Unix user name.
- CA separation
- Use separate user and host CAs and scopes; evaluate offline roots or hardware protection according to risk.
- Audit and revocation
- Record who received which principals, target scope and lifetime, correlated by certificate serial number.
Worked example
Issue the operations team a 30-minute certificate containing only the web-admin principal. Web servers trust the user CA through TrustedUserCAKeys; database servers must not accept that principal. Record rejection of a new connection after expiry and separately observe whether an existing session continues under product policy.
For 20 administrators and 200 servers, static distribution and removal can touch hundreds of targets. Certificates consolidate that work into CA trust and signing policy, while CA compromise has a wider blast radius. The decision therefore depends on CA operating maturity, not only file counts.
Example commands: replace lab values and confirm permissions and software versions before use.
ssh-keygen -s user_ca -I ticket-4821 -n web-admin -V -5m:+30m -z 4821 operator.pub
ssh-keygen -L -f operator-cert.pub
sshd -T | grep -E 'trustedusercakeys|authorizedprincipals'Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Signed certificate is rejected | Principal, TrustedUserCAKeys path or system time may not match. | Inspect principals and validity with ssh-keygen -L, then compare effective sshd configuration and time. |
| Old access lasts longer than expected | Open sessions might not close when certificate validity ends. | Test new connections and existing sessions separately; enforce session duration at the access layer. |
| Many targets fail together | CA file distribution or the signing service is a shared failure domain. | Monitor CA trust deployment and the last successful certificate-issuance path independently. |
Acceptance checks
- Distribute CA trust only to intended servers.
- Test principal mapping with allowed and disallowed accounts.
- Reject expired and not-yet-valid certificates.
- Reject a certificate signed by the wrong user CA.
- Log issuance with serial and request identity.
- Rehearse emergency revocation and signer outage.
Related concepts
Authentication and sessions
Authentication proves who a user or workload is; authorization determines what that identity may do. Successful sign-in does not grant access to every resource. User sessions, service identities, API tokens and device certificates have different lifecycles. Design session duration, token renewal, employee departure, lost-device handling and emergency access alongside initial sign-in. Measure which existing sessions remain usable and which new accesses are denied when the identity provider becomes unavailable.
Least privilege and separation of duties
Least privilege limits the permissions needed for a task to specific resources and time periods. Giving everyone the same administrator role complicates access reviews and investigations. Separate daily-use identities from privileged accounts, and restrict interactive use and unnecessary network access for service identities. An access matrix should show which operation an identity may perform on each resource. Test whether an application keeps working after a permission is removed: unnecessary privileges sometimes become visible only during controlled reduction.
Trust boundary and failure domain
A trust boundary separates components governed by different access decisions; a failure domain groups resources that one event can affect together. Two VLANs do not create a strong trust boundary when routing between them is unrestricted. Backups in different folders still share a failure domain if one administrator can delete both. Assess physical location, identity provider, management account, network path and power source separately. Test which access paths and recovery options remain available when a component is lost.
Version and support lifecycle
Installability does not prove production support. Review the compatibility chain across OS, application, drivers, extensions and management tools. Update plans should record version, support end, restart needs and rollback methods. An unrepresentative test environment can produce misleading results. Validate service health and existing workflows after a change, not just version numbers. Remember that pinning a version can also prevent future security fixes.
File permissions and service identities
File access combines users/groups, permission bits, ACLs and security policies. Running an application as root can hide permission problems; prefer a justified, restricted service identity in production. Directory traversal permission differs from file-read permission. Sharing permissions do not necessarily override filesystem restrictions. Identify the actual runtime user, directory chain and ACLs when troubleshooting. Test narrowly required access rather than opening permissions globally.
Telemetry and time correlation
Telemetry combines logs, metrics and events that explain system behaviour. A log describes an event, a metric shows behaviour over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.