Support actual ssh authentication

[nfebe]

Originally mentioned by @danfuzz via mail.

If you allowed folks to upload a public key to their accounts, then that could be used for authentication instead of a password, which is arguably much better from a security standpoint.

Details

Implement support for actual ssh public key authentication where the user can just upload their existing key(s) to permanent and the sftp can directly accepts requests from matching devices with the right private keys.

Related:

Permanent uses FusionAuth as IdP and hence for authentication and there a discussion in #175 about eliminating the password-flow by using an authentication token provided from FusionAuth.

[danfuzz]

Thanks for filing this on my behalf. FWIW I would wayyyy prefer the "actual request."

---

UPDATE: The above was a reply to the original issue report. (It's a bit of a nonsequitur now.)

[slifty]

FWIW the first portion of this ticket, by my read, is not SSH key authentication (which I believe is what this issue title indicates) but rather OAUTH authentication, so I think it would be better to separate them out.

Some of the additional context around ssh key authentication is that it would require permanent to support key management and would also involve some research into how / if FusionAuth would support that auth flow. All this is to say it would / will be a fairly heavy lift, but also feels like the most correct auth flow for SFTP as it is one of the most secure ways to accomplish auth and would solve our 2FA problems as well.

[jasonaowen]

would also involve some research into how / if FusionAuth would support that auth flow

I'd given this some thought, and I think it's both doable and worth doing.

FusionAuth does not support that auth flow, because that flow cuts FusionAuth out of the loop: the user is authenticating to sftp-service with credentials that FA does not have and cannot validate.

Instead, the back-end would need to be extended to allow known clients to act on behalf of a user without a token for that user. In that model, sftp-service would request a client credentials token from FusionAuth, present the token to the API along with a header or something indicating the user it is acting on behalf of, and then the API would validate the token, confirm it belongs to a trusted client, confirm with FusionAuth that that user is valid, and then proceed as normal.

• on a new ssh connection to sftp-service, sftp-service checks key against list of authorized keys to get user or deny connection
• sftp-service requests token from FusionAuth using the client credentials flow
• sftp-service makes requests to API using its client credentials token and indicating the current user
• API validates request
  • token is valid
  • token is issued to a known, trusted client
  • user is allowed to log in to FusionAuth
• API sets the current user and continues as normal

There's still an open question of where/how to store the public ssh keys; sftp-service needs to be able to get a complete list along with what user they map to, and the front-end needs to be able to do CRUD operations on the current user's key.

[nfebe]

FWIW the first portion of this ticket, by my read, is not SSH key authentication (which I believe is what this issue title indicates) but rather OAUTH authentication, so I think it would be better to separate them out.

Yep, I updated the ticket to make ssh authentication the mainline while mentioning the other stuff as some tangential. Since from the conversation here this seems like the best option if the auth flow would change, I have not created another ticket to fusion-auth-token flow. (That can be branched off from this ticket if we are decide to close this one as there's going to be only one flow)

Thanks for bring that up Dan.