[FR] SSH mirror option #7589

New Issue

GiteaMirror · 2025-11-02T07:30:39-06:00

GiteaMirror commented

2025-11-02 07:30:39 -06:00

Originally created by @adyanth on GitHub (Jul 15, 2021).

Gitea version (or commit ref): all
Git version: all
Operating system: all
Database (use [x]): all
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
Log gist: N/A

Description

This is a feature request to include SSH based remote mirrors on Gitea. Gitlab provides this option here

There is a very good use case for this, since these configurations are per repository. Github and others already provide Deploy keys with write access, which are SSH keys allowed access only to that repository. This can be used for the remote mirror without providing a Personal token which has user wide access and needs to be created and tracked for each mirror.

Ideally Gitea should also generate and use a new SSH key for each mirror since I believe there is a limitation on adding the same key in multiple places. But that is also how Gitlab has implemented it, where they provide the key that will be used for this mirror instance.

Screenshots

Originally created by @adyanth on GitHub (Jul 15, 2021). - Gitea version (or commit ref): all - Git version: all - Operating system: all - Database (use `[x]`): all - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [X] Yes (provide example URL) - [ ] No - Log gist: N/A    ## Description This is a feature request to include SSH based remote mirrors on Gitea. Gitlab provides this option [here](https://docs.gitlab.com/ee/user/project/repository/repository_mirroring.html#push-to-a-remote-repository) There is a very good use case for this, since these configurations are per repository. Github and others already provide Deploy keys with write access, which are SSH keys allowed access only to that repository. This can be used for the remote mirror without providing a Personal token which has user wide access and needs to be created and tracked for each mirror. Ideally Gitea should also generate and use a new SSH key for each mirror since I believe there is a limitation on adding the same key in multiple places. But that is also how Gitlab has implemented it, where they provide the key that will be used for this mirror instance. ## Screenshots

GiteaMirror closed this issue

2025-11-02 07:30:39 -06:00

GiteaMirror commented

2025-11-02 07:30:40 -06:00

@ansemjo commented on GitHub (Aug 7, 2021):

+1 on this ..

Mirroring via HTTPS using username and password/token is implemented in #15157 (available since 1.15.0-rc1) but that does not allow the ssh:// protocol. There is a couple of post-receive hooks in #3480, which can be adapted to use pubkey authentication instead of username:password. Ideally, this would also be combined with #16579.

I want to mirror a number of repositories to my GitHub account and don't want to create separate keys / tokens for each. So this is how I am currently doing it:

login as the git/gitea user and generate a new key, e.g. with ssh-keygen -t ed25519 -C "gitea mirroring" -f ~/.ssh/id_ed25519 -N ""
add this key to your GitHub account
try ssh git@github.com once to accept the hostkey and make sure GitHub recognizes you
enable git hooks in gitea
add the following post-receive hook to repositories:

#!/usr/bin/env bash
git push --mirror --quiet git@github.com:username/repository.git &>/dev/null &
echo "GitHub mirror initiated .."

I've used a selfhosted GitLab before and I could just configure push mirrors using URLs like ssh://git@github.com/username/repository.git and leave username and password blank with the above key-based method. I agree that generating a separate key per repository and printing the public key would be useful, too.

@ansemjo commented on GitHub (Aug 7, 2021): +1 on this .. Mirroring via HTTPS using username and password/token is implemented in #15157 (available since `1.15.0-rc1`) but that does not allow the `ssh://` protocol. There is a couple of `post-receive` hooks in #3480, which can be adapted to use pubkey authentication instead of `username:password`. Ideally, this would also be combined with #16579. I want to mirror a number of repositories to my GitHub account and don't want to create separate keys / tokens for each. So this is how I am currently doing it: * login as the `git`/`gitea` user and generate a new key, e.g. with `ssh-keygen -t ed25519 -C "gitea mirroring" -f ~/.ssh/id_ed25519 -N ""` * add this key to your GitHub account * try `ssh git@github.com` once to accept the hostkey and make sure GitHub recognizes you * enable git hooks in gitea * add the following `post-receive` hook to repositories: ```bash #!/usr/bin/env bash git push --mirror --quiet git@github.com:username/repository.git &>/dev/null & echo "GitHub mirror initiated .." ``` I've used a selfhosted GitLab before and I could just configure push mirrors using URLs like `ssh://git@github.com/username/repository.git` and leave username and password blank with the above key-based method. I agree that generating a separate key per repository and printing the public key would be useful, too.

