Can't clone a repository via ssh: Repository does not exist or you do not have access #1454
Comments
|
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: |
|
For first issue, have you followed all the steps on https://docs.gitea.io/en-us/upgrade-from-gogs/ |
|
@lunny Thanks for the reply. I have indeed followed all the steps in that guide (though your link results in a 404) - including rewriting the authorized_keys file multiple times by clicking the button in the admin panel. Forget the old password in the git config? I'm not sure I understand. Do you mean on the server or the client? On the client-side I tried deleting and re-adding the ssh key, but that didn't help either :-( |
|
404 because docs site down. I mean client-side. When using http, you could clear the old password git remember when you are using Gogs. |
|
@lunny Hrm. The odd thing is that that was the first time I'd used http...... I'm just baffled as to why I can't clone via ssh :-/ |
|
Hrm. If I delete and recreate the repository on the server and preinitialise it with a README / .gitignore, then it lets me commit via https. ssh still doesn't work though :-( |
|
Have you set up the right user permission? all the files should be owned by your run user, for example |
lunny
added
the
type/question
|
@lunny Good thinking. I've run a |
|
|
|
It seems your SSH public key is not exist. Commonly this means your |
|
@lunny I have run the "Rewrite '.ssh/authorized_keys' file" thing multiple times, yet it still doesn't help. |
|
Maybe you can use |
|
@lunny It doesn't mean much to me, but the output of that (up to the hang) is here: https://hastebin.com/bohoyirenu.txt |
|
Right. This is getting a bit messy, so let me clear a few things up. This looks like 2 separate issues to me.
|
|
It seems your local key is a public key but not a private key? And the log is only a part not a full? |
|
@lunny Nope, I have both a public and a private key locally, stored in |
|
so did you have ~/.ssh/config to indicate the |
|
@lunny Yep |
|
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. |
lunny
added
type/bug
issue/critical
|
Ok.... so why does |
|
How do you resolve your |
|
@lunny I have no idea. I've already tried cloning - and it didn't work. Then, just the other day, I forgot about which remote I needed to pull from (I've got both ssh and https set up until this issue is resolved), and it just worked. Astonished, I tried pushing too - but sadly that didn't work either. |
|
Umm ok, I think pulling only works intermittently - not for a repositories. |
|
I'll keep an eye on this, but Gitea is effectively broken as of right now, as best as I can tell. |
|
@lafriks As I explained above, it says that it will have no effect if I'm using the inbuilt SSH server - which I am. Regardless, I've done do anyway - and it has not helped. I'm still getting this message: |
|
Hey! What's the status on this, @lunny and @lafriks? Is there any additional information or data I can provide? I can provide a complete database copy for example if required to track down this issue. To summarise:
Please make sure you have the correct access rights Additional logs - pushing via inbuilt server (no output when pushing via openssh)
|
|
@sbrl are you still using the same version of Gitea? |
|
@techknowlogick I'm currently on v1.4.1 of Gitea, on Ubuntu Server 16.04 LTS. |
|
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. |
|
Solved! Change the gitea users shell with: Once I'd done that cloning via ssh worked. It seems the gitea user needs shell access if you're using the system SSH server. |
|
@adrinux That's odd. I've done the same, and it has not solved the issue for me - either via openssh or the builtin ssh server 😕 If at all possible, I'd like to avoid giving the git user a shell. |
|
@sbrl It actually mentions making sure you've given the git user a shell in the Gitea troubleshooting section (wish I'd read that earlier). I have no idea how Gitea is built - but at the very least it has to interact with git to do its work, so it would have to shell out at some point. Seems unavoidable to me. |
|
Hrm, I see @adrinux. On my server, I have the If I grant shell access to the If that is a thing I need to do, I'd like to at least figure out how to jail that user to Also, there's still the issue surrounding the built-in ssh server. I've just been inspecting the logs again, and I found some possible clues. Here's a teensy extract: Hrm, curious. I'm sure I pulled from If there's anything else I can do to help speed up the process of fixing it, I'm happy to do so. This has been driving me nuts for far too long :P (Supervised, of course) shell access to my server is not out of the question either if it helps. The only reason I haven't turned gitea inside-out to fix this issue already is that I don't know Go, and that the go toolchain is way too big for my hard drive. |
I have no idea how Gitea actually works I'm just assuming that when gitea wants to do git operations it calls git - otherwise Gitea would have to replicate git functionality in itself, no? As for you other problems. Are you sure you don't have mis-configured paths in the gitea config? I had an issue with certs yesterday where gitea needed the full path specified in its conifg, not a path relative to gitea home. Or permissions issues on the filesystem? |
|
....but you can start a subprocess (e.g. I'm pretty sure, yeah. I did another |
|
I bow to your greater Unix knowledge - I've a feeling your git user doesn't need a shell if you use the built in ssh, only if you're using system openssh...but again, I don't know how it actually works... Maybe it's worth looking at the config cheat sheet and trying some other options for the ini file, SSH_ROOT_PATH for instance. Though it sounds like you've probably checked all that. My only other thought it to check you're not overriding some of the ini declarations at run time in the systemd service (or whatever you're using to start Gitea). I have two instances running now, many other people happily use Gitea, so it really does seem like there is something awry in your setup , hope you figure out what that is. |
|
Is the repo |
|
@lunny Thanks thanks for the suggestion there. It just keeps getting weirder. If I download a copy of Running
What's more, it doesn't seem to have saved any changes to my keys to Furthermore, if I try and upload a GPG key, it wipes it shortly afterwards - as if I'd never entered it. |
|
Thanks @adrinux for the link there, I hadn't actually seen that. I can't see anything wrong with my config file though. Here's my configuration (with the By all accounts, it looks like gitea is silently failing to write to the database, but there's no logging output there to know either way, though that modify time is rather telling. Checking the permissions on |
|
@sbrl maybe you can find the |
|
@lunny Absolutely. Here's a transcript from Here's what I did in that transcript:
More is available upon request of course 😺 |
|
@sbrl that's a blank URL. |
|
@lunny Huh, that's weird. It shows for me! Here it is again using pastebin.com instead: https://pastebin.com/WdNmNpJ4 If this doesn't work, then I'll paste it directly into a message here - but be warned: it'll be very long :P |
|
At the risk of adding more confusion to this long issue: I had this issue as well using a default ssh install. 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. |
|
@noerw Ah, interesting. I'm not sure that issue is related to this one though, as to summarise (this issue does have quite the history :P), we've just discovered that, for some reason, my install is not writing to the database at all! i.e. half of my repositories are missing from the database, and my ssh keys in the database that are used for 2nd-stage authentication are not updating either. I'd recommend opening another issue for that, as I suspect that it has another root cause. Also, ping @lunny. Does that pastebin link for you? |
|
@sbrl maybe because you enabled 2fa? Could you try without 2fa enabled? Cannot find any useful clues from your pastebin. |
|
Nope, I haven't got 2-factor authentication enabled @lunny.
I've done an I'm also open to running a 'custom' build of gitea with extra logging output enabled - though I don't currently have the ability to compile go programs - if that would help too. |
|
/edit: Just noticed that in my case it was due to another issue (LDAP users being disabled by Sync) |
|
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 :D :D :D Thanks for all your help, @lunny 😺 |
|
TL;DR: I manually typed in my url to 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 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~ |
|
To an extent, I think the title of this issue is somewhat deceptive, since my specific issue was specifically related to a migration from Gogs to Gitea. I guess a single error message can have a number of different root causes. |
Gitea version 1.1.0+8-gd9bdf7a built with: bindata, sqlitegit version 2.7.4Ubuntu 16.04.2 LTS[x]):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
The text was updated successfully, but these errors were encountered: