Share SSH key between accounts #11587

Originally created by @crabdancing on GitHub (Sep 4, 2023).

Feature Description

Currently, Gitea relies on the SSH key itself to figure out which account you're logging in as. This is something of a de facto standard with SSH git accounts, but it seems unnecessarily limiting. Since Gitea has an internal git server, there's in principle no reason we couldn't use the account name provided via SSH protocol have multiple accounts share the same git key, and ID by git 'account name' instead of key. This significantly improves flexibility, when setting up nontrivial secure passwordless local development environments, allowing an intersection of resource access, with access authorization being denoted by being given a specific keypair.

Screenshots

No response

Originally created by @crabdancing on GitHub (Sep 4, 2023). ### Feature Description Currently, Gitea relies on the SSH key itself to figure out which account you're logging in as. This is something of a de facto standard with SSH git accounts, but it seems unnecessarily limiting. Since Gitea has an internal git server, there's in principle no reason we couldn't use the account name provided via SSH protocol have _multiple_ accounts share the same git key, and ID by git 'account name' instead of key. This significantly improves flexibility, when setting up nontrivial secure passwordless local development environments, allowing an intersection of resource access, with access authorization being denoted by being given a specific keypair. ### Screenshots _No response_

GiteaMirror added the type/proposal label 2025-11-02 09:41:49 -06:00

GiteaMirror closed this issue

GiteaMirror commented

@lunny commented on GitHub (Sep 4, 2023):

I don't know how it works. Once two public keys matched, which user should we think it is doing?

@lunny commented on GitHub (Sep 4, 2023): I don't know how it works. Once two public keys matched, which user should we think it is doing?

GiteaMirror commented

@crabdancing commented on GitHub (Sep 4, 2023):

If the user signs in as, e.g., alice@git.something.com, then you look for an account name exactly matching alice. For backward compatibility, if the SSH name is git, you revert to trying to match by key instead of by git name.

@crabdancing commented on GitHub (Sep 4, 2023): If the user signs in as, e.g., `alice@git.something.com`, then you look for an account name exactly matching `alice`. For backward compatibility, if the SSH name is `git`, you revert to trying to match by key instead of by git name.

GiteaMirror commented

@lunny commented on GitHub (Sep 5, 2023):

if the SSH name is git, you revert to trying to match by key instead of by git name.

It's impossible from technique.

@lunny commented on GitHub (Sep 5, 2023): > if the SSH name is git, you revert to trying to match by key instead of by git name. It's impossible from technique.

GiteaMirror commented

https://betterprogramming.pub/how-to-set-up-multiple-ssh-keys-ae6688f76570

@CaiCandong commented on GitHub (Sep 5, 2023):

@alxpettit I guess your question is, "How To Set Up Multiple SSH Keys on Your Computer"?

@CaiCandong commented on GitHub (Sep 5, 2023): @alxpettit I guess your question is, "How To Set Up Multiple SSH Keys on Your Computer"? https://betterprogramming.pub/how-to-set-up-multiple-ssh-keys-ae6688f76570

GiteaMirror commented

@amrsoll commented on GitHub (Sep 5, 2023):

@alxpettit You should consider making multiple ssh keypairs instead of using a single ssh keypair to auth as 2 different users. It is fundamentally the opposite intent to using private-public encryption keypairs.

✔️ One user can have multiple ssh keys

❌ Multiple users share one ssh keypair

They are not 'git keys', and it is not a limitation of git (as you point out) but a limitation of the security scheme.

You could generate a new key pair for every user you choose to generate for your dev environment. By tweaking .ssh/config, you can create a host definition for each use case, using a different ssh key previously generated

Host git_user_a
    Hostname gitea.com
    IdentityFile ~/.ssh/id_user_a
    IdentitiesOnly yes
Host git_user_b
    Hostname gitea.com
    IdentityFile ~/.ssh/id_user_b
    IdentitiesOnly yes

You can then setup multiple remotes in git, each one would be pushing as a different user

git remote add origin_a git@git_user_a:myrepo.git
git remote add origin_b git@git_user_b:myrepo.git

Then use the remotes with the git actions

git push origin_a master # push to gitea.com:myrepo.git using the ssh key ~/.ssh/id_user_a

See StackOverflow for more info on how to setup the ssh config file and use it with git

