gitea: Can't clone a repository via ssh: Repository does not exist or you do not have access
- Gitea version (or commit ref):
Gitea version 1.1.0+8-gd9bdf7a built with: bindata, sqlite - Git version:
git version 2.7.4 - Operating system:
Ubuntu 16.04.2 LTS - Database (use
[x]):- PostgreSQL
- MySQL
- MSSQL
- SQLite
- Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
- Log gist:
2017/04/06 20:29:44 [T] SSH: Handshaking for 5.198.65.153:42250
2017/04/06 20:29:44 [T] SSH: Connection from 5.198.65.153:42250 (SSH-2.0-OpenSSH_7.3p1 Ubuntu-1)
2017/04/06 20:29:44 [T] SSH: Payload: git-upload-pack 'sbrl/alatael.git'
2017/04/06 20:29:44 [T] SSH: Arguments: [serv key-10 --config=/srv/git/gitea/custom/conf/app.ini]
2017/04/06 20:29:44 [...a/modules/ssh/ssh.go:103 func1()] [E] SSH: Wait: exit status 1
Description
If I create a new repository and then attempt to clone it, it doesn’t let me. See the screenshot below.
Note that I’ve recently undergone a rather (painful) migration from gogs to gitea.
Screenshots
If this issue involves the Web Interface, please include a screenshot
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 3
- Comments: 82 (21 by maintainers)
TL;DR: I manually typed in my url to
git remote set-url origin <urlhere>, instead of copying from the hosting website, and it fixed my permission denied issue. Probably not an issue the OP faced, but thought I should post it here anyway since this is the best-matching issue on the internet I could find in the last 5 hours I’ve spent searching.For others experiencing similar issues, I wanted to post something that solved my issue that was almost identical to this main thread but seems to have different source (i.e., all git -v and git -T commands were returning successful authentication, and my SSH keys were properly setup). And I was getting “Permission denied (publickey).” on trying to push or clone my repository.
It turns out there must have been some strange whitespace character in my git url, because after typing in the url manually, I was able to clone and push successfully. I had been copying the clone url directly from GitHub, and reset the url using
git remote set-url origin <urlhere>multiple times, but always copying directly from the website. You can see from mygit config -lafter my failed attempt, the url looks identical to the one that I changed it to. Yet, I can’t seem to reproduce the problem. I have since tried to go back andgit remote set-url origin <url-directly-from-GitHub>again, yet pushing still works. That is the only command I ran that changed anything between my last fail and my first success. And on visual inspection, I see no differences between the output ofgit config -lbefore and after the fix. So I suspect either a whitespace/carriage return issue, or something else that I don’t understand that changed by me manually typing in my url.Below you can see that my url before and what I changed it to look identical. If git captured revisions of the config file (maybe it does?), I would revert to the old version to find the issue.
@kratzercanby Thank you so much for saving me A LOT of time. I have been trying to solve the problem for hours. Cheer~
Yes! I’ve finally fixed it. Turns out that I’ve I had a strange bug in my systemd configuration file whereby I gave it the old working directory during the migration. Updating that and cleaning up seems to have fixed the strange DB issues, so it all works as expected now 😄 😄 😄
Thanks for all your help, @lunny 😺
At the risk of adding more confusion to this long issue:
I had this issue as well using a default ssh install. I was unable to to clone
sshUser@domain:giteaUser/repo.git. What worked instead issshUser@domain:~/pathToGiteaRepos/giteaUser/repo.git.I then “fixed” the issue by clicking “Rewrite ‘.ssh/authorized_keys’ file (for Gitea SSH keys).” in the admin panel of gitea. ssh clones with the advertised URL worked then. Hoewever, #2046 happened then, so beware.
Also seeing this issue using system ssh server (built in disabled). Can clone via http but not ssh. ssh logs indicate gitea user authenticates successfully but git reports:
As for others. Cycling the authorized_keys file in the admin section makes no difference (backup is identical). authorized_keys points to correct binary and app.ini. The authorized_key listed is the one I uploaded to my user account.
Here’s debug output from ssh -T -vvv gitea@my.gitea.server
Hope this helps.
Yesterday I had similar issue. After setup server, I changed port to connect, and left only port 14222. But git tried pull using port 22, so this port was closed, git returned similar error: "fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists."
Please check file /etc/ssh/ssh_config, maybe you also have open only one port, which different from 22.
for what it’s worth…here’s a work around – this issue seems to be specific to a user account that has admin privileges. I created a limited user named “git” and
git pullandgit pushwork just fine now.So my guess would be there’s an issue in the code path related to an admin level user’s permissions.
I’ll keep an eye on this, but Gitea is effectively broken as of right now, as best as I can tell.
Exact same problem.
Created a repo in the web UI, but when I try to clone it locally – nada.
cloning via HTTPS works fine (but isn’t ideal for obvious reasons). I can SSH to the server without issue – and the PUB key loaded into my profile on Gitea is the same PUB key I am using locally.
UPDATE –
interestingly, the repo is set to be a public repo, and the SSH key is in place.
Oh dear. Now I’ve tried pushing via https, and although git says “everything up to date” when I push a second time, it isn’t showing up on the web interface.
Appropriate logs: