search

go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
45.17k stars 5.49k forks source link

automatically set SSH principal for users #28327

Open moo-im-a-cow opened 11 months ago

moo-im-a-cow commented 11 months ago

Feature Description

currently: if using ssh certificates, before first use, user needs to log into gitea on the web, go to settings, and type their gitea username into the principals field.

feature request: Add a global setting to automatically set the ssh principals linked to a user, based on their username or email (whichever one is enabled in SSH_AUTHORIZED_PRINCIPALS_ALLOW)

my environment has OIDC login, and oidc provisioned ssh keys, but currently after logging in, you need to go to the ssh settings page and add a principal for your username

My suggestion is to add a setting called SSH_AUTHORIZED_PRINCIPALS_FORCE, defaults to false. if this is set to true, then when a new (or existing) user signs in, gitea will set the principals to their username and/or email, user cant edit them, but can immediately push to gitea with their ssh certificate

Screenshots

No response

juliadin commented 7 months ago

I wanted to chime in supporting the proposal in general but making the point that there isn't necessarily only one setting enabled in SSH_AUTHORIZED_PRINCIPALS_ALLOW and a decision would be required how to handle this: adding the first, adding all ... something along those lines ...

I myself would find it nice if there was a way to create a default principal but still let the user add/remove others (and maybe protect the created default one from being changed or deleted)

Crumb5 commented 1 month ago

I agree with this as well. If we've already gone to the effort of setting up signed ssh certificates we've already considered what principals are to be used, it would be nice to define the principals in the flow without relying on users to copy and paste their email or username into their profile -> keys -> principals again.

To me it makes sense to have default principals set by the administrator, then toggle whether we allow the user to set their own principals ontop of / instead of that.

Something like:

SSH_ALLOW_CUSTOM_USER_PRINCIPALS: true/false SSH_ALLOW_DEFAULT_USER_PRINCIPALS: none,email,username,id