An old administrator key is still sitting in the project folder. It works on several servers, but nobody knows exactly who has a copy. Moving from passwords to SSH keys has changed authentication without establishing responsibility.
Effective SSH management connects individual identities, suitable permissions on target systems and reliable revocation. Depending on the environment, maintained public keys with a sound inventory may suffice. Larger or frequently changing environments can benefit from short-lived SSH certificates. Both approaches need manageable operations.
Four things that should not be confused
The private user key proves the user’s identity. It is kept securely and is not distributed through chat, email or an unprotected project folder. The corresponding public key can be installed on the intended target systems to authorise access. Its fingerprint helps identify it unambiguously in the inventory.
The host key instead identifies the server being contacted. Host verification prevents a connection from silently reaching the wrong endpoint. An SSH certificate adds a signed statement to a public key, for example about identity and validity. OpenSSH certificates use their own format and are not ordinary TLS/X.509 certificates.
Separate personal logins from automated jobs
Administrative work is assigned to individuals and their authorised tasks. A shared, long-lived root key makes departures, rotation and traceability unnecessarily difficult. Individual logins with appropriately controlled administrative rights provide a better basis.
A backup or deployment job needs its own technical identity with documented responsibility. Wherever possible, restrict its access to the intended function, for example through a forced command and suitable forwarding rules. An employee’s private key should not silently become a permanent requirement for an automated job.
From key inventory to short-lived certificates
For a small number of systems, controlled public-key distribution may be sufficient. The inventory records the person or service, fingerprint, target systems, scope and planned review or replacement date. The crucial point is reliable maintenance of permissions on every affected target.
An SSH certificate authority can instead sign public keys for a limited period and defined identities. Servers trust the designated CA and check their additional rules. The private login key does not need to be sent to the CA. CA keys and issuance rules receive particular protection.
Short validity periods reduce the time an issued credential can be used. They do not end an existing session or replace revocation procedures. Issuing new certificates must also be prevented after a departure. A central secrets platform is one possible operating model; it must actually support the intended SSH workflow.
| Management approach | Suitable for | Operational requirements |
|---|---|---|
| Maintain public keys | A manageable, well-inventoried set of target systems. | Distribution, removal of old permissions and cover for absent administrators. |
| Issue SSH certificates | Limited validity and defined identities. | CA protection, issuance rules, server trust and revocation. |
| Technical identities | Automation with a clearly defined task. | Restricted target permissions, responsibility and rotation procedures. |
| Agent or hardware key | Suitable personal authentication methods. | Forwarding limits, version checks and recovery. |
Use agents and hardware keys deliberately
An SSH agent enables authentication using loaded keys without copying the private key file to every target server. Forwarding the agent does, however, give a remote system access to its signing capabilities. OpenSSH explicitly warns that an attacker with sufficient access to that system can authenticate using loaded identities without extracting the key material.
Agent forwarding is therefore configured only for the required path. Supported time or destination restrictions can provide further limits. Hardware security keys are another option for suitable interactive access. Client, server, key type and touch or PIN requirements must be compatible; an unattended job has different needs from a personal login.
Rotation and revocation must reach the target
Replacing a key on a notebook does not remove old access from the server. When public keys are installed, permissions must be updated on every affected target. Certificates can additionally use revocation mechanisms such as OpenSSH Key Revocation Lists. Revocation only takes effect when the intended servers correctly enforce it.
The procedure also covers a lost device, a compromised key and an unavailable management service. Independent emergency access is protected, documented and tested under controlled conditions. Recovery must not depend on the very access path that has failed.
Take a differentiated approach to Linux and Proxmox
In mixed environments, record versions and the OpenSSH features actually supported. A current manual does not guarantee that every installed Linux system offers the same options. Introduce new rules using a designated test login and a verified rollback path.
Proxmox VE also uses SSH for its own cluster functions, including certain console, migration and replication paths. Assess these technical trust relationships separately from personal administrator access. Blanket removal or overwriting of key files can disrupt operations. Check changes against the documentation for the installed version.
What a manageable first step includes
DAXS inventories existing SSH access, assigns responsibilities and plans suitable management. The pilot tests login, permissions, revocation, logging and recovery. A successful login alone is insufficient for acceptance. Authentication logs alone are not automatically a complete record of every command executed.
The infrastructure services and the article on Proxmox in business provide operational context. For shared portals, the article on vaults, roles and offboarding adds another perspective. You can request an inventory of administrative access.
Frequently asked questions
Can I share a public key?
The public part is intended for appropriate distribution. Its association with the right person and target must still be verified. The private part is protected and is not passed around as a shared access file.
Is a short-lived certificate sufficient for immediate revocation?
No. Issuance, remaining validity, revocation checks and existing sessions must be considered together. A short lifetime does not replace this process.
Is a central certificate authority always required?
No. Scale, frequency of change, automation and operational capability determine the right solution. Well-maintained key management may suit a manageable estate.
Sources: OpenSSH: authentication and authorised keys (external link) · OpenSSH: certificates and revocation lists (external link) · OpenSSH: server-side trust and revocation rules (external link) · OpenSSH: agent forwarding (external link) · OpenSSH: agent keys and restrictions (external link) · Proxmox VE: administration guide, SSH in the cluster (external link)
Conceptual guidance; specific features depend on installed versions and the planned management approach.
