-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
[FR] SSH mirror option #16437
Comments
+1 on this .. Mirroring via HTTPS using username and password/token is implemented in #15157 (available since 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:
#!/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 |
Please read my comments on #1635 #1635 (comment) 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. |
This is the way, if implemented. Gitea has to manage pub/priv key pairs per repo where enabled and use it. |
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? |
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) |
Merging this into #1635 as mirror & migrate would have the same logic in the backend, just that mirror would be called multiple times. |
[x]
): allDescription
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
The text was updated successfully, but these errors were encountered: