To grant temporary SSH access securely, you should use Certificate Authority (CA) keys to sign user public keys with a specific expiration time. This method allows administrators to issue credentials that automatically expire, eliminating the need for manual cleanup of authorized_keys files or managing complex cron jobs to revoke access after a set period.
Understanding SSH Certificate Authorities
Traditional SSH authentication relies on individual public keys stored in the
authorized_keys file on the server. While effective for long-term users, this approach becomes cumbersome when granting short-term access to contractors, auditors, or emergency support staff. Every time access needs to be revoked, an administrator must manually edit these files across potentially hundreds of servers.
SSH Certificate Authorities provide a scalable alternative. Instead of trusting individual keys, the SSH daemon trusts a CA certificate. When a user presents a key signed by this CA, the server validates the signature and checks the certificate's validity period. If the current time falls outside the start and end dates defined in the certificate, access is denied automatically. This mechanism centralizes trust management and simplifies lifecycle management for temporary accounts.
Generating the CA Key Pair
The first step involves creating a Certificate Authority key pair on a secure machine, typically a bastion host or a dedicated key management server. You should never distribute the CA private key to regular users or store it on the target SSH servers. The process begins by generating a strong Ed25519 key, which is currently recommended for its security and performance benefits.
Run the following command to generate the CA private key:
ssh-keygen -t ed25519 -f /etc/ssh/ca_key -N "" -C "temporary-access-ca"
This command creates two files:
/etc/ssh/ca_key (the private key) and
/etc/ssh/ca_key.pub (the public key). The private key must remain secret, while the public key will be distributed to all SSH servers that need to validate these temporary certificates. Ensure the permissions on the private key are restricted to root only, using
chmod 600.
Distributing the CA Public Key to Servers
Once the CA key pair is generated, the public key must be installed on every SSH server where temporary access is desired. This is done by appending the CA public key to the global
sshd_config file. This tells the SSH daemon to trust any key signed by this specific CA.
Add the following line to
/etc/ssh/sshd_config:
TrustedUserCAKeys /etc/ssh/ca_key.pub
After modifying the configuration file, restart the SSH service to apply the changes. On systems using systemd, execute:
sudo systemctl restart sshd
If you have multiple servers, consider using configuration management tools like Ansible or SaltStack to propagate this change consistently. For more details on managing key additions manually, refer to our guide on
Fixing Permission Denied with OpenSSH: Manually adding authorized_keys. Note that this step differs from standard user key addition as it configures the server's trust anchor rather than individual user permissions.
Signing User Keys with Expiration
When a temporary user requires access, generate their key pair locally if they do not already have one. Then, sign their public key using the CA private key. The critical aspect of this step is specifying the valid-from and valid-to times. These parameters define the window during which the certificate is considered valid.
Use the
-V flag to set the validity period. For example, to grant access for exactly 24 hours starting from now:
ssh-keygen -s /etc/ssh/ca_key -I temp_user_id -n username -V +24h /home/user/.ssh/id_ed25519.pub
This command produces a signed certificate file, typically named
id_ed25519-cert.pub. The user must copy both their original private key (
id_ed25519) and the signed certificate (
id_ed25519-cert.pub) to their local machine. The SSH client will automatically present the certificate during authentication if it is located in the same directory as the private key.
Verifying Access and Revocation
To verify that the setup works, attempt an SSH connection from the user's machine. The server will check the certificate against the trusted CA key. If the signature is valid and the current time is within the specified window, access is granted. If the certificate has expired, the server rejects the connection immediately.
Revoking access is instantaneous because it is tied to the expiration time embedded in the certificate. No further action is required on the server side once the
valid-to time passes. This eliminates the risk of lingering access rights that could be exploited later.
For troubleshooting connection issues, such as key exchange errors or permission denials, consult our resources on
Troubleshooting kex_exchange_identification Error in Linux SSH Connection and
Permission denied when trying to SSH into CISCO virtual router. These guides cover common pitfalls that may arise even with proper certificate configuration.
Frequently Asked Questions
Can I use RSA keys instead of Ed25519 for the CA?
Yes, you can use RSA keys, but Ed25519 is generally preferred due to better security properties and faster performance. If you must use RSA, ensure the key length is at least 4096 bits to maintain adequate security standards.
How do I handle users who need access beyond the initial expiration?
You must re-sign the user's public key with a new validity window. Simply extending the existing certificate is not possible; a new certificate must be generated and distributed to the user. Automating this process can reduce administrative overhead for recurring temporary roles.
Does this method work for SFTP connections?
Yes, SSH certificates authenticate the user regardless of the protocol used over the SSH tunnel. If the user has shell access via the certificate, they also have SFTP access unless specific restrictions are configured in
sshd_config.
What happens if the CA private key is compromised?
If the CA private key is compromised, all previously issued certificates become untrustworthy. You must immediately rotate the CA key pair, update the
TrustedUserCAKeys on all servers, and re-issue new certificates to all active users. Regular audits of CA key storage are essential.
Is there a limit to how many servers can trust the same CA?
There is no technical limit to the number of servers that can trust a single CA public key. However, managing a large fleet of servers requires careful consideration of deployment strategies to ensure all nodes receive updates promptly.