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

Can't clone a repository via ssh: Repository does not exist or you do not have access #1454

Closed
sbrl opened this issue Apr 6, 2017 · 80 comments

Comments

@sbrl
Copy link

commented Apr 6, 2017

  • 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

selection_007

If this issue involves the Web Interface, please include a screenshot

@sbrl

This comment has been minimized.

Copy link
Author

commented Apr 6, 2017

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:

2017/04/06 20:57:32 [D] Session ID: f014da28a1472b00
2017/04/06 20:57:32 [D] CSRF Token: 0XpJiGPYJ-OziWHgaGZEANE233g6MTQ5MTUwNTA1MjIyMDYwOTg2MA==
2017/04/06 20:57:40 [D] Session ID: 5f3d2dce75cd87a0
2017/04/06 20:57:40 [D] CSRF Token: IcNEueAf3HeSrJdEA9_j1bom2XM6MTQ5MTUwNTA2MDU0NzYyMDc1OA==
2017/04/06 20:57:40 [D] Session ID: fcd24c369c8dc016
2017/04/06 20:57:40 [D] CSRF Token: 4GnzkgIhoxyUQNRWtUh78v-dF7s6MTQ5MTUwNTA2MDU3ODA4NzY5OA==
2017/04/06 20:57:40 [...routers/repo/http.go:137 HTTP()] [E] invalid token
2017/04/06 20:57:48 [D] Session ID: bc0c3c23890e364c
2017/04/06 20:57:48 [D] CSRF Token: s82CopP0TP3phEhBQ45tajFgbOA6MTQ5MTQ4MDQ4MjEyNTE0OTA3NA==
2017/04/06 20:57:48 [D] Bare repository: /sbrl/alatael
2017/04/06 20:57:48 [D] Template: repo/bare
@lunny

This comment has been minimized.

Copy link
Member

commented Apr 7, 2017

For first issue, have you followed all the steps on https://docs.gitea.io/en-us/upgrade-from-gogs/
For second issue, please forget the old password on git config and try again.

@sbrl

This comment has been minimized.

Copy link
Author

commented Apr 7, 2017

