Secure Server Access: Hardware Keys & Ephemeral SSH Credentials

Managing a fleet of web servers, APIs, or internal applications requires a balance between security and ease of use. Password‑based SSH logins are simple but expose a single point of failure: if a password is compromised, every server that accepts it is at risk. Modern best practices recommend replacing passwords with hardware‑backed authentication and short‑lived credentials. This article explains how to use FIDO2/U2F security keys for SSH access and how to issue temporary SSH certificates for large server environments. The steps are provided for Debian/Ubuntu (apt) and AlmaLinux/Rocky Linux 8+ (dnf), with notes on Windows Server where applicable.

Why Passwords Are No Longer Sufficient

• Static secrets – passwords rarely change and are often reused across services.
• Phishing and keyloggers – a compromised password can be captured remotely.
• Brute‑force attacks – automated tools can try millions of combinations.
• Compliance – many regulations (e.g., ISO 27001, GDPR) now require multi‑factor authentication for privileged access.

Replacing passwords with a combination of hardware keys and short‑lived SSH certificates removes these weaknesses. A hardware key proves “something you have”, a certificate proves “something you are” (the private key on the key) and optionally “something you know” (a PIN). Ephemeral certificates limit the time window a credential is valid, further reducing risk.

Setting Up Hardware Security Keys for SSH

OpenSSH ≥ 8.2 includes native support for FIDO/U2F keys. The installation steps differ only in package names; the configuration is identical on Debian‑based and RHEL‑based systems.

1. Install Required Packages

Debian / Ubuntu (apt)

# apt update
# apt install openssh-client openssh-server libpam-u2f pcscd

AlmaLinux / Rocky Linux / RHEL (dnf)

# dnf install openssh openssh-server pam_u2f pcsc-lite

libpam-u2f (or pam_u2f) provides PAM integration for login. pcscd (or pcsc-lite) enables communication with USB smart‑card devices.

2. Register Your Security Key

Each user who will log in with a key must create a .ssh/authorized_keys entry that references the hardware token. Run the following as the target user (e.g., ubuntu or admin).

# mkdir -p ~/.ssh
# chmod 700 ~/.ssh
# ssh-keygen -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk -C "my-key" -O resident

The -t ecdsa-sk flag tells ssh-keygen to generate a key that lives on a FIDO2 security key. The -O resident option stores the private key on the token itself, so no private key file is written to disk. After touching the key, you’ll be prompted to set a PIN (optional but recommended).

Append the public key to authorized_keys:

# cat ~/.ssh/id_ecdsa_sk.pub >> ~/.ssh/authorized_keys
# chmod 600 ~/.ssh/authorized_keys

3. Configure SSHD to Require FIDO Keys

Edit /etc/ssh/sshd_config and add or adjust the following lines:

PubkeyAuthentication yes
AuthenticationMethods publickey,password
# Optional: enforce hardware keys only
# AuthenticationMethods publickey

Restart the SSH service:

Debian / Ubuntu

# systemctl restart ssh

AlmaLinux / Rocky Linux / RHEL

# systemctl restart sshd

Once the key works, passwords can be disabled by removing password from AuthenticationMethods.

Generating Ephemeral SSH Certificates

Even with hardware keys, you may want to avoid long‑lived public keys on every server. OpenSSH’s ssh-keygen -s command can act as a lightweight certificate authority (CA) that issues short‑lived certificates for a specific user and host set. This approach is useful for granting temporary access to developers, automation scripts, or auditors.

1. Create a CA Key Pair

Run this once on a secure, offline admin workstation (Linux or macOS). The CA key never leaves that machine.

# ssh-keygen -t ed25519 -f ~/ssh-ca -C "AtoZNode fleet CA"
# chmod 600 ~/ssh-ca

The private key (ssh-ca) signs certificates; the public key (ssh-ca.pub) is distributed to every server that will accept certificates.

2. Distribute the CA Public Key to All Nodes

Copy ssh-ca.pub to each server and add it to /etc/ssh/ssh_known_ca (or TrustedUserCAKeys in sshd_config).

Debian / Ubuntu

# mkdir -p /etc/ssh
# cat ssh-ca.pub >> /etc/ssh/ssh_known_ca
# systemctl restart ssh

AlmaLinux / Rocky Linux / RHEL

# mkdir -p /etc/ssh
# cat ssh-ca.pub >> /etc/ssh/ssh_known_ca
# systemctl restart sshd