@amrsoll commented on GitHub (Sep 5, 2023): @alxpettit You should consider making multiple ssh keypairs instead of using a single ssh keypair to auth as 2 different users. It is fundamentally the opposite intent to using private-public encryption keypairs. ✔️ One user can have multiple ssh keys ❌ Multiple users share one ssh keypair They are not 'git keys', and it is not a limitation of git (as you point out) but a limitation of the security scheme. You could generate a new key pair for every user you choose to generate for your dev environment. By tweaking `.ssh/config`, you can create a host definition for each use case, using a different ssh key previously generated ``` Host git_user_a Hostname gitea.com IdentityFile ~/.ssh/id_user_a IdentitiesOnly yes Host git_user_b Hostname gitea.com IdentityFile ~/.ssh/id_user_b IdentitiesOnly yes ``` You can then setup multiple remotes in git, each one would be pushing as a different user ```sh git remote add origin_a git@git_user_a:myrepo.git git remote add origin_b git@git_user_b:myrepo.git ``` Then use the remotes with the git actions ```sh git push origin_a master # push to gitea.com:myrepo.git using the ssh key ~/.ssh/id_user_a ``` See [StackOverflow](https://stackoverflow.com/a/11251797/11136955) for more info on how to setup the ssh config file and use it with git

GiteaMirror commented

@wxiaoguang commented on GitHub (Sep 5, 2023):

Duplicate of #21141

SSH key shouldn't be shared by different users.

@wxiaoguang commented on GitHub (Sep 5, 2023): Duplicate of #21141 SSH key shouldn't be shared by different users.

GiteaMirror commented

@lunny commented on GitHub (Sep 5, 2023):

I think this could be closed as it's impossible.

@lunny commented on GitHub (Sep 5, 2023): I think this could be closed as it's impossible.

GiteaMirror commented

@crabdancing commented on GitHub (Sep 6, 2023):

This is far from impossible, but okay...

@crabdancing commented on GitHub (Sep 6, 2023): This is far from impossible, but okay...

GiteaMirror commented

2025-11-02 09:41:51 -06:00

@wxiaoguang commented on GitHub (Sep 6, 2023):

This is far from impossible, but okay...

If you think it is possible, you could try to write some code to implement it to see whether it is really possible at the moment.

@wxiaoguang commented on GitHub (Sep 6, 2023): > This is far from impossible, but okay... If you think it is possible, you could try to write some code to implement it to see whether it is really possible at the moment.

GiteaMirror commented

@crabdancing commented on GitHub (Sep 6, 2023):

For context, I am a NixOS user, managing dozens of systems, each of which have their own SSH keys. If I had a single SSH key per Gitea user account, per computer, I would multiply the keys by a factor of at least 4. Given that there's already 10 machines, and more being added to the cluster, the solutions posited here are frankly somewhat ridiculous. (Also a little condescending to assume I don't know how to use SSH.)

I can automatically generate a keypair for every Gitea user on every machine, and then write code specifically to pull the keypairs for every user on every machine that ought to have access to a specific git resource, and integrate it into the database via the available shell commands -- and then additionally make sure that's updated when keys expire. It seems much simpler to just share the damn key across multiple Gitea user accounts, in contexts where a given machine has the same security profile and trust level.

I understand that perhaps Gitea is written into a corner on this one and it would be prohibitively difficult to do the necessary refactoring to implement, but honestly I wish people would have just said that, instead of inexplicably trying to teach me the basics of SSH or flatly declare it impossible.

@crabdancing commented on GitHub (Sep 6, 2023): For context, I am a NixOS user, managing dozens of systems, each of which have their own SSH keys. If I had a single SSH key per Gitea user account, per computer, I would multiply the keys by a factor of at least 4. Given that there's already 10 machines, and more being added to the cluster, the solutions posited here are frankly somewhat ridiculous. (Also a little condescending to assume I don't know how to use SSH.) I can automatically generate a keypair for every Gitea user on every machine, and then write code specifically to pull the keypairs for every user on every machine that ought to have access to a specific git resource, and integrate it into the database via the available shell commands -- and then additionally make sure that's updated when keys expire. It seems much simpler to _just share the damn key_ across multiple Gitea user accounts, in contexts where a given machine has the same security profile and trust level. I understand that perhaps Gitea is written into a corner on this one and it would be prohibitively difficult to do the necessary refactoring to implement, but honestly I wish people would have just said that, instead of inexplicably trying to teach me the basics of SSH or flatly declare it impossible.

