Push mirror using public key authorization #8308

New Issue

GiteaMirror · 2025-11-02T08:01:50-06:00

GiteaMirror commented

2025-11-02 08:01:50 -06:00

Originally created by @SamWhited on GitHub (Jan 2, 2022).

Feature Description

Currently the push mirror feature only supports a username and a password for authentication. However, I would like to push to another Gitea instance (that has pull mirrors disabled), so it would be useful if it could also take an SSH key. This way, instead of giving one Gitea instance access to my entire account on the other Gitea instance I could setup a deploy key and use that to authorize access only to the repo that we're pushing to.

Screenshots

No response

Originally created by @SamWhited on GitHub (Jan 2, 2022). ### Feature Description Currently the push mirror feature only supports a username and a password for authentication. However, I would like to push to another Gitea instance (that has pull mirrors disabled), so it would be useful if it could also take an SSH key. This way, instead of giving one Gitea instance access to my entire account on the other Gitea instance I could setup a deploy key and use that to authorize access only to the repo that we're pushing to. ### Screenshots _No response_

GiteaMirror added the type/proposal label 2025-11-02 08:01:50 -06:00

GiteaMirror commented

2025-11-02 08:01:51 -06:00

@Konsonanz commented on GitHub (Feb 16, 2022):

+1, this is also a usecase for me.
I have a scenario where I'm managing packages on the Arch User Repository; I want to maintain the packages on gitea and push-mirror to the AUR. But AUR only allows write operations with ssh authentication.

Slightly related, AUR also only allows pushing to the master branch and to no other refs. Since currently there is no option to push-mirror only from/to selective branches, I wonder if gitea would fail here if not all refs can be pushed, or if at least the master branch would in fact be pushed to...

@Konsonanz commented on GitHub (Feb 16, 2022): +1, this is also a usecase for me. I have a scenario where I'm managing packages on the [Arch User Repository](https://aur.archlinux.org/); I want to maintain the packages on gitea and push-mirror to the AUR. But AUR only allows write operations with ssh authentication. Slightly related, AUR also only allows pushing to the master branch and to no other refs. Since currently there is no option to push-mirror only from/to selective branches, I wonder if gitea would fail here if not all refs can be pushed, or if at least the master branch would in fact be pushed to...

GiteaMirror commented

2025-11-02 08:01:51 -06:00

@Gusted commented on GitHub (Feb 16, 2022):

I think this is a nice addition and should be straight forward to implement(just a personal note on how to pass down the ssh key]. I do see a little thing that should be considered, while you're giving essentially a private key to gitea, it should be made clear to only add a deploy key which can be revoked at any time by the destination's push mirror, as we do not want to posses user's private keys.

@Gusted commented on GitHub (Feb 16, 2022): I think this is a nice addition and _should be_ straight forward to implement(just a [personal note](https://stackoverflow.com/questions/4565700/how-to-specify-the-private-ssh-key-to-use-when-executing-shell-command-on-git) on how to pass down the ssh key]. I do see a little thing that should be considered, while you're giving essentially a private key to gitea, it should be made clear to only add a deploy key which can be revoked at any time by the destination's push mirror, as we do not want to posses user's private keys.

GiteaMirror commented

2025-11-02 08:01:51 -06:00

@SamWhited commented on GitHub (Feb 16, 2022):

@Gusted An alternative UI that I had thought might be good is to have Gitea say "if you want us to push somewhere, authorize this public key". Ie. Gitea generates the private key and doesn't give the user access to it (or only does so in some sort of advanced settings interface where you can replace it with your own); this way the user who doesn't have some advanced deployment scheme in mind doesn't accidentally use their own private key without thinking the consequences through.

@SamWhited commented on GitHub (Feb 16, 2022): @Gusted An alternative UI that I had thought might be good is to have Gitea say "if you want us to push somewhere, authorize this public key". Ie. Gitea generates the private key and doesn't give the user access to it (or only does so in some sort of advanced settings interface where you can replace it with your own); this way the user who doesn't have some advanced deployment scheme in mind doesn't accidentally use their own private key without thinking the consequences through.

GiteaMirror commented

2025-11-02 08:01:51 -06:00

@Gusted commented on GitHub (Feb 17, 2022):

@SamWhited That's pretty handy UI, will see if I can fit this feature in this week

@Gusted commented on GitHub (Feb 17, 2022): @SamWhited That's pretty handy UI, will see if I can fit this feature in this week

GiteaMirror commented

2025-11-02 08:01:51 -06:00

@adamcstephens commented on GitHub (Feb 18, 2022):

I'd love to see this feature. Sourcehut doesn't allow pushing over HTTPS, so gitea can't currently push mirror there. Having ssh-based authentication would also allow scoping of access to Github on a per-repository basis, using deploy keys, versus the personal auth token which is given full access to all repos.

@adamcstephens commented on GitHub (Feb 18, 2022): I'd love to see this feature. Sourcehut doesn't allow pushing over HTTPS, so gitea can't currently push mirror there. Having ssh-based authentication would also allow scoping of access to Github on a per-repository basis, using deploy keys, versus the personal auth token which is given full access to all repos.

GiteaMirror commented

2025-11-02 08:01:52 -06:00

@lunny commented on GitHub (Feb 18, 2022):

We should have a secret store feature at first.

@lunny commented on GitHub (Feb 18, 2022): We should have a secret store feature at first.

GiteaMirror commented

2025-11-02 08:01:52 -06:00

@Gusted commented on GitHub (Feb 18, 2022):

We should have a secret store feature at first.

Why should we have that? Gitea generates the key and has to pass the private key to git anyway. I don't see the particular need of a secret store feature before this can become a thing.

But if such feature is really needed, how should it look like? Because encrypting it would need to be done by a secret key(most likely the one that's generated on startup). Even in such case it isn't really encrypted in my sense - as the gitea adminstrator will still be able see the contents and if a malicious attacker happen to get the files, it would also be able to retrieve the secret key via app.ini

@Gusted commented on GitHub (Feb 18, 2022): > We should have a secret store feature at first. Why should we have that? Gitea generates the key and has to pass the private key to git anyway. I don't see the particular need of a secret store feature before this can become a thing. But if such feature is _really needed_, how should it look like? Because encrypting it would need to be done by a secret key(most likely the one that's generated on startup). Even in such case it isn't really encrypted in my sense - as the gitea adminstrator will still be able see the contents and if a malicious attacker happen to get the files, it would also be able to retrieve the secret key via app.ini

GiteaMirror commented

2025-11-02 08:01:52 -06:00

@Gusted commented on GitHub (Feb 20, 2022):

I've created a draft PR for this, see #18835

@Gusted commented on GitHub (Feb 20, 2022): I've created a draft PR for this, see #18835

GiteaMirror commented

2025-11-02 08:01:52 -06:00

@techknowlogick commented on GitHub (Jul 19, 2025):

I have a PR for this here: https://github.com/go-gitea/gitea/pull/35089

@techknowlogick commented on GitHub (Jul 19, 2025): I have a PR for this here: https://github.com/go-gitea/gitea/pull/35089

Sign in to join this conversation.