Alternatively, add TrustedUserCAKeys /etc/ssh/ssh_known_ca to sshd_config if the file is not automatically read.

3. Issue an Ephemeral Certificate

When a user needs temporary access, generate a certificate that expires after a defined period (e.g., 4 hours). The command runs on the admin workstation that holds the CA private key.

# ssh-keygen -s ~/ssh-ca -I temp-$(date +%s) \
    -V +4h -n user1,root -z 1 ~/.ssh/id_ecdsa_sk.pub

Explanation of flags:

• -s ~/ssh-ca – path to the CA private key used for signing.
• -I temp-$(date +%s) – a unique identifier for the certificate (timestamp‑based).
• -V +4h – validity interval; +4h means “now until 4 hours later”.
• -n user1,root – principals (usernames) allowed to use the certificate.
• -z 1 – serial number; increment for each new certificate.
• Last argument is the public key to be certified.

The output is a file named something like id_ecdsa_sk-cert.pub. Copy this certificate to the user’s ~/.ssh/ directory on the client machine. SSH will automatically use it when the matching private key (stored on the hardware token) is present.

4. Automate Certificate Renewal (Optional)

For users who need daily access, a simple cron job can request a new certificate from an internal API that checks RBAC policies before invoking ssh-keygen. The script would:

1. Call the API with the user’s identity.
2. Receive a signed certificate valid for, say, 12 hours.
3. Save the certificate to ~/.ssh/ and set permissions to 600.

Because each certificate expires quickly, even if an attacker steals the hardware key they also need a fresh certificate, which they cannot obtain without API access.

Integrating with Configuration Management and Orchestration

When you manage dozens or hundreds of servers, manual distribution of the CA public key or updating sshd_config becomes error‑prone. Use your existing tools—Ansible, Chef, Puppet, or SaltStack—to enforce the required configuration.

Sample Ansible Playbook (YAML excerpt)

- hosts: all
  become: yes
  tasks:
    - name: Ensure SSH CA file exists
      copy:
        src: files/ssh-ca.pub
        dest: /etc/ssh/ssh_known_ca
        owner: root
        group: root
        mode: '0644'

    - name: Enable TrustedUserCAKeys in sshd_config
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^#?TrustedUserCAKeys'
        line: 'TrustedUserCAKeys /etc/ssh/ssh_known_ca'
        state: present
      notify: Restart SSH

  handlers:
    - name: Restart SSH
      service:
        name: "{{ 'ssh' if ansible_facts['os_family'] == 'Debian' else 'sshd' }}"
        state: restarted

This playbook works for both Debian‑based and RHEL‑based hosts because it selects the correct service name dynamically.

Best Practices and Operational Tips

• Backup the CA private key securely. Store it offline, encrypted with a strong passphrase, and limit access to a single admin.
• Rotate hardware keys regularly. Treat a lost or compromised key as a security incident and revoke its certificates immediately.
• Log certificate usage. Enable AuthorizedPrincipalsFile and LogLevel VERBOSE in sshd_config to record which principal used which certificate.
• Enforce PIN or biometric verification on the token. This adds a second factor even if the key is physically stolen.
• Combine with IP‑based restrictions. Use Match Address blocks in sshd_config for especially sensitive servers.

Windows Server Considerations

Windows Server does not use OpenSSH by default, but recent versions include an optional OpenSSH Server feature. The installation and configuration steps are similar: the service name is sshd and configuration files live under C:\ProgramData\ssh\. Hardware‑key support requires the same ssh-keygen -t ecdsa-sk commands run from a Git‑Bash or WSL environment, and the resulting public key can be placed in authorized_keys for the Windows user. For enterprise environments, consider using Azure AD‑joined machines with Conditional Access policies as an alternative to hardware keys.

Conclusion

Moving away from password‑based SSH logins significantly reduces the attack surface of any server fleet. By pairing FIDO2/U2F hardware keys with short‑lived SSH certificates signed by a dedicated CA, you gain:

• Phishing‑resistant authentication.
• Automatic credential expiration that limits misuse.
• Centralised control via a single CA key, simplifying revocation.
• Compatibility with existing automation tools and orchestration pipelines.

Implementing these measures on Debian/Ubuntu or AlmaLinux/Rocky Linux servers is straightforward, and the same principles translate to Windows Server when OpenSSH is in use. Start by provisioning hardware keys for your administrators, set up a CA, and integrate the workflow into your configuration‑management pipeline. The result is a more secure, auditable, and manageable environment for all of AtoZNode’s customers.