What we are aiming for is support for standard (non sk-*) SSH keys backed by macOS Secure Enclave, created and managed in a way that avoids application-level vendor lock-in.
Specifically, we would like Royal TSX to be able to:
-
Create a standard SSH key whose private key resides in Secure Enclave
(i.e. a classical SSH key type such as ecdsa-sha2-nistp256, not a FIDO / sk-* identity).
-
Expose that key as a credential inside Royal TSX, including the human-readable description/name assigned in Royal.
-
Make that key available via a standard SSH agent interface (e.g. SSH_AUTH_SOCK), so that:
-
other SSH clients and tools can use the same key,
-
access is not limited to Royal TSX itself,
-
the key can be shared across applications in a controlled, user-approved way.
The important requirement is that Royal TSX should not become the only application capable of using the key.
Comparison with existing tools
As a reference point, Shellfish demonstrates that it is possible to use Secure Enclave–backed SSH keys successfully. However, Shellfish currently integrates with Secure Enclave in an application-specific way: the keys are usable inside Shellfish, but they are not exposed through a standard SSH agent interface and therefore cannot be accessed from the terminal or other SSH clients.
This is precisely the limitation we would like to avoid in Royal TSX.
Possible UX direction (conceptual idea)
Conceptually, I imagine that in the document tree (where Royal TSX currently displays connections and credentials), there could also be a hardware-backed component section — for example:
This would allow Royal TSX to:
-
detect existing hardware-backed identities,
-
present them as selectable credentials,
-
clearly distinguish hardware-backed keys from file-based keys,
-
while still relying on standard system interfaces rather than app-local key storage.
This is just a conceptual UX idea, but it illustrates the intended direction:
integration with platform-level security components, not isolated application-level key silos.
Desired user experience
Ideally, the workflow would look like this:
The user installs Royal TSX.
If Secure Enclave already contains one or more SSH keys, Royal TSX automatically detects them.
Those keys appear in the document/credential tree as available hardware-backed identities.
The user can select and use those keys for connections inside Royal TSX.
New Secure Enclave–backed keys created within Royal TSX also become visible through the standard SSH agent interface.
The same keys remain available to other tools (e.g. terminal, scripts, other SSH clients) through the SSH agent, without duplication or re-generation.
In other words, Royal TSX should both:
discover existing hardware-backed identities, and
integrate with them via standard system interfaces rather than app-local storage.
To be clear:
this request is not about FIDO / sk-* identities or SecurityKeyProvider.
It is about standard SSH keys whose private material is hardware-protected by Secure Enclave, while remaining accessible via a standard agent interface.
