Eliminating On-Disk SSH Keys via Hardware-Resident Credentials

By moving SSH key material into secure hardware enclaves, users can ensure that even if a host's file system is compromised, the private keys cannot be exfiltrated or used without physical hardware presence. This shift addresses the vulnerability of 'traditional' on-disk keys, which remain accessible to any attacker who gains root access to the local machine.

The Shift to Hardware-Resident Keys

Traditional SSH keys are typically stored as files on a disk, protected only by a passphrase. While a passphrase encrypts the key using bcrypt and AES, the decrypted material is still vulnerable if an attacker gains sufficient privileges on the host. Hardware-resident keys move this protection to a secure enclave or a purpose-built device like a YubiKey.

The primary security benefit is that the hardware used to generate the key is required to use it. Because there is no mechanism to exfiltrate the internal key material, an attacker who steals a disk image or gains remote root access cannot replicate the key without physical possession of the hardware.

“The theoretical benefit here is that the hardware used to generate the SSH key is needed in order to use the key.”

— I deleted all my SSH keys

Implementation Methods: YubiKey, TPM, and Secure Enclave

The YubiKey method utilizes the ed25519-sk (Security Key) format. When a key is enrolled with the resident option, the YubiKey stores the material internally. The file on the host disk becomes a mere 'handle' that points to the hardware device. Users can configure these keys to require a physical touch for every authentication attempt, providing a high level of presence detection.

This screenshot illustrates the specific command-line method for enrolling keys into a YubiKey's internal memory.

For users wanting to leverage existing hardware, the TPM (Trusted Platform Module) can be used via the ssh-tpm-agent. Unlike the YubiKey, the TPM does not natively support enrolling SSH keys; instead, the private key material is stored on disk in encrypted form, and the TPM is used to decrypt it. This binds the key to the specific machine's hardware.

This visual demonstrates the implementation of TPM-backed keys using the ssh-tpm-agent.

On macOS, the Smart Card Auth system can create non-exportable identities within the Apple Secure Enclave. By using the -ne (non-exportable) flag during creation, the key is forced to stay within the enclave. These identities can be exported as handles to the disk, which OpenSSH can then use via the ssh-keychain.dylib provider.

This screenshot shows the process for creating non-exportable identities on macOS.

Operational Trade-offs and Limitations

Moving to hardware-resident keys introduces specific operational constraints. For example, Apple's Secure Enclave keys may fail in 'clamshell mode' (laptop lid closed) because TouchID is unavailable, requiring users to either use a Bluetooth keyboard with TouchID or a YubiKey for presence detection. Additionally, hardware malfunction or loss can render keys permanently unusable, making redundancy across multiple devices essential.

A significant limitation exists for unattended authentication. While YubiKeys support a 'no-touch-required' flag, this must be explicitly allowed on the server side by prepending the key in the authorized_keys file. This requirement may not be supported by all third-party services, such as GitHub or BitBucket, which may limit the use of these keys for automated workflows.