WIP: Add support for authentication via ssh certificates #442

Open
42wim wants to merge 1 commits from 42wim/tea:sshcert into master
42wim commented 2 months ago

This adds support for authentication using a SSH certificate when you've got an ssh-agent running that has this certificate loaded.

First question when creating a new login is to ask about the ssh certificates, when the answer is yes, we don't need to ask about tokens/usernames anymore.

depends (in order) on:

This adds support for authentication using a SSH certificate when you've got an ssh-agent running that has this certificate loaded. First question when creating a new login is to ask about the ssh certificates, when the answer is yes, we don't need to ask about tokens/usernames anymore. depends (in order) on: - https://github.com/go-gitea/gitea/pull/17565 - https://gitea.com/gitea/go-sdk/pulls/553
42wim added 1 commit 2 months ago
118a8fefb0
Add support for authentication via ssh certificates
42wim force-pushed sshcert from 118a8fefb0 to ac766ea945 2 months ago
Collaborator

Nice idea! Some quick remarks, even though the upstream changes are not done:

I'd make the interactive login flow like this:

  • replace the bool prompt do you have a token? with a select prompt login with.. [token/password/sshkey]
    • if loginmethod == ssh_key, prompt for ssh key (ideally also a select populated with ssh-add -l and keys in $HOME/.ssh/*.pub?
    • if not, do sshkey autodetection and prompt for key as already implemented

For non-interactive login, make only one of the set (password, ssh-key, token) required

Also not sure about the new field Login.SSHCert. Is it supposed to store the key material, its fingerprint? We already have Login.SSHKey which contains a path to a key, used for git operations when no ssh-agent auth succeeded.
Would be nice if we could consolidate both fields (but to support the ssh-agent usecase, we'd probably need to migrate away from storing key-paths in SSHKey)

Nice idea! Some quick remarks, even though the upstream changes are not done: I'd make the interactive login flow like this: - replace the bool prompt `do you have a token?` with a select prompt `login with.. [token/password/sshkey]` - if `loginmethod == ssh_key`, prompt for ssh key (ideally also a select populated with `ssh-add -l` and keys in `$HOME/.ssh/*.pub`? - if not, do sshkey autodetection and prompt for key as already implemented For non-interactive login, make only one of the set (password, ssh-key, token) required ~~Also not sure about the new field `Login.SSHCert`. Is it supposed to store the key material, its fingerprint? We already have `Login.SSHKey` which contains a path to a key, used for git operations when no ssh-agent auth succeeded. Would be nice if we could consolidate both fields (but to support the ssh-agent usecase, we'd probably need to migrate away from storing key-paths in `SSHKey`)~~
Poster

sshkey and ssh certificate is not the same in this setup.

The sshkey option can only do pull/clone but the ssh certificate has access to the whole API (it talks over http(s), not ssh, it uses the ssh certificate to sign http(s) requests)

The Login.SSHCert is a bool to see if we have it enabled or not, and if so it's given as an option to the NewClient in go-sdk

So I don't think it's a good idea to replace the bool prompt as you suggested. We can change it to: login with.. [token/password/sshkey/sshcert] if you want though.

sshkey and ssh certificate is not the same in this setup. The sshkey option can only do pull/clone but the ssh certificate has access to the whole API (it talks over http(s), not ssh, it uses the ssh certificate to sign http(s) requests) The Login.SSHCert is a bool to see if we have it enabled or not, and if so it's given as an option to the `NewClient` in go-sdk So I don't think it's a good idea to replace the bool prompt as you suggested. We can change it to: `login with.. [token/password/sshkey/sshcert]` if you want though.
Collaborator

Ah I see it now, thanks for clarifying!

Ah I see it now, thanks for clarifying!
noerw changed title from Add support for authentication via ssh certificates to WIP: Add support for authentication via ssh certificates 2 months ago
noerw added the
upstream/gitea
label 2 months ago
noerw added the
kind/feature
label 2 months ago
Some checks failed
continuous-integration/drone/pr Build is failing
Required
Details
This pull request is marked as a work in progress.
This branch is out-of-date with the base branch
Sign in to join this conversation.
Loading…
There is no content yet.