GiteaMirror commented

2025-11-02 07:30:40 -06:00

@zeripath commented on GitHub (Aug 7, 2021):

Please read my comments on #1635 https://github.com/go-gitea/gitea/issues/1635#issuecomment-542910118

Although a simple request to make - the requirements to do this properly are quite involved. It would require that Gitea stores private keys - which would mean that users would need some way of installing private keys on Gitea, Gitea generating its own per user (potentially per repository) public/private keypair that the user would then have to install on the external site, or, similar things with Certificates.

This requires serious thought and planning about how this would be implemented.

@zeripath commented on GitHub (Aug 7, 2021): Please read my comments on #1635 https://github.com/go-gitea/gitea/issues/1635#issuecomment-542910118 Although a simple request to make - the requirements to do this properly are quite involved. It would require that Gitea stores private keys - which would mean that users would need some way of installing private keys on Gitea, Gitea generating its own per user (potentially per repository) public/private keypair that the user would then have to install on the external site, or, similar things with Certificates. This requires serious thought and planning about how this would be implemented.

GiteaMirror commented

2025-11-02 07:30:40 -06:00

@adyanth commented on GitHub (Aug 7, 2021):

This is the way, if implemented. Gitea has to manage pub/priv key pairs per repo where enabled and use it.

@adyanth commented on GitHub (Aug 7, 2021): This is the way, if implemented. Gitea has to manage pub/priv key pairs per repo where enabled and use it.

GiteaMirror commented

2025-11-02 07:30:41 -06:00

@zeripath commented on GitHub (Aug 7, 2021):

Which one of the options are you suggesting?

If we're not expecting users to upload private keys - how do you deal with the entropy problem with generating so many keypairs? Would you be expecting a keypair per user or per repo?

If we're expecting users to upload their private keys - how do we store them and encrypt them?

@zeripath commented on GitHub (Aug 7, 2021): Which one of the options are you suggesting? If we're not expecting users to upload private keys - how do you deal with the entropy problem with generating so many keypairs? Would you be expecting a keypair per user or per repo? If we're expecting users to upload their private keys - how do we store them and encrypt them?

GiteaMirror commented

2025-11-02 07:30:41 -06:00

@adyanth commented on GitHub (Aug 7, 2021):

I'm suggesting Gitea to generate per repo. But this is not done for every single repo. Only when someone requests a SSH mirror to be configured, right? If we do not have enough entropy, I would just say to notify the user of the same and try again later, or (maybe complex, just a thought) to upload one manually. Private keys have to be saved at the end of the day, should not matter who generated it. Maybe add them to the SSH agent and delete them? (Where does SSH agent persist data? I'm not too sure here)

@adyanth commented on GitHub (Aug 7, 2021): I'm suggesting Gitea to generate per repo. But this is not done for every single repo. Only when someone requests a SSH mirror to be configured, right? If we do not have enough entropy, I would just say to notify the user of the same and try again later, or (maybe complex, just a thought) to upload one manually. Private keys have to be saved at the end of the day, should not matter who generated it. Maybe add them to the SSH agent and delete them? (Where does SSH agent persist data? I'm not too sure here)

GiteaMirror commented

2025-11-02 07:30:41 -06:00

@techknowlogick commented on GitHub (Aug 7, 2021):

Merging this into #1635 as mirror & migrate would have the same logic in the backend, just that mirror would be called multiple times.

@techknowlogick commented on GitHub (Aug 7, 2021): Merging this into #1635 as mirror & migrate would have the same logic in the backend, just that mirror would be called multiple times.

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#7589