What type of hardware are you using: VPS bought online What YunoHost version are you running: YunoHost 12.0.4.1 (testing). What app is this about: Forgejo, Gitea, Gogs
Describe your issue
Pushing to a repo in either Forgejo, Gitea or Gogs always results in:
$ git push -u origin main
remote: Unauthorized
fatal: Authentication failed for 'https://<my_domain>/gitea/<user>/<repo_name>.git/'
I am prompted for my login details when pushing, and entering my username and password (same as I login to the web version of the apps) I get the above error.
Forgejo, Gitea and Gogs are all set to Public, so that visitors can see them.
Share relevant logs or error messages
No errors during install on any of them.
All work in the web version.
Am able to upload files via the web version.
Does not matter if the repo is Public or Private, same error.
Exact same error if bogus username and password are used.
Not sure exactly how git authentication works for these app … I’m gonna exceptionally poke (hopefully it’s ok) @Josue who may have some expertise about this
Honestly, I didn’t do any test for now but I suppose that it probably work with the auth basic and so we probably need the disable the auth basic spoofing protection.
Can you try adding the following settings in the app setting with this command:
Hmm, yeah okay mixed results.
If I log in via SSH to my coding computer and try to push, it does actually work!
So I guess everything works just fine. Thanks!
But if I do it on my local computer I just get redirected to the Yunohost login page on my website.
Nothing happens if I login on the page though, I’m just stuck at git push -u origin main forever.
Did you set the app as public (so are the visitors group allowed in the gitea.main permission) ? Note that this is required to make it working if you use http instead of ssh for git.
They do have the Gitea permission, yes.
And as I said, it works when I SSH into a machine and do the HTTPS push.
But locally it just opens the website.
Also just noticed that doing git clone opens the same website.
Is this something I can change on my end, or what could be causing this?
I was recently informed that if you clone or push using git clone <user>@<repo> instead of just git clone <repo>, it will ask for your credentials, store them, and then everything works. This fixes the website opening.
This feels more like a workaround than a fix, so perhaps some setting on the server still needs to be adjusted.
But for now, it works.
Make a repo on any of the specified apps.
Locally, do git clone <repo url>, this would, as stated above, open up the Yunohost website hosting the repo and ask for my details.
The same happens with doing git push.
Even if the user logs in when the website opens, the clone or push process would not continue, and is instead stuck forever.
However, instead of doing, for example, git clone <repo url>, you can do git clone <user name>@<repo url>.
This will prompt the user with the “native” Git credentials manager screen, where entering your password will allow the cloning or pushing process to continue normally.
Once this is done, the user no longer needs to use git clone <user name>@<repo url> as the credentials are stored.
Meaning that git clone <repo url> will work (i.e. no longer up the Yunohost website) after the “trick” has been used once.
So just installed gitea form master on a container and than did this command from my computer:
➜ git clone https://<domain>/gitea/<user>/test.git
Clonage dans 'test'...
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
Réception d'objets: 100% (4/4), fait.
#
# create a commit ...
#
➜ test git:(main) git push origin main
Username for 'https://<domain>': <user>
Password for 'https://<user>@<domain>':
remote: Unauthorized
fatal : Échec d'authentification pour 'https://<domain>/gitea/<user>/test.git/'
#
# Fix the protect_against_basic_auth_spoofing issue
#
➜ test git:(main) git push origin main
Username for 'https://<domain>': <user>
Password for 'https://<user>@<domain>':
Énumération des objets: 4, fait.
Décompte des objets: 100% (4/4), fait.
Compression par delta en utilisant jusqu'à 4 fils d'exécution
Compression des objets: 100% (2/2), fait.
Écriture des objets: 100% (3/3), 488 octets | 488.00 Kio/s, fait.
Total 3 (delta 0), réutilisés 0 (delta 0), réutilisés du pack 0
remote: . Processing 1 references
remote: Processed 1 references in total
To https://<domain>/gitea/<user>/test.git
d7bf391..208a5b9 main -> main
Conclusion from my side: I confirm that there are an issue related to the protect_against_basic_auth_spoofing settings. But after disabling this protection I can push without any issues (with HTTP).
Note I didn’t test with ssh.
Small question, what is the platform of your client ?
Look like more SSH url. Do you use Git over ssh or over http ? (Note in gitea you can retrieve the url in both format)
Locally, and where the website opens, is Windows 11.
I’m only talking about HTTPS. (SSH has always worked)
I don’t want to give away my domain name, but I am doing: git clone https://<domain>/gitea/<user>/test.git
Which results in the website domain opening up, asking me to login.
However, doing: git clone https://<user>@<domain>/gitea/<user>/test.git
will result in the native Git credentials manager (instead of the website) asking me for my password.
And that will let me clone the repo, via HTTPS.
The credentials are then also stored in the Windows Credentials manager, meaning that simply doing git clone https://<domain>/gitea/<user>/test.git will work the next time.
I don’t know the technical details behind all of this, but my guess is that Gitea reports Yunohost as a website that the user can login to.
Git then brings up the website for the user to login into, and Git keeps waiting for the correct cookie (or whatever Git is waiting for) to be created, which never happens. Leaving the cloning/pushing action stuck forever.
I’ve sent you a private message showing the process.
