Add support for authentication via ssh certificates and pub/privatekey #442
Labels
No Label
kind/breaking
kind/bug
kind/build
kind/dependency
kind/deployment
kind/docs
kind
enhancement
kind
feature
kind/proposal
kind
question
kind
refactor
kind/security
kind/testing
kind/translation
priority/critical
priority/high
priority/low
priority/medium
reviewed/duplicate
reviewed/invalid
reviewed/wontfix
skip-changelog
status/blocked
status/has-backport
status/has-pull
status/needs-backport
status/needs-feedback
status/needs-reviews
status/wip
upstream/gitea
upstream/sdk
No Milestone
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: gitea/tea#442
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "42wim/tea:sshcert"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This adds support for authentication using a SSH certificate and normal public keys when you've got an ssh-agent running that has this certificate or your public key loaded.
First question when creating a new login is to ask about the ssh certificates or public keys, when the answer is yes, we don't need to ask about tokens/usernames anymore.
depends (in order) on:
118a8fefb0
toac766ea945
Nice idea! Some quick remarks, even though the upstream changes are not done:
I'd make the interactive login flow like this:
do you have a token?
with a select promptlogin with.. [token/password/sshkey]
loginmethod == ssh_key
, prompt for ssh key (ideally also a select populated withssh-add -l
and keys in$HOME/.ssh/*.pub
?For non-interactive login, make only one of the set (password, ssh-key, token) required
Also not sure about the new fieldLogin.SSHCert
. Is it supposed to store the key material, its fingerprint? We already haveLogin.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
)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-sdkSo 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.Ah I see it now, thanks for clarifying!
Add support for authentication via ssh certificatesto WIP: Add support for authentication via ssh certificatesAs tea doesn't build against go-sdk master I've made a go-sdk PR againt go-sdk v0.15.0 here: gitea/go-sdk#592
So that this can be tested on current tea
WIP: Add support for authentication via ssh certificatesto WIP: Add support for authentication via ssh certificates and pub/privatekey70e2516f2a
to1502f26af5
@noerw fyi: I followed your suggestion wrt to the interactive login flow in my latest commit as I'm adding support for normal pubkeys and non-ssh-agent support too.
Had to black out some personal info, but screenshot is clear enough I think
WIP: Add support for authentication via ssh certificates and pub/privatekeyto Add support for authentication via ssh certificates and pub/privatekeyready for review, hopefully can be released with gitea 1.17 release :)
(ofcourse the go.mod must be changed, but it's included now for easy build/testing)
Updated to add support for encrypted ssh keys.
@ -64,2 +66,4 @@
gopkg.in/yaml.v3 v3.0.0-20200313102051-9f266ea9e77c // indirect
)
replace code.gitea.io/sdk/gitea => gitea.com/42wim/go-sdk/gitea v0.0.0-20220624190204-04147197ae82
sdk pull got merged
ok pulled in upstream go-sdk back
Can any of the maintainers can take a look to get this merged ?
@6543 maintainer edits is now active
@42wim nice, i'll push some commits later, fixing conflicts and refactoring a bit
@noerw as this pull and your refactoring is in the same milestone ... it wont be breaking change in any case ... so I'll merge it now and you can create a pull targeting main