Skip to content
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

Closed
1 of 6 tasks
adyanth opened this issue Jul 15, 2021 · 6 comments
Closed
1 of 6 tasks

[FR] SSH mirror option #16437

adyanth opened this issue Jul 15, 2021 · 6 comments

Comments

@adyanth
Copy link
Contributor

adyanth commented 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

@ansemjo
Copy link

ansemjo commented 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.

@zeripath
Copy link
Contributor

zeripath commented Aug 7, 2021

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.

@adyanth
Copy link
Contributor Author

adyanth commented Aug 7, 2021

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

@zeripath
Copy link
Contributor

zeripath commented 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?

@adyanth
Copy link
Contributor Author

adyanth commented 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)

@techknowlogick
Copy link
Member

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

@ansemjo ansemjo mentioned this issue Aug 7, 2021
5 tasks
@go-gitea go-gitea locked and limited conversation to collaborators Oct 19, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants