-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ssh certificate support #12281
Add ssh certificate support #12281
Conversation
Support for this should be also added to built-in ssh server or at least support for this should be hidden if built-in ssh server is u |
@lafriks good point, just updated the PR by adding a It now shows it's not supported when running the builtin server. (and disabled when ssh is disabled) |
It would be great to add option to manage also CA certs in Gitea admin section to easier add support to built in ssh server later on |
@lafriks yes, but that should be for another PR :) |
If it is left out it will than later on become breaking change as it would not be possible to migrate automatically to new one |
I've added support for the builtin SSH. Added a new key Should I let gitea write into |
I would say that for extendability later on it would be better if Gitea would generate that file from setting value |
Updated and the ca file is now getting generated. |
|
We're actually using certificates on centos 6 too :-)
ed25519 support on the other hand.. |
Yeah, I too once manually compiled openssh just for ed25519 😉 |
I'm 99% sure I'm doing something wrong when testing this using opensshd in docker, but am having troubles figuring out what I'm doing wrong. Is anyone else able to test this scenario? |
@techknowlogick it was the 1% my fault, sorry :( |
As this depends on the content of TrustedUserCAKeys we should allow all signature algorithms as admins can choose the specific algorithm on their signing CA
Co-authored-by: Lauris BH <[email protected]>
pleace resolve conflicts :) |
@techknowlogick can you review again please? |
It would be nice to ad some Docs about ssh-certificate (tld howto and some "read more" links ...) |
@6543 something like #12281 (comment) ? |
@42wim would be a nice to have 👍 I think you can reuse parts of this comment ... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice ...!
still some docs like you described in your comment would be better ...
Codecov Report
@@ Coverage Diff @@
## master #12281 +/- ##
==========================================
- Coverage 42.60% 42.52% -0.09%
==========================================
Files 673 673
Lines 73862 74114 +252
==========================================
+ Hits 31470 31514 +44
- Misses 37275 37483 +208
Partials 5117 5117
Continue to review full report at Codecov.
|
docs could be a different PR |
@42wim ☝️ :) |
Fixes #12224
New KeyType
KeyTypePrincipal
and structPrincipalKey
is created.It's reusing the
PublicKey
table, changes are:KeyTypePrincipal
authorized_principals
file instead ofauthorized_keys
PublicKey
is modified so it doesn't write KeyTypes withKeyTypePrincipal
to the authorized_keys.New section is added to the SSH / GPG keys section.
The
sshd_config
is also modified by adding aAuthorizedPrincipalsFile
managed by gitea and aTrustedUserCAKeys
pointing to/data/ssh/trusted-user-ca-keys.pem
which should be managed by the gitea administrator. (this contains the publickey of the CA that signs your ssh certificates)Updates to the original PR:
SSH_TRUSTED_USER_CA_KEYS
option has been added to the config for specifying your CA keys (and have gitea manage them)SSH_TRUSTED_USER_CA_KEYS_FILENAME
has been added to the config for specifying the filename gitea will manage the CA keys inSSH_AUTHORIZED_PRINCIPALS_ALLOW
has been added to config which by default only allows principals that are equalto the user's email or username (to avoid malicious activity). Option to allow anything is also available