You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
resident
Indicate that the key handle should be stored on the FIDO authenticator itself. This makes it easier to use the authenticator on multiple computers. Resident keys may be supported on FIDO2 authenticators and typically require that a PIN be set on the authenticator prior to generation. Resident keys may be loaded off the authenticator using ssh-add(1). Storing both parts of a key on a FIDO authenticator increases the likelihood of an attacker being able to use a stolen authenticator device.
I'd like to add my two cents to this feature request.
One of the primary reasons I use an Android SSH client is for emergency access while traveling. Unfortunately, I've had my phone stolen during a trip before. With my previous SSH client (terminus), replacing the phone meant generating a new FIDO2-backed SSH key, updating my servers, and then repeating the process again once I returned back home and had bought a permanent new phone.
It worked, but it was an huge burden during a shitty situation.
If Conduit supported downloading existing resident OpenSSH credentials from a FIDO2 authenticator (similar to ssh-keygen -K or ssh-add -K), the recovery process would be dramatically simpler.
I could purchase a replacement phone, install Conduit, recover the resident credential from my key, and immediately regain access to my infrastructure without generating new keys or modifying any servers configuration.
I understand the security trade-offs between resident and non-resident credentials. For many users, non-resident credentials are probably the better default. However, for a mobile emergency workflow, I believe resident credentials provide a significant usability advantage. In my case, the key is an apex flex nfc implant that is literally always with me, while my phone is the device most likely to be lost, stolen, or replaced.
Supporting resident credential discovery would make Conduit the best choice for admins who rely on OpenSSH FIDO2 credentials and need a portable, standards-based recovery workflow that isn't some proprietary junk that other apps use.
I know "+1, me too" comments aren't exactly the finest contribution one can make to a GitHub issue, but I'll throw mine in anyway.
I don't keep anything particularly sensitive on the machines I SSH into, and strictly speaking there's not much there worth protecting. I use hardware keys mostly because I'm extremely lazy.
They've saved me from remembering passwords, dealing with password managers, moving SSH keys between devices, and other annoying bullshit.
The last missing piece for me is basically "ssh-keygen -K" on Android.
Once that's there, my laziness can finally be complete.
I'll just add that resident credentials can be used right now without any issues, they just can't be imported from the key itself. If you generate a resident credential on a pc and copy the "private" key (which contains no cryptographic material and is purely just a stub that tells OpenSSH about your key and how to find it, so it can even theoretically be published safely) to your phone, you can paste it into Conduit as an ed25519-sk private key and it will work just fine.
I'll just add that resident credentials can be used right now without any issues, they just can't be imported from the key itself. If you generate a resident credential on a pc and copy the "private" key (which contains no cryptographic material and is purely just a stub that tells OpenSSH about your key and how to find it, so it can even theoretically be published safely) to your phone, you can paste it into Conduit as an ed25519-sk private key and it will work just fine.
I think we're talking about two different use cases. I'm aware that copying the OpenSSH key handle (stub) from another machine works today. My request is specifically about eliminating the need for that stub in a disaster recovery scenario.
If my phone is stolen while traveling and my only remaining device is my FIDO2 authenticator, I want to be able to install Conduit on a replacement phone and recover the resident credential directly from the authenticator (like ssh-keygen -K or ssh-add -K) without requiring access to another computer or a backup of the stub file. The value of resident credentials is their portability, and from what you've written and I've seen it isn't implemented in conduit yet.
I'll just add that resident credentials can be used right now without any issues, they just can't be imported from the key itself. If you generate a resident credential on a pc and copy the "private" key (which contains no cryptographic material and is purely just a stub that tells OpenSSH about your key and how to find it, so it can even theoretically be published safely) to your phone, you can paste it into Conduit as an ed25519-sk private key and it will work just fine.
That's true, but it's extra work. Computers were made to reduce manual work, not to create tasks like “go copy something from one place to another.”
I think we're talking about two different use cases. I'm aware that copying the OpenSSH key handle (stub) from another machine works today. My request is specifically about eliminating the need for that stub in a disaster recovery scenario.
If my phone is stolen while traveling and my only remaining device is my FIDO2 authenticator, I want to be able to install Conduit on a replacement phone and recover the resident credential directly from the authenticator (like ssh-keygen -K or ssh-add -K) without requiring access to another computer or a backup of the stub file. The value of resident credentials is their portability, and from what you've written and I've seen it isn't implemented in conduit yet.
@gwitko: I have created a pull request that adds this feature. It has been created with the help of codex and claude. If at any point it seems to be too much slop, feel free to immediately throw it back to me and I'll improve. I took a lot of time to review it multiple times and get it as simple as it gets with all those protocol quirks. But I am not really versed well in dart, so I can just hope it's not awful.
I tested this with 2 different yubikey firmware versions (5.7.1 and 5.4.3) on Android. Other supported hardware I do not possess.
Activity
PhilThurston commentedon Aug 4, 2026
I'd like to add my two cents to this feature request.
One of the primary reasons I use an Android SSH client is for emergency access while traveling. Unfortunately, I've had my phone stolen during a trip before. With my previous SSH client (terminus), replacing the phone meant generating a new FIDO2-backed SSH key, updating my servers, and then repeating the process again once I returned back home and had bought a permanent new phone.
It worked, but it was an huge burden during a shitty situation.
If Conduit supported downloading existing resident OpenSSH credentials from a FIDO2 authenticator (similar to ssh-keygen -K or ssh-add -K), the recovery process would be dramatically simpler.
I could purchase a replacement phone, install Conduit, recover the resident credential from my key, and immediately regain access to my infrastructure without generating new keys or modifying any servers configuration.
I understand the security trade-offs between resident and non-resident credentials. For many users, non-resident credentials are probably the better default. However, for a mobile emergency workflow, I believe resident credentials provide a significant usability advantage. In my case, the key is an apex flex nfc implant that is literally always with me, while my phone is the device most likely to be lost, stolen, or replaced.
Supporting resident credential discovery would make Conduit the best choice for admins who rely on OpenSSH FIDO2 credentials and need a portable, standards-based recovery workflow that isn't some proprietary junk that other apps use.
hhejkhalkfahjahsf commentedon Aug 5, 2026
I know "+1, me too" comments aren't exactly the finest contribution one can make to a GitHub issue, but I'll throw mine in anyway.
I don't keep anything particularly sensitive on the machines I SSH into, and strictly speaking there's not much there worth protecting. I use hardware keys mostly because I'm extremely lazy.
They've saved me from remembering passwords, dealing with password managers, moving SSH keys between devices, and other annoying bullshit.
The last missing piece for me is basically "ssh-keygen -K" on Android.
Once that's there, my laziness can finally be complete.
GGORG0 commentedon Aug 7, 2026
I'll just add that resident credentials can be used right now without any issues, they just can't be imported from the key itself. If you generate a resident credential on a pc and copy the "private" key (which contains no cryptographic material and is purely just a stub that tells OpenSSH about your key and how to find it, so it can even theoretically be published safely) to your phone, you can paste it into Conduit as an ed25519-sk private key and it will work just fine.
PhilThurston commentedon Aug 7, 2026
I think we're talking about two different use cases. I'm aware that copying the OpenSSH key handle (stub) from another machine works today. My request is specifically about eliminating the need for that stub in a disaster recovery scenario.
If my phone is stolen while traveling and my only remaining device is my FIDO2 authenticator, I want to be able to install Conduit on a replacement phone and recover the resident credential directly from the authenticator (like ssh-keygen -K or ssh-add -K) without requiring access to another computer or a backup of the stub file. The value of resident credentials is their portability, and from what you've written and I've seen it isn't implemented in conduit yet.
hhejkhalkfahjahsf commentedon Aug 7, 2026
That's true, but it's extra work. Computers were made to reduce manual work, not to create tasks like “go copy something from one place to another.”
GGORG0 commentedon Aug 8, 2026
Yup, that's exactly the point of this issue!
rschaffar commentedon Aug 14, 2026
@gwitko: I have created a pull request that adds this feature. It has been created with the help of codex and claude. If at any point it seems to be too much slop, feel free to immediately throw it back to me and I'll improve. I took a lot of time to review it multiple times and get it as simple as it gets with all those protocol quirks. But I am not really versed well in dart, so I can just hope it's not awful.
I tested this with 2 different yubikey firmware versions (5.7.1 and 5.4.3) on Android. Other supported hardware I do not possess.