Allow admin to set default SSH certificate principal(s)

[andrewheberle]

What problem would this solve?

1. A reduction in manual and repeated per user steps to allow the use of SSH certificates for authentication.
2. Allowing an admin to lock down the use of SSH certificates

What do you propose?

This is a request to implement the feature in issue #28327 that was closed by PR #34978

That PR marked the noted issue as being closed if it was merged but that is not the case as it dit not implement anything to allow an admin to default/force/set accepted principals used for SSH certificate authentication that I can see.

So this is a (re-)request for a couple new configuration options in the [server] section similar to the following:

• SSH_ALLOW_DEFAULT_USER_PRINCIPALS which accepts none (default), email or username that sets a default principal on user creation if SSH certificate authentication is enabled
• SSH_ALLOW_CUSTOM_USER_PRINCIPALS that accepts true (default) or false which allows the user to add/delete their own SSH certificate principals

For example having SSH_ALLOW_DEFAULT_USER_PRINCIPALS=username and SSH_ALLOW_CUSTOM_USER_PRINCIPALS=false would allow a newly created user who possesses a valid and trusted SSH certificate (based on SSH_TRUSTED_USER_CA_KEYS) to have seamless access via SSH if their certificate contains a user id matching their Gitea username while also preventing the accidental (or deliberate) access for another user access using an alternate principal by preventing them making changes to this setting (ie they cannot add “badactor” as an allowed principal)