4 ms·

I wrote a proprietary variation of this project for a large organization and used a similar approach to the author. The primary reason I used the browser for au

I wrote a proprietary variation of this project for a large organization and used a similar approach to the author. The primary reason I used the browser for authentication was to take advantage of FIDO U2F (Yubikeys). Openssh does support U2F authentication, but it requires the user to sign a public key with the hardware device, forcing the organization to again store users' public keys. The users disliked the redirects to and from the MFA provider just to log in and receive a signed SSH certificate, but there was no practical way to perform logins in the terminal without creating a whole new protocol and expanding the timeline of the project.

fc417fc802 2y ago
> without creating a whole new protocol Doesn't it "just" require a CLI client that can speak both FIDO U2F and whatever the MFA provider uses? But yeah point taken. Even if Google and Microsoft don't support it could a FOSS CLI client capable of speaking all the relevant protocols have resolved your issue? With OpenPubkey gaining support it seems to me that a service could potentially support exclusively that and in doing so cover all necessary auth methods simultaneously, at least assuming the provider is comfortable self hosting an IdP solution.
- linkregister 2y ago
  Indeed I would have preferred to interact with the U2F system libraries, create a challenge-response protocol for the registered U2F device to authenticate, and open source the effort. But I was not skilled enough at pitching the expanded scope. It would have been a more interesting project though! If I take a sabbatical then writing a client like that sounds interesting. Part of it would be inventing a new MFA provider, as the existing MFA APIs don't expose a "sign with U2F device" authentication method, as far as I know.
  - fc417fc802 2y ago
    At least pocket id and keycloak support fido2/webauthn; I'm sure there are others. I'm not sure how involved a CLI interface for that flow would be though. (Maybe someone has already done it? If so I didn't immediately come across it.) Keycloak for example provides an API for the password flow. So webauthn via API definitely isn't too far off of what it already provides.

fc417fc802 2y ago

> without creating a whole new protocol Doesn't it "just" require a CLI client that can speak both FIDO U2F and whatever the MFA provider uses? But yeah point taken. Even if Google and Microsoft don't support it could a FOSS CLI client capable of speaking all the relevant protocols have resolved your issue? With OpenPubkey gaining support it seems to me that a service could potentially support exclusively that and in doing so cover all necessary auth methods simultaneously, at least assuming the provider is comfortable self hosting an IdP solution.

linkregister 2y ago
Indeed I would have preferred to interact with the U2F system libraries, create a challenge-response protocol for the registered U2F device to authenticate, and open source the effort. But I was not skilled enough at pitching the expanded scope. It would have been a more interesting project though! If I take a sabbatical then writing a client like that sounds interesting. Part of it would be inventing a new MFA provider, as the existing MFA APIs don't expose a "sign with U2F device" authentication method, as far as I know.
- fc417fc802 2y ago
  At least pocket id and keycloak support fido2/webauthn; I'm sure there are others. I'm not sure how involved a CLI interface for that flow would be though. (Maybe someone has already done it? If so I didn't immediately come across it.) Keycloak for example provides an API for the password flow. So webauthn via API definitely isn't too far off of what it already provides.