GiteaMirror commented

2025-11-02 09:41:51 -06:00

@wxiaoguang commented on GitHub (Sep 6, 2023):

For context, I am a NixOS user, managing dozens of systems, each of which have their own SSH keys. If I had a single SSH key per Gitea user account, per computer, I would multiply the keys by a factor of at least 4.

There is "deploy key" feature, which is not limited to any user.

@wxiaoguang commented on GitHub (Sep 6, 2023): > For context, I am a NixOS user, managing dozens of systems, each of which have their own SSH keys. If I had a single SSH key per Gitea user account, per computer, I would multiply the keys by a factor of at least 4. There is "deploy key" feature, which is not limited to any user.

GiteaMirror commented

2025-11-02 09:41:51 -06:00

@crabdancing commented on GitHub (Sep 6, 2023):

So, my understanding is:

Gitea users are the only way to acquire access to resources
Although Gitea supports asymmetric cryptographic keys, it does not want to make a distinction between the key, and the user with which that key is associated.
Therefore, scenarios where resources are shared with minimum duplication of entries are impossible without significant refactoring.

To get an idea of what I am trying to implement, and why it would be troublesome to implement, see this diagram:

I would, given what I currently know about Gitea (which may well be incomplete. I would be happy to be informed otherwise), presumably have to do something like this:

This is of course, ridiculous.

The only alternative I can think of is to share the SSH keys across machines -- having a single SSH key per resource, instead of per which imposes several unreasonable limitations on this security model. For one, if a single machine is suspected of being compromised, the SSH key must be revoked for all the machines, and then a replacement must be redistributed.

Or I could have an instance of Gitea for every resource. But that's even more absurd.