@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 :-(

@lunny

This comment has been minimized.

Copy link
Member

commented Apr 7, 2017

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.

@sbrl

This comment has been minimized.

Copy link
Author

commented Apr 7, 2017

@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 :-/

@sbrl

This comment has been minimized.

Copy link
Author

commented Apr 7, 2017

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 :-(

@lunny

This comment has been minimized.

Copy link
Member

commented Apr 8, 2017

Have you set up the right user permission? all the files should be owned by your run user, for example git.

@lunny lunny added the kind/question label Apr 8, 2017

@sbrl

This comment has been minimized.

Copy link
Author

commented Apr 8, 2017

@lunny Good thinking. I've run a sudo chown -R git:git /srv/git, but that doesn't seem to rectify the problem 😕

@sbrl

This comment has been minimized.

Copy link
Author

commented Apr 14, 2017

image
Uh oh! Now I can't pull from an existing repository. I tried cycling the public key already. Suggestions? I can provide any information required on request.

@lunny

This comment has been minimized.

Copy link
Member

commented Apr 14, 2017

It seems your SSH public key is not exist. Commonly this means your .authorized_keys file is not corrected. And you have to run Rewrite '.ssh/authorized_keys' file on Admin Panel. And could you run ssh -T <git_user>@<gitea_host> and test if its normal?

@sbrl

This comment has been minimized.

Copy link
Author

commented Apr 14, 2017

@lunny I have run the "Rewrite '.ssh/authorized_keys' file" thing multiple times, yet it still doesn't help. ssh -T git@git.starbeamrainbowlabs.com just hangs - I don't get any output :-(

@lunny

This comment has been minimized.

Copy link
Member

commented Apr 14, 2017

Maybe you can use ssh -vvv git@git.starbeamrainbowlabs.com to debug where is the problem.

@sbrl

This comment has been minimized.

Copy link
Author

commented Apr 14, 2017

@lunny It doesn't mean much to me, but the output of that (up to the hang) is here: https://hastebin.com/bohoyirenu.txt

@sbrl

This comment has been minimized.

Copy link
Author

commented Apr 14, 2017

Right. This is getting a bit messy, so let me clear a few things up. This looks like 2 separate issues to me.

  1. I get a Can't clone a repository via ssh: Repository does not exist or you do not have access when attempting to clone a newly-created repository.
  2. I get a Invalid key ID[key-11]: public key does not exist [id: 11] when attempting to interact with an existing repository.
@lunny

This comment has been minimized.

Copy link
Member

commented Apr 15, 2017

It seems your local key is a public key but not a private key? And the log is only a part not a full?

@sbrl

This comment has been minimized.

Copy link
Author

commented Apr 15, 2017

@lunny Nope, I have both a public and a private key locally, stored in ~/.ssh/sbrl_gogs.pub and ~/.ssh/sbrl_gogs respectively. The log of that ssh -vvv command is indeed the full thing. It just hangs at the end of the log 😕

@lunny

This comment has been minimized.

Copy link
Member

commented Apr 15, 2017

so did you have ~/.ssh/config to indicate the sbrl_gogs when git@git.starbeamrainbowlabs.com?

@sbrl

This comment has been minimized.

Copy link
Author

commented Apr 15, 2017

@lunny Yep

@xxdesmus

This comment has been minimized.

Copy link

commented Apr 17, 2017

Exact same problem.

Created a repo in the web UI, but when I try to clone it locally -- nada.

Cloning into 'XXXXX'...
fatal: 'user/XXXXX' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

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

GIT_CURL_VERBOSE=1 GIT_TRACE=1 git clone https://XXXX/USER/REPO.git
15:07:22.036099 git.c:371               trace: built-in: git 'clone' 'https://XXXX/USER/REPO'
Cloning into 'REPO'...
15:07:22.052383 run-command.c:350       trace: run_command: 'git-remote-https' 'origin' 'https://XXXX/USER/REPO'
* Couldn't find host XXXXX in the .netrc file; using defaults
*   Trying 104.223.12.155...
* TCP_NODELAY set
* Connected to XXXXXX (104.223.12.155) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate: XXXXX
* Server certificate: Let's Encrypt Authority X3
* Server certificate: DST Root CA X3
> GET /USER/REPO.git/info/refs?service=git-upload-pack HTTP/1.1
Host: XXXXXX
User-Agent: git/2.11.0 (Apple Git-81)
Accept: */*
Accept-Encoding: gzip
Pragma: no-cache

< HTTP/1.1 401 Unauthorized
< Content-Length: 0
< Content-Type: text/plain; charset=utf-8
< Date: Mon, 17 Apr 2017 22:07:22 GMT
< Server: Caddy
< Set-Cookie: lang=en-US; Path=/; Max-Age=2147483647
< Set-Cookie: i_like_gogits=e5d298dd810d718d; Path=/; HttpOnly
< Set-Cookie: _csrf=QIfBDKxBwI__8WPAvvoJtyL-J4A6MTQ5MjQ2Njg0MjE1MzA0NTkxNQ%3D%3D; Path=/; Expires=Tue, 18 Apr 2017 22:07:22 GMT; HttpOnly
< Www-Authenticate: Basic realm="."
< X-Frame-Options: SAMEORIGIN
<
* Curl_http_done: called premature == 0
* Connection #0 to host XXXXX left intact

interestingly, the repo is set to be a public repo, and the SSH key is in place.

@lunny lunny modified the milestone: 1.2.0 Apr 19, 2017

@sbrl

This comment has been minimized.

Copy link
Author

commented Apr 20, 2017

Ok.... so why does pull work and push doesn't?

@lunny

This comment has been minimized.

Copy link
Member

commented Apr 21, 2017

How do you resolve your pull issue?

@sbrl

This comment has been minimized.

Copy link
Author

commented Apr 21, 2017

@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.

@sbrl

This comment has been minimized.

Copy link
Author

commented Apr 23, 2017

Umm ok, I think pulling only works intermittently - not for a repositories.

@xxdesmus

This comment has been minimized.

Copy link

commented Apr 23, 2017

I'll keep an eye on this, but Gitea is effectively broken as of right now, as best as I can tell.

@sbrl

This comment has been minimized.

Copy link
Author

commented Mar 25, 2018

Doing ssh -T git@starbeamrainbowlabs.com (to access the ssh main server) gives this:

Hi there, You've successfully authenticated, but Gitea does not provide shell access.
If this is unexpected, please log in with password and setup Gitea under another user.

....but ssh -T git@git.starbeamrainbowlabs.com (the internal Gitea SSH server) gives nothing, and doesn't return.

@sbrl

This comment has been minimized.

Copy link
Author

commented Mar 25, 2018

......but as soon as I try to push via starbeamrainbowlabs.com (the main ssh server), I get this again:

Gitea: Invalid key ID
Invalid key ID[key-11]: public key does not exist [id: 11]
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

How come it can authenticate via -T, but not when pushing?

@lafriks

This comment has been minimized.

Copy link
Member

commented Mar 26, 2018

Regenerate ssh authorized keys file using admin section in web UI and try again

@sbrl

This comment has been minimized.

Copy link
Author

commented Mar 27, 2018

@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:

Gitea: Invalid key ID
Invalid key ID[key-12]: public key does not exist [id: 12]
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
@sbrl

This comment has been minimized.

Copy link
Author

commented Jun 4, 2018

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:

  • I've got access via openssh and the inbuilt SSH server setup
  • The test via openssh works - ssh -T git@starbeamrainbowlabs.com -> Hi there, You've successfully authenticated, but Gitea does not provide shell access.
  • The test via the inbuilt SSH server hangs indefinitely (ssh -T git@git.starbeamrainbowlabs.com): https://hastebin.com/saheluriqa
  • Pulling from a public repo via SSH (either the inbuilt SSH server or the OpenSSH server) works
  • Pushing via SSH (either method) does not work: `Gitea: Invalid key ID
    Invalid key ID[key-15]: public key does not exist [id: 15]
    fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.`

Additional logs - pushing via inbuilt server (no output when pushing via openssh)

logs/gitea.log

2018/06/04 21:39:00 [T] SSH: Handshaking for 5.198.44.45:44008
2018/06/04 21:39:00 [T] SSH: Connection from 5.198.44.45:44008 (SSH-2.0-OpenSSH_7.5p1 Ubuntu-10ubuntu0.1)
2018/06/04 21:39:00 [T] SSH: Payload: git-receive-pack 'sbrl/arduino.git'
2018/06/04 21:39:00 [T] SSH: Arguments: [serv key-15 --config=/srv/git/gitea/custom/conf/app.ini]
2018/06/04 21:39:00 [...a/modules/ssh/ssh.go:103 func1()] [E] SSH: Wait: exit status 1

logs/xorm.log

2018/06/04 21:40:25 [I] [SQL] SELECT `id`, `owner_id`, `name`, `fingerprint`, `content`, `mode`, `type`, `created_unix`, `updated_unix` FROM `public_key` WHERE (content like ?) LIMIT 1 []interface {}{"ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDK4bOAYn90dMnenrBqCtUuEbqUd/YtDdz2sahbv++JLG8sFNqZ5ZiYGNmU6+NI0Q1E09anf1MwkgcbvLjoc7thLkguUaU6XOl2fYkc8ucg8Aly3QV8rRiiLjUGxOeoiMMnn81rWuJM2NwLHNd0ciBbAfL9lfIZI8M9P9ay1W7a7YCfqQsne8l43mYhgf2Gj2Jr/sPa/64fp2WPt/HEGUjxQ9bGgRaJ/8RvDGgDSv4lUQByfis7EC6d+6ieBEqWy5pgLB7a/BQW3VJp1mF70J1cOk7lV3+PZvPX0L6Im426NUR1/MT32xVRMqebK+LxImUo3Whx1ZinhxaKbJDK7fJjJ84KQXUsO0gsh531wPRL6fvwUG0RdpBfVdRlvbzDBLQytqNNif/29r6xrPJGHdqLCQXbTASZPo8ycda4M49gmdYY+/pkUZ65boYRd2POWk5MkSsZhbSZ6qzsYnkZT6XoNsql7G35rg8KaB/iekyIjE6stB6FHFp9GRHg7NsrdnHvJqpH7PH8NjhuGBmQRDq19YXpnpP/DXtwZcK/3bb1wmz3Nx0qFElS2tUV4p4HTXHu1SBYmJdWuzsc/vB5dpNLdHFuG4GdQ2NVn9PR9XTo5Q5Mjjh/qGpXVLDN82o963fdBSkFJD/dx1P1MAGN2n6VjMtI8odZpdQSo4YeoTWYow==%"}
2018/06/04 21:40:26 [I] [SQL] SELECT repository.* FROM `repository` INNER JOIN `user` ON `user`.id = repository.owner_id WHERE (repository.lower_name = ?) AND (`user`.lower_name = ?) LIMIT 1 []interface {}{"arduino", "sbrl"}
2018/06/04 21:40:26 [I] [SQL] SELECT `id`, `owner_id`, `name`, `fingerprint`, `content`, `mode`, `type`, `created_unix`, `updated_unix` FROM `public_key` WHERE `id`=? LIMIT 1 []interface {}{15}
@techknowlogick

This comment has been minimized.

Copy link
Member

commented Jun 4, 2018

@sbrl are you still using the same version of Gitea?

@sbrl

This comment has been minimized.

Copy link
Author

commented Jun 4, 2018

@techknowlogick I'm currently on v1.4.1 of Gitea, on Ubuntu Server 16.04 LTS.

@adrinux

This comment has been minimized.

Copy link

commented Jun 12, 2018

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:

fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

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

debug1: Authentication succeeded (publickey).
Authenticated to [REDACTED]
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug3: receive packet: type 4
debug1: Remote: Forced command.
debug3: receive packet: type 4
debug1: Remote: Port forwarding disabled.
debug3: receive packet: type 4
debug1: Remote: X11 forwarding disabled.
debug3: receive packet: type 4
debug1: Remote: Agent forwarding disabled.
debug3: receive packet: type 4
debug1: Remote: PTY allocation disabled.
debug3: receive packet: type 4
debug1: Remote: Forced command.
debug3: receive packet: type 4
debug1: Remote: Port forwarding disabled.
debug3: receive packet: type 4
debug1: Remote: X11 forwarding disabled.
debug3: receive packet: type 4
debug1: Remote: Agent forwarding disabled.
debug3: receive packet: type 4
debug1: Remote: PTY allocation disabled.
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x08
debug2: client_session2_setup: id 0
debug1: Sending environment.
debug3: Ignored env XDG_CURRENT_DESKTOP
debug3: Ignored env DBUS_STARTER_ADDRESS
debug1: Sending env LANG = en_GB.UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env DISPLAY
debug3: Ignored env PWD
debug3: Ignored env LOGNAME
debug3: Ignored env SHLVL
debug3: Ignored env INVOCATION_ID
debug3: Ignored env MANDATORY_PATH
debug3: Ignored env XDG_VTNR
debug3: Ignored env XAUTHORITY
debug3: Ignored env JOURNAL_STREAM
debug3: Ignored env GTK_IM_MODULE
debug3: Ignored env COLORTERM
debug3: Ignored env XDG_SESSION_ID
debug3: Ignored env DESKTOP_SESSION
debug3: Ignored env IM_CONFIG_PHASE
debug3: Ignored env XDG_SESSION_DESKTOP
debug3: Ignored env GDMSESSION
debug3: Ignored env TEXTDOMAINDIR
debug3: Ignored env USERNAME
debug3: Ignored env WINDOWPATH
debug3: Ignored env TEXTDOMAIN
debug3: Ignored env GNOME_DESKTOP_SESSION_ID
debug3: Ignored env DBUS_SESSION_BUS_ADDRESS
debug3: Ignored env VTE_VERSION
debug3: Ignored env DBUS_STARTER_BUS_TYPE
debug3: Ignored env XDG_DATA_DIRS
debug3: Ignored env _
debug3: Ignored env QT4_IM_MODULE
debug3: Ignored env CLUTTER_IM_MODULE
debug3: Ignored env XDG_MENU_PREFIX
debug3: Ignored env QT_ACCESSIBILITY
debug3: Ignored env SHELL
debug3: Ignored env QT_IM_MODULE
debug3: Ignored env XDG_SESSION_TYPE
debug3: Ignored env XDG_CONFIG_DIRS
debug3: Ignored env MANAGERPID
debug3: Ignored env SSH_AGENT_PID
debug3: Ignored env GTK_MODULES
debug3: Ignored env SESSION_MANAGER
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env PATH
debug3: Ignored env LIBVIRT_DEFAULT_URI
debug3: Ignored env TERM
debug3: Ignored env HOME
debug3: Ignored env USER
debug3: Ignored env XMODIFIERS
debug3: Ignored env XDG_RUNTIME_DIR
debug3: Ignored env DEFAULTS_PATH
debug3: Ignored env GPG_AGENT_INFO
debug3: Ignored env XDG_SEAT
debug3: Ignored env TILIX_ID
debug3: Ignored env OLDPWD
debug3: Ignored env EDITOR
debug3: Ignored env VISUAL
debug3: Ignored env PAGER
debug3: Ignored env LESS
debug3: Ignored env LESSOPEN
debug3: Ignored env TMPDIR
debug3: Ignored env PYTHONPATH
debug3: Ignored env ANSIBLE_LIBRARY
debug3: Ignored env MANPATH
debug3: Ignored env GOPATH
debug3: Ignored env GOBIN
debug3: Ignored env LESS_TERMCAP_mb
debug3: Ignored env LESS_TERMCAP_md
debug3: Ignored env LESS_TERMCAP_me
debug3: Ignored env LESS_TERMCAP_se
debug3: Ignored env LESS_TERMCAP_so
debug3: Ignored env LESS_TERMCAP_ue
debug3: Ignored env LESS_TERMCAP_us
debug3: Ignored env LS_COLORS
debug3: Ignored env GREP_COLOR
debug3: Ignored env GREP_COLORS
debug3: Ignored env NVM_CD_FLAGS
debug3: Ignored env NVM_DIR
debug3: Ignored env NVM_BIN
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
debug3: receive packet: type 96
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug3: receive packet: type 97
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug3: send packet: type 97
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)

debug3: send packet: type 1
Transferred: sent 2720, received 3004 bytes, in 1.0 seconds
Bytes per second: sent 2766.3, received 3055.1
debug1: Exit status 1

Hope this helps.

@adrinux

This comment has been minimized.

Copy link

commented Jun 13, 2018

Solved!
I'm using a 'gitea' user to run gitea. It seems I'd created the gitea user with shell /bin/false instead of bash.
You can check your gitea user (wehter that be git or gitea or whatever) in /etc/passwd

Change the gitea users shell with:

sudo chsh -s /bin/bash gitea

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.

@sbrl

This comment has been minimized.

Copy link
Author

commented Jun 13, 2018

@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.

@adrinux

This comment has been minimized.

Copy link

commented Jun 14, 2018

@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.

@sbrl

This comment has been minimized.

Copy link
Author

commented Jun 15, 2018

Hrm, I see @adrinux. On my server, I have the gitea binary started as the git user, and I execute setcap 'cap_net_bind_service=+ep' gitea to ensure it can bind to port 22 without being root. Surely it's theoretically possible to set the 'shell' of the git user to be the gitea binary? Wouldn't that be in theory more secure?

If I grant shell access to the git user permanently (instead of just for testing), who else would be able to gain access to my server? Would that be anyone with an ssh key attached to their account?

If that is a thing I need to do, I'd like to at least figure out how to jail that user to /srv/git (the directory in which all git-related stuff happens, and also the git user's home directory).

Also, there's still the issue surrounding the built-in ssh server. To that end, I've no idea why that's not working

I've just been inspecting the logs again, and I found some possible clues. Here's a teensy extract:

2018/06/15 12:06:59 [...io/gitea/cmd/serv.go:165 runServ()] [F] Repository does not exist: sbrl/floatingislands

Hrm, curious. I'm sure I pulled from git@git.starbeamrainbowlabs.com:sbrl/FloatingIslands.git, and my repository on disk is sbrl/floatingislands.git....? Here's all the log lines generated for this attempt:

2018/06/15 12:10:29 [T] SSH: Handshaking for 5.198.44.45:59002

==> logs/xorm.log <==
2018/06/15 12:10:29 [I] [SQL] SELECT `id`, `owner_id`, `name`, `fingerprint`, `content`, `mode`, `type`, `created_unix`, `updated_unix` FROM `public_key` WHERE (content like ?) LIMIT 1 []interface {}{"ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDK4bOAYn90dMnenrBqCtUuEbqUd/YtDdz2sahbv++JLG8sFNqZ5ZiYGNmU6+NI0Q1E09anf1MwkgcbvLjoc7thLkguUaU6XOl2fYkc8ucg8Aly3QV8rRiiLjUGxOeoiMMnn81rWuJM2NwLHNd0ciBbAfL9lfIZI8M9P9ay1W7a7YCfqQsne8l43mYhgf2Gj2Jr/sPa/64fp2WPt/HEGUjxQ9bGgRaJ/8RvDGgDSv4lUQByfis7EC6d+6ieBEqWy5pgLB7a/BQW3VJp1mF70J1cOk7lV3+PZvPX0L6Im426NUR1/MT32xVRMqebK+LxImUo3Whx1ZinhxaKbJDK7fJjJ84KQXUsO0gsh531wPRL6fvwUG0RdpBfVdRlvbzDBLQytqNNif/29r6xrPJGHdqLCQXbTASZPo8ycda4M49gmdYY+/pkUZ65boYRd2POWk5MkSsZhbSZ6qzsYnkZT6XoNsql7G35rg8KaB/iekyIjE6stB6FHFp9GRHg7NsrdnHvJqpH7PH8NjhuGBmQRDq19YXpnpP/DXtwZcK/3bb1wmz3Nx0qFElS2tUV4p4HTXHu1SBYmJdWuzsc/vB5dpNLdHFuG4GdQ2NVn9PR9XTo5Q5Mjjh/qGpXVLDN82o963fdBSkFJD/dx1P1MAGN2n6VjMtI8odZpdQSo4YeoTWYow==%"}

==> logs/gitea.log <==
2018/06/15 12:10:29 [T] SSH: Connection from 5.198.44.45:59002 (SSH-2.0-OpenSSH_7.5p1 Ubuntu-10ubuntu0.1)
2018/06/15 12:10:29 [T] SSH: Payload: git-upload-pack 'sbrl/FloatingIslands.git'
2018/06/15 12:10:29 [T] SSH: Arguments: [serv key-15 --config=/srv/git/gitea/custom/conf/app.ini]

==> logs/xorm.log <==
2018/06/15 12:10:29 [I] [SQL] SELECT repository.* FROM `repository` INNER JOIN `user` ON `user`.id = repository.owner_id WHERE (repository.lower_name = ?) AND (`user`.lower_name = ?) LIMIT 1 []interface {}{"floatingislands", "sbrl"}

==> logs/serv.log <==
2018/06/15 12:10:29 [...io/gitea/cmd/serv.go:165 runServ()] [F] Repository does not exist: sbrl/floatingislands

==> logs/gitea.log <==
2018/06/15 12:10:29 [...a/modules/ssh/ssh.go:103 func1()] [E] SSH: Wait: exit status 1

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.

@adrinux

This comment has been minimized.

Copy link

commented Jun 15, 2018

Surely it's theoretically possible to set the 'shell' of the git user to be the gitea binary?

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?

@sbrl

This comment has been minimized.

Copy link
Author

commented Jun 15, 2018

....but you can start a subprocess (e.g. git) with arguments without starting a shell.

I'm pretty sure, yeah. I did another sudo chown -R git:git /srv/git && sudo chmod -R u+rw /srv/git just in case, but it all seems to be fine. Here's my gitea config file (screenshot of admin page)

@adrinux

This comment has been minimized.

Copy link

commented Jun 15, 2018

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.

@lunny

This comment has been minimized.

Copy link
Member

commented Jun 15, 2018

Is the repo sbrl/floatingislands in your database repository? And another issue is sqlite will be failed when some processes visit it.

@sbrl

This comment has been minimized.

Copy link
Author

commented Jun 17, 2018

@lunny Thanks thanks for the suggestion there. It just keeps getting weirder. If I download a copy of gogs.db and inspect it, I see less than half of my repositories in that table!

Running stat /srv/git/gitea/data/gogs.db gives me these values:

  • Access: 2018-06-17 01:13:59.504436085 +0100
  • Modify: 2017-12-11 12:11:11.104763360 +0000
  • Change: 2018-06-15 13:20:00.637822624 +0100

What's more, it doesn't seem to have saved any changes to my keys to gogs.db - further inspection of gogs.db reveals that the public key saved in the database is different to the one I have locally - even after deleting it and recreating it.

Furthermore, if I try and upload a GPG key, it wipes it shortly afterwards - as if I'd never entered it.

@sbrl

This comment has been minimized.

Copy link
Author

commented Jun 17, 2018

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 [security] section stripped):

APP_NAME = SBRL Git Service
RUN_USER = git
RUN_MODE = prod

[database]
DB_TYPE  = sqlite3
HOST     = 127.0.0.1:3306
NAME     = gogs
USER     = root
PASSWD   = 
SSL_MODE = disable
PATH     = data/gogs.db

[repository]
ROOT = /srv/git/repos

[server]
DOMAIN           = git.starbeamrainbowlabs.com
HTTP_PORT        = 3000
ROOT_URL         = https://git.starbeamrainbowlabs.com/
DISABLE_SSH      = false
SSH_PORT         = 22
OFFLINE_MODE     = false
START_SSH_SERVER = true

[mailer]
ENABLED = true
HOST    = starbeamrainbowlabs.com:587
FROM    = "SBRL git" <postasaurus@starbeamrainbowlabs.com>
USER    = postasaurus@starbeamrainbowlabs.com
PASSWD  = ***** secret ******
[service]
REGISTER_EMAIL_CONFIRM = true
ENABLE_NOTIFY_MAIL     = true
DISABLE_REGISTRATION   = true
ENABLE_CAPTCHA         = false
REQUIRE_SIGNIN_VIEW    = false

[picture]
DISABLE_GRAVATAR = false

[session]
PROVIDER = file

[log]
MODE      = file
LEVEL     = Trace
ROOT_PATH = /srv/git/gitea/logs

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 data/gogs.db reveals that it's owned by git:git and set to -rw-r--r--, so I'm not sure that's the issue.

@lunny

This comment has been minimized.

Copy link
Member

commented Jun 19, 2018

@sbrl maybe you can find the xorm.log.

@sbrl

This comment has been minimized.

Copy link
Author

commented Jun 20, 2018

@lunny Absolutely. Here's a transcript from xorm.log: https://hastebin.com/nisusumiko.sql

Here's what I did in that transcript:

  • I logged in
  • Opened my settings page
  • Added my GPG public key (again)
  • Pulled via HTTPS the private repository sbrl/FloatingIslands (which worked)
  • Pulled via SSH the private repository sbrl/FloatingIslands (which failed)
  • Pulled via SSH the public repository sbrl/cscz (which worked)
  • Pulled via SSH the public repository sbrl/cscz (which failed)

More is available upon request of course 😺

@lunny

This comment has been minimized.

Copy link
Member

commented Jun 21, 2018

@sbrl that's a blank URL.

@sbrl

This comment has been minimized.

Copy link
Author

commented Jun 21, 2018

@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

@noerw

This comment has been minimized.

Copy link

commented Jun 28, 2018

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 is sshUser@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.

@sbrl

This comment has been minimized.

Copy link
Author

commented Jun 29, 2018

@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?

@lunny

This comment has been minimized.

Copy link
Member

commented Jul 6, 2018

@sbrl maybe because you enabled 2fa? Could you try without 2fa enabled? Cannot find any useful clues from your pastebin.

@sbrl

This comment has been minimized.

Copy link
Author

commented Jul 8, 2018

Nope, I haven't got 2-factor authentication enabled @lunny.

selection_028

I've done an ls -lAR of my /srv/git/gitea folder, in case that brings any permissions issues to light. I think I've got everything setup right, but just to be sure. You can download the gzipped output here: https://transfer.sh/113OEV/gitea-ls.txt.gz

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.

@leepfrog-ger

This comment has been minimized.

Copy link

commented Jul 9, 2018

Having the same issue running 1.4.2 on Windows with MSSQL backend and using the builtin SSH server.

Pulling public repos works, pulling private repos or pushing to public and private repos fails with the errors below.

2018/07/09 11:34:55 [T] SSH: Handshaking for 10.10.10.10:51022
2018/07/09 11:34:56 [I] [SQL] SELECT  TOP 1 "id", "owner_id", "name", "fingerprint", "content", "mode", "type", "created_unix", "updated_unix" FROM "public_key" WHERE (content like ?) []interface {}{"ssh-rsa AAAAB3...pzyQ==%"}
2018/07/09 11:34:56 [T] SSH: Connection from 10.10.10.10:51022 (SSH-2.0-TortoiseGitPlink_Release_0.70)
2018/07/09 11:34:56 [T] SSH: Payload: git-upload-pack 'USER/REPO.git'
2018/07/09 11:34:56 [T] SSH: Arguments: [serv key-4 --config=C:\gitea\custom\conf\app.ini]
2018/07/09 11:34:56 [...a/modules/ssh/ssh.go:103 func1()] [E] SSH: Wait: exit status 1

Running the SQL query against the database indeed returns the correct entry from the public_key table (so the key was correctly saved).

/edit: Just noticed that in my case it was due to another issue (LDAP users being disabled by Sync)

@sbrl

This comment has been minimized.

Copy link
Author

commented Aug 31, 2018

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 😺

@sbrl sbrl closed this Aug 31, 2018

@kratzercanby

This comment has been minimized.

Copy link

commented Nov 20, 2018

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 my git config -l after 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 and git 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 of git config -l before 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.
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.