Allow admins to manage user SSH keys #1597

New Issue

GiteaMirror · 2025-11-02T04:06:07-06:00

GiteaMirror commented

2025-11-02 04:06:07 -06:00

Originally created by @jerrykan on GitHub (Mar 6, 2018).

We run gitea internally and have set up a few "service accounts" for systems that interact with the git repositories. One of the pain points with doing this is that you have to log in as the service account to manage the ssh keys associated with the account.

Ideally it would be good if an admin user had access to be able to able to manage the public ssh keys of the users.

I would also be open to the idea of having a separate service/integrations account type so that admins would only be able to manage keys for those types of accounts, instead of all of the normal users.

I am aware that deploy keys could be used for this sort of thing, but being able to add a service account to a repository provides a lot more visibility as to which systems have access to a repository. It also makes key management a lot easier if the keys need to be updated.

Originally created by @jerrykan on GitHub (Mar 6, 2018). We run gitea internally and have set up a few "service accounts" for systems that interact with the git repositories. One of the pain points with doing this is that you have to log in as the service account to manage the ssh keys associated with the account. Ideally it would be good if an admin user had access to be able to able to manage the public ssh keys of the users. I would also be open to the idea of having a separate service/integrations account type so that admins would only be able to manage keys for those types of accounts, instead of all of the normal users. I am aware that deploy keys could be used for this sort of thing, but being able to add a service account to a repository provides a lot more visibility as to which systems have access to a repository. It also makes key management a lot easier if the keys need to be updated.

GiteaMirror added the type/feature issue/confirmed labels 2025-11-02 04:06:07 -06:00

GiteaMirror commented

2025-11-02 04:06:08 -06:00

@nvx commented on GitHub (Jan 1, 2019):

Due to the limitations of deploy keys (max one per repo as per #3959, can't add them to organisations, etc) I find myself using this pattern.

Either this needs to happen, or deploy keys need to be revamped to provide similar experience (think of a CI/CD user usecase).

@nvx commented on GitHub (Jan 1, 2019): Due to the limitations of deploy keys (max one per repo as per #3959, can't add them to organisations, etc) I find myself using this pattern. Either this needs to happen, or deploy keys need to be revamped to provide similar experience (think of a CI/CD user usecase).

GiteaMirror commented

2025-11-02 04:06:08 -06:00

@immanuelfodor commented on GitHub (Jan 22, 2019):

I just needed to create a service account with random scrambled password wanting to add an SSH key later to it, then realized, I need to change it to something I know to be able to login to the new account, add the key, then set up the random password again. Came here right after to see if this issue has already been added or I need to create it myself. Thanks for the original report, this one should worth take a look by the team.

@immanuelfodor commented on GitHub (Jan 22, 2019): I just needed to create a service account with random scrambled password wanting to add an SSH key later to it, then realized, I need to change it to something I know to be able to login to the new account, add the key, then set up the random password again. Came here right after to see if this issue has already been added or I need to create it myself. Thanks for the original report, this one should worth take a look by the team.

GiteaMirror commented

2025-11-02 04:06:08 -06:00

@stale[bot] commented on GitHub (Mar 23, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Mar 23, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 04:06:09 -06:00

@immanuelfodor commented on GitHub (Mar 23, 2019):

So many thumbs up and hearts, I think this feature request should be kept open.

@immanuelfodor commented on GitHub (Mar 23, 2019): So many thumbs up and hearts, I think this feature request should be kept open.

GiteaMirror commented

2025-11-02 04:06:09 -06:00

@zeripath commented on GitHub (Mar 24, 2019):

There are multiple ways of working around this:

If you manage your users in LDAP we can import SSH keys from that.
Use the API /admin/users/:username/keys or with the sudo option /user/keys?sudo=:username

@zeripath commented on GitHub (Mar 24, 2019): There are multiple ways of working around this: * If you manage your users in LDAP we can import SSH keys from that. * Use the API `/admin/users/:username/keys` or with the sudo option `/user/keys?sudo=:username`

GiteaMirror commented

2025-11-02 04:06:09 -06:00

@immanuelfodor commented on GitHub (Mar 25, 2019):

I don't have LDAP, but if there is an API for that, it should be relatively easy to create a frontend to it

@immanuelfodor commented on GitHub (Mar 25, 2019): I don't have LDAP, but if there is an API for that, it should be relatively easy to create a frontend to it

GiteaMirror commented

2025-11-02 04:06:09 -06:00

@zeripath commented on GitHub (Mar 25, 2019):

BTW The referenced #3959 deploy key limitations should no longer be a problem - so if you only need to push/pull you don't actually need an account and can use deploy keys.

@zeripath commented on GitHub (Mar 25, 2019): BTW The referenced #3959 deploy key limitations should no longer be a problem - so if you only need to push/pull you don't actually need an account and can use deploy keys.

GiteaMirror commented

2025-11-02 04:06:10 -06:00

@immanuelfodor commented on GitHub (Mar 25, 2019):

Wow, great news, I was not aware of that one!

@immanuelfodor commented on GitHub (Mar 25, 2019): Wow, great news, I was not aware of that one!

GiteaMirror commented

2025-11-02 04:06:10 -06:00

@zeripath commented on GitHub (Mar 25, 2019):

The fix was in #5939 and I explain my understanding of how keys are supposed to work there.

@zeripath commented on GitHub (Mar 25, 2019): The fix was in #5939 and I explain my understanding of how keys are supposed to work there.

GiteaMirror commented

2025-11-02 04:06:10 -06:00

@nvx commented on GitHub (Mar 27, 2019):

#5939 solves my use-case so the ability for admins to manage user SSH keys is no longer needed by me.

@nvx commented on GitHub (Mar 27, 2019): #5939 solves my use-case so the ability for admins to manage user SSH keys is no longer needed by me.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#1597