@crabdancing commented on GitHub (Sep 6, 2023): So, my understanding is: 1) Gitea users are the only way to acquire access to resources 2) Although Gitea supports asymmetric cryptographic keys, it does _not_ want to make a distinction between the key, and the user with which that key is associated. 3) Therefore, scenarios where resources are _shared_ with minimum duplication of entries are impossible without significant refactoring. To get an idea of what I am trying to implement, and why it would be troublesome to implement, see this diagram: ![Untitled Diagram drawio](https://github.com/go-gitea/gitea/assets/28266167/cddcd883-4547-47b4-8418-4bd060042248) I would, given what I _currently_ know about Gitea (which may well be incomplete. I would be happy to be informed otherwise), presumably have to do something like this: ![Untitled Diagram drawio2](https://github.com/go-gitea/gitea/assets/28266167/8b3e75b6-0657-482c-8720-996a078a658d) This is of course, ridiculous. The only alternative I can think of is to share the SSH keys across machines -- having a _single_ SSH key per resource, instead of per which imposes several unreasonable limitations on this security model. For one, if a single machine is suspected of being compromised, the SSH key must be revoked for _all_ the machines, and then a replacement must be redistributed. Or I could have an instance of Gitea for every resource. But that's even more absurd.

GiteaMirror commented

@crabdancing commented on GitHub (Sep 6, 2023):

For context, I am a NixOS user, managing dozens of systems, each of which have their own SSH keys. If I had a single SSH key per Gitea user account, per computer, I would multiply the keys by a factor of at least 4.

There is "deploy key" feature, which is not limited to any user.

Deploy key? This is news to me! So I could have them be per-project, and forego the accounts entirely? Sorry, I must have missed that. I guess my use case may be covered after all. Thank you for informing me @wxiaoguang!

@crabdancing commented on GitHub (Sep 6, 2023): > > For context, I am a NixOS user, managing dozens of systems, each of which have their own SSH keys. If I had a single SSH key per Gitea user account, per computer, I would multiply the keys by a factor of at least 4. > > There is "deploy key" feature, which is not limited to any user. Deploy key? This is news to me! So I could have them be per-project, and forego the accounts entirely? Sorry, I must have missed that. I guess my use case may be covered after all. Thank you for informing me @wxiaoguang!

GiteaMirror commented

@wxiaoguang commented on GitHub (Sep 6, 2023):

So, my understanding is:

1. Gitea users are the only way to acquire access to resources

Almost, except "Deploy Key" or some other internal mechanisms.

2. Although Gitea supports asymmetric cryptographic keys, it does _not_ want to make a distinction between the key, and the user with which that key is associated.

Gitea distinguishes the SSH keys. Each SSH key should bind to a user (except Deploy Key).

Then, Gitea needs to use the "SSH key user" to find their org / team / repo, etc, to check permissions.

And at the moment, Gitea also supports external SSH server (OpenSSH), which has to only use one pre-defined SSH user to communicate (eg: git@git-server, but not any-user@git-server).

If you would like to "share" SSH keys between users, then:

The permission problem: how to check a SSH key's permission it binds to different users? A lot of code is written based on the above design.
The "current user" problem: if you would like to use "alice@git-server" and "bob@git-server" with the same SSH key, how to make OpenSSH work and not break end users?
What's the complicity of the “shared SSH key" implementation? Anyone is willing and is able to maintain it?

None of these problem looks like an easy "possible" problem. They might be able to be done, but the question is the balance of the feasibility / benefit / cost.

@wxiaoguang commented on GitHub (Sep 6, 2023): > So, my understanding is: > > 1. Gitea users are the only way to acquire access to resources Almost, except "Deploy Key" or some other internal mechanisms. > 2. Although Gitea supports asymmetric cryptographic keys, it does _not_ want to make a distinction between the key, and the user with which that key is associated. Gitea distinguishes the SSH keys. Each SSH key should bind to a user (except Deploy Key). Then, Gitea needs to use the "SSH key user" to find their org / team / repo, etc, to check permissions. And at the moment, Gitea also supports external SSH server (OpenSSH), which has to only use one pre-defined SSH user to communicate (eg: `git@git-server`, but not `any-user@git-server`). If you would like to "share" SSH keys between users, then: 1. The permission problem: how to check a SSH key's permission it binds to different users? A lot of code is written based on the above design. 2. The "current user" problem: if you would like to use "alice@git-server" and "bob@git-server" with the same SSH key, how to make OpenSSH work and not break end users? 3. What's the complicity of the “shared SSH key" implementation? Anyone is willing and is able to maintain it? None of these problem looks like an easy "possible" problem. They might be able to be done, but the question is the balance of the feasibility / benefit / cost.

GiteaMirror commented

@wxiaoguang commented on GitHub (Sep 6, 2023):

The "Deploy Key" feature is here:

@wxiaoguang commented on GitHub (Sep 6, 2023): The "Deploy Key" feature is here: ![image](https://github.com/go-gitea/gitea/assets/2114189/da734a21-74b4-41b0-b3e0-a8afa738470e)

GiteaMirror commented

@crabdancing commented on GitHub (Sep 6, 2023):

Yup. Thanks :)

Looks like the reason I missed it, is because I didn't realize it allowed for write access. That's super useful! :)

Thank you for your time.

@crabdancing commented on GitHub (Sep 6, 2023): Yup. Thanks :) Looks like the reason I missed it, is because I didn't realize it allowed for write access. That's super useful! :) Thank you for your time.

GiteaMirror commented

@crabdancing commented on GitHub (Sep 6, 2023):

Err... may have celebrated a bit too early. What am I doing wrong?

Edit: looks like it's exactly what it says on the tin. I would have expected to be able to use my primary machine key as a deploy key, but I guess I'm going to have to make sure they're not attached to any of the Gitea accounts. Doesn't seem like too much of a complication though 🤔

Edit 2: Looks like the deploy keys can't be controlled through the Gitea command line interface, so if I have, say, thirty projects and I'm trying to synchronize 4 machine keys on all of them, this may become prohibitively difficult after all. Is there a solution to this?

@crabdancing commented on GitHub (Sep 6, 2023): ![image](https://github.com/go-gitea/gitea/assets/28266167/3c3c87b8-c226-40fe-8cdf-42c704e1ec9c) Err... may have celebrated a bit too early. What am I doing wrong? Edit: looks like it's exactly what it says on the tin. I would have expected to be able to use my primary machine key as a deploy key, but I guess I'm going to have to make sure they're not attached to any of the Gitea accounts. Doesn't seem like too much of a complication though :thinking: Edit 2: Looks like the deploy keys [can't be controlled through the Gitea command line interface](https://docs.gitea.com/administration/command-line), so if I have, say, thirty projects and I'm trying to synchronize 4 machine keys on all of them, this may become prohibitively difficult after all. Is there a solution to this?

GiteaMirror commented

@amrsoll commented on GitHub (Sep 6, 2023):

use the account name provided via SSH protocol have multiple accounts share the same git key, and ID by git 'account name' instead of key

One would usually understand that you were binding real peoples accounts to a single ssh key. Albeit not being the case, it still merited the clarification.

To get an idea of what I am trying to implement, and why it would be troublesome to implement, see this diagram:

Is one distinct account+ssh key/machine not sufficient for your use case? Say user_machine1 has ssk_key1 and granted permission to ressouce 1 and 2 in your example. It is less elegant than the deploy key but probably accessible through the API

@amrsoll commented on GitHub (Sep 6, 2023): > use the account name provided via SSH protocol have multiple accounts share the same git key, and ID by git 'account name' instead of key One would usually understand that you were binding real peoples accounts to a single ssh key. Albeit not being the case, it still merited the clarification. > To get an idea of what I am trying to implement, and why it would be troublesome to implement, see this diagram: Is one distinct account+ssh key/machine not sufficient for your use case? Say user_machine1 has ssk_key1 and granted permission to ressouce 1 and 2 in your example. It is less elegant than the deploy key but probably accessible through the API

GiteaMirror commented

@wxiaoguang commented on GitHub (Sep 6, 2023):

Edit 2: Looks like the deploy keys can't be controlled through the Gitea command line interface, so if I have, say, thirty projects and I'm trying to synchronize 4 machine keys on all of them, this may become prohibitively difficult after all. Is there a solution to this?

I think maybe it could add some APIs for managing the deploy keys?

@wxiaoguang commented on GitHub (Sep 6, 2023): > Edit 2: Looks like the deploy keys [can't be controlled through the Gitea command line interface](https://docs.gitea.com/administration/command-line), so if I have, say, thirty projects and I'm trying to synchronize 4 machine keys on all of them, this may become prohibitively difficult after all. Is there a solution to this? I think maybe it could add some APIs for managing the deploy keys?

GiteaMirror commented

@crabdancing commented on GitHub (Sep 6, 2023):

use the account name provided via SSH protocol have multiple accounts share the same git key, and ID by git 'account name' instead of key

One would usually understand that you were binding real peoples accounts to a single ssh key. Albeit not being the case, it still merited the clarification.

To get an idea of what I am trying to implement, and why it would be troublesome to implement, see this diagram:

Is one distinct account+ssh key/machine not sufficient for your use case? Say user_machine1 has ssk_key1 and granted permission to ressouce 1 and 2 in your example. It is less elegant than the deploy key but probably accessible through the API

So, if I have 50 machines & 50 resources, I simply automatically create 2500 accounts? That would technically work, but the scalability is simply not there. The number of accounts grows as the product of machines & resources.

@crabdancing commented on GitHub (Sep 6, 2023): > > use the account name provided via SSH protocol have multiple accounts share the same git key, and ID by git 'account name' instead of key > > One would usually understand that you were binding real peoples accounts to a single ssh key. Albeit not being the case, it still merited the clarification. > > > To get an idea of what I am trying to implement, and why it would be troublesome to implement, see this diagram: > > Is one distinct account+ssh key/machine not sufficient for your use case? Say user_machine1 has ssk_key1 and granted permission to ressouce 1 and 2 in your example. It is less elegant than the deploy key but probably accessible through the API So, if I have 50 machines & 50 resources, I simply automatically create 2500 accounts? That would technically work, but the scalability is simply not there. The number of accounts grows as the product of machines & resources.

GiteaMirror commented

@amrsoll commented on GitHub (Sep 6, 2023):

No, I was thinking 1 account per machine. Those accounts would have access to however many resources they are allowed to. Each of those accounts have 1 key, i.e. 1 key per machine.

@amrsoll commented on GitHub (Sep 6, 2023): No, I was thinking 1 account per machine. Those accounts would have access to however many resources they are allowed to. Each of those accounts have 1 key, i.e. 1 key per machine.

GiteaMirror commented