Can&#39;t clone a repository via ssh: Repository does not exist or you do not have access #618

@sbrl commented on GitHub (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

@sbrl commented on GitHub (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 ```

GiteaMirror commented

@lunny commented on GitHub (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.

@lunny commented on GitHub (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.

GiteaMirror commented

@sbrl commented on GitHub (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 :-(

@sbrl commented on GitHub (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 :-(

GiteaMirror commented

@lunny commented on GitHub (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.

@lunny commented on GitHub (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.

GiteaMirror commented

@sbrl commented on GitHub (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 commented on GitHub (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 :-/

GiteaMirror commented

@sbrl commented on GitHub (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 :-(

@sbrl commented on GitHub (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 :-(

GiteaMirror commented

@lunny commented on GitHub (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 commented on GitHub (Apr 8, 2017): Have you set up the right user permission? all the files should be owned by your run user, for example `git`.

GiteaMirror commented

@sbrl commented on GitHub (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 commented on GitHub (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 :confused:

GiteaMirror commented

@sbrl commented on GitHub (Apr 14, 2017):

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.

@sbrl commented on GitHub (Apr 14, 2017): ![image](https://cloud.githubusercontent.com/assets/9929737/25043442/e67b737c-2117-11e7-9ebb-16f3f9f572ef.png) 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.

GiteaMirror commented

@lunny commented on GitHub (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?

@lunny commented on GitHub (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?

GiteaMirror commented

@sbrl commented on GitHub (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 :-(

@sbrl commented on GitHub (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 :-(

GiteaMirror commented

@lunny commented on GitHub (Apr 14, 2017):

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

@lunny commented on GitHub (Apr 14, 2017): Maybe you can use `ssh -vvv git@git.starbeamrainbowlabs.com` to debug where is the problem.

GiteaMirror commented

@sbrl commented on GitHub (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 commented on GitHub (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

GiteaMirror commented

@sbrl commented on GitHub (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.

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.
I get a Invalid key ID[key-11]: public key does not exist [id: 11] when attempting to interact with an existing repository.

@sbrl commented on GitHub (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.

GiteaMirror commented

@lunny commented on GitHub (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?

@lunny commented on GitHub (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?

GiteaMirror commented

@sbrl commented on GitHub (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 😕

@sbrl commented on GitHub (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 :confused:

GiteaMirror commented

@lunny commented on GitHub (Apr 15, 2017):

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

@lunny commented on GitHub (Apr 15, 2017): so did you have ~/.ssh/config to indicate the `sbrl_gogs` when `git@git.starbeamrainbowlabs.com`?

GiteaMirror commented

@sbrl commented on GitHub (Apr 15, 2017):

@lunny Yep

@sbrl commented on GitHub (Apr 15, 2017): @lunny Yep

GiteaMirror commented

@xxdesmus commented on GitHub (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.

@xxdesmus commented on GitHub (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.

GiteaMirror commented

@sbrl commented on GitHub (Apr 20, 2017):

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

@sbrl commented on GitHub (Apr 20, 2017): Ok.... so why does `pull` work and `push` doesn't?

GiteaMirror commented

@lunny commented on GitHub (Apr 21, 2017):

How do you resolve your pull issue?

@lunny commented on GitHub (Apr 21, 2017): How do you resolve your `pull` issue?

GiteaMirror commented

@sbrl commented on GitHub (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 commented on GitHub (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.

GiteaMirror commented

@sbrl commented on GitHub (Apr 23, 2017):

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

@sbrl commented on GitHub (Apr 23, 2017): Umm ok, I think pulling only works intermittently - not for a repositories.

GiteaMirror commented

@xxdesmus commented on GitHub (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.

@xxdesmus commented on GitHub (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.

GiteaMirror commented

@lunny commented on GitHub (Apr 24, 2017):

@xxdesmus what's the broken? could you post your error here or another issue?

@lunny commented on GitHub (Apr 24, 2017): @xxdesmus what's the broken? could you post your error here or another issue?

GiteaMirror commented

@xxdesmus commented on GitHub (Apr 24, 2017):

@lunny please see above. Full details posted. Looks like you acknowledged it as a critical bug.

@xxdesmus commented on GitHub (Apr 24, 2017): @lunny please see above. Full details posted. Looks like you acknowledged it as a critical bug.

GiteaMirror commented

@xxdesmus commented on GitHub (Apr 24, 2017):

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 pull and git push work just fine now.

So my guess would be there's an issue in the code path related to an admin level user's permissions.

@xxdesmus commented on GitHub (Apr 24, 2017): 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 pull` and `git push` work just fine now. So my guess would be there's an issue in the code path related to an admin level user's permissions.

GiteaMirror commented

@kermorgant commented on GitHub (May 7, 2017):

I think I have the same issue, although not in the exact same scenario.

On my main machine, I can work with the repo from my admin account (just verified by cloning it to a temp folder).
But on the other machine where I have a separate ssh key (which I just added to gitea), I tried to pull the repo, and there, the issue happened.

@kermorgant commented on GitHub (May 7, 2017): I think I have the same issue, although not in the exact same scenario. On my main machine, I can work with the repo from my admin account (just verified by cloning it to a temp folder). But on the other machine where I have a separate ssh key (which I just added to gitea), I tried to pull the repo, and there, the issue happened.

GiteaMirror commented

@lunny commented on GitHub (May 7, 2017):

@sbrl are you running a Gitea builtin SSH server?
@xxdesmus Maybe your issue is not the same with this one since you have problem with a HTTPS remote.
@kermorgant Did you mean your issue is the same with @sbrl or @xxdesmus ?

@lunny commented on GitHub (May 7, 2017): @sbrl are you running a Gitea builtin SSH server? @xxdesmus Maybe your issue is not the same with this one since you have problem with a HTTPS remote. @kermorgant Did you mean your issue is the same with @sbrl or @xxdesmus ?

GiteaMirror commented

@kermorgant commented on GitHub (May 8, 2017):

Hi @lunny

I'm trying with ssh, which I think is common to @sbrl and @xxdesmus (I understand that @xxdesmus uses https as a fallback option only to get it working).

@kermorgant commented on GitHub (May 8, 2017): Hi @lunny I'm trying with ssh, which I think is common to @sbrl and @xxdesmus (I understand that @xxdesmus uses https as a fallback option only to get it working).

GiteaMirror commented

@sbrl commented on GitHub (May 8, 2017):

@lunny Yep, I'm using the inbuilt server on port 22, as my actual ssh server is running on another port. This way I don't expose an ssh server with password-based authentication on port 22 to spammers (I do have a secure password - don't worry :P).

@sbrl commented on GitHub (May 8, 2017): @lunny Yep, I'm using the inbuilt server on port 22, as my actual ssh server is running on another port. This way I don't expose an ssh server with password-based authentication on port 22 to spammers (I do have a secure password - don't worry :P).

GiteaMirror commented

@sbrl commented on GitHub (Jun 27, 2017):

@lunny Any updates on this? Is there anything I can provide to expedite the tracking down of this bug?

@sbrl commented on GitHub (Jun 27, 2017): @lunny Any updates on this? Is there anything I can provide to expedite the tracking down of this bug?

GiteaMirror commented

@sbrl commented on GitHub (Aug 5, 2017):

I've just tried crerating a non-admin account as @xxdesmus suggested and adding a new ssh key to it, but that still doesn't work - I get the exact same response. Why is it always me who experiences the difficult problems :P

I'm using 4096-bit RSA keys, if that helps.

@sbrl commented on GitHub (Aug 5, 2017): I've just tried crerating a non-admin account as @xxdesmus suggested and adding a new ssh key to it, but that still doesn't work - I get the exact same response. Why is it always me who experiences the difficult problems :P I'm using 4096-bit RSA keys, if that helps.

GiteaMirror commented

@IDobrelya commented on GitHub (Aug 8, 2017):

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.

@IDobrelya commented on GitHub (Aug 8, 2017): 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.

GiteaMirror commented

@sbrl commented on GitHub (Aug 8, 2017):

@IDobrelya I have port, say, 4567 which runs my main SSH server that I use to access the server. I then have Gitea running on 22 with the inbuilt SSH server. I have verified that public key authentication succeeds with ssh user@host -vvv. That can't be problem. In addition, everything works as intended with gogs, the project that gitea was forked from.

@sbrl commented on GitHub (Aug 8, 2017): @IDobrelya I have port, say, 4567 which runs my main SSH server that I use to access the server. I then have Gitea running on 22 with the inbuilt SSH server. I have verified that public key authentication succeeds with `ssh user@host -vvv`. That can't be problem. In addition, everything works as intended with gogs, the project that gitea was forked from.

GiteaMirror commented

@sbrl commented on GitHub (Oct 15, 2017):

Hello again, @lunny! I've just updated to Gitea 1.2.0, and I've got an update for you - the error message has changed! Here's the new message:

Gitea: Internal error
Failed to get repository: no such column: size

@sbrl commented on GitHub (Oct 15, 2017): Hello again, @lunny! I've just updated to Gitea 1.2.0, and I've got an update for you - the error message has changed! Here's the new message: ``` Gitea: Internal error Failed to get repository: no such column: size ```

GiteaMirror commented

@builderall commented on GitHub (Oct 28, 2017):

I can use ssh with below setup. Gitea Version: 5f4210a
I'm using it on docker (port is mapped to 10022->22). Have ssh config file on client side as follows
Host hostname
Port 10022
IdentityFile ~/.ssh/id_rsa

Also make sure the permission on file is 600 if it is on linux. Hope this helps.
Thanks

@builderall commented on GitHub (Oct 28, 2017): I can use ssh with below setup. Gitea Version: 5f4210a I'm using it on docker (port is mapped to 10022->22). Have ssh config file on client side as follows Host hostname Port 10022 IdentityFile ~/.ssh/id_rsa Also make sure the permission on file is 600 if it is on linux. Hope this helps. Thanks

GiteaMirror commented

@sbrl commented on GitHub (Oct 28, 2017):

@builderall Nope, sorry! That doesn't help really. I'm not currently using docker though. I've checked the permissions on all files involved like a million times 😕

@sbrl commented on GitHub (Oct 28, 2017): @builderall Nope, sorry! That doesn't help really. I'm not currently using docker though. I've checked the permissions on all files involved like a million times :confused:

GiteaMirror commented

@sbrl commented on GitHub (Dec 11, 2017):

Ok, I've updated to giteaa v1.3.1, @lunny - here's what it says now:

Host key fingerprint is SHA256:K/VB82hyTNzYH2suaufGRPWoqSlbN9C9avFk//yspFs

Gitea: Internal error
Failed to get repository: no such column: size
fatal: Could not read from remote repository.

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

.....and then in gitea.log:

2017/12/11 11:50:22 [T] SSH: Handshaking for 5.198.44.45:56346
2017/12/11 11:50:22 [T] SSH: Connection from 5.198.44.45:56346 (SSH-2.0-OpenSSH_7.4p1 Ubuntu-10)
2017/12/11 11:50:22 [T] SSH: Payload: git-upload-pack 'sbrl/SpritePacker.git'
2017/12/11 11:50:22 [T] SSH: Arguments: [serv key-12 --config=/srv/git/gitea/custom/conf/app.ini]
2017/12/11 11:50:22 [...a/modules/ssh/ssh.go:103 func1()] [E] SSH: Wait: exit status 1

....and then in serv.log:

``
2017/12/11 11:52:44 [...io/gitea/cmd/serv.go:174 runServ()] [F] Failed to get repository: no such column: size


Hrm. That error points me [here](https://github.com/go-gitea/gitea/blob/v1.3.1/cmd/serv.go#L174) in Gitea's source code. I'm now thinking it's a database error because I don't have a required column. I can provide a copy of my database on request for inspection.

@sbrl commented on GitHub (Dec 11, 2017): Ok, I've updated to giteaa v1.3.1, @lunny - here's what it says now: ``` Host key fingerprint is SHA256:K/VB82hyTNzYH2suaufGRPWoqSlbN9C9avFk//yspFs Gitea: Internal error Failed to get repository: no such column: size fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. ``` .....and then in `gitea.log`: ``` 2017/12/11 11:50:22 [T] SSH: Handshaking for 5.198.44.45:56346 2017/12/11 11:50:22 [T] SSH: Connection from 5.198.44.45:56346 (SSH-2.0-OpenSSH_7.4p1 Ubuntu-10) 2017/12/11 11:50:22 [T] SSH: Payload: git-upload-pack 'sbrl/SpritePacker.git' 2017/12/11 11:50:22 [T] SSH: Arguments: [serv key-12 --config=/srv/git/gitea/custom/conf/app.ini] 2017/12/11 11:50:22 [...a/modules/ssh/ssh.go:103 func1()] [E] SSH: Wait: exit status 1 ``` ....and then in `serv.log`: `` 2017/12/11 11:52:44 [...io/gitea/cmd/serv.go:174 runServ()] [F] Failed to get repository: no such column: size ``` Hrm. That error points me [here](https://github.com/go-gitea/gitea/blob/v1.3.1/cmd/serv.go#L174) in Gitea's source code. I'm now thinking it's a database error because I don't have a required column. I can provide a copy of my database on request for inspection.

GiteaMirror commented

@lafriks commented on GitHub (Dec 11, 2017):

Migrations seems not to be run correctly... As repository seems to be missing size column

@lafriks commented on GitHub (Dec 11, 2017): Migrations seems not to be run correctly... As repository seems to be missing size column

GiteaMirror commented

@sbrl commented on GitHub (Dec 11, 2017):

@lafriks Is that something I can run again manually? Or should I just create a size column as an int in the repository table in data/gogs.db?

@sbrl commented on GitHub (Dec 11, 2017): @lafriks Is that something I can run again manually? Or should I just create a `size` column as an `int` in the `repository` table in `data/gogs.db`?

GiteaMirror commented

@sbrl commented on GitHub (Dec 11, 2017):

Update: Yeah, I've got the size column issue fixed, so now I'm getting the old

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.

error again. Here's the logging output: https://hastebin.com/idalidemov

@sbrl commented on GitHub (Dec 11, 2017): Update: Yeah, I've got the size column issue fixed, so now I'm getting the old ``` 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. ``` error again. Here's the logging output: https://hastebin.com/idalidemov

GiteaMirror commented

2025-11-02 03:30:17 -06:00

@lunny commented on GitHub (Dec 11, 2017):

could you find the ssh key on table public_key where id=12?

@lunny commented on GitHub (Dec 11, 2017): could you find the ssh key on table public_key where id=12?

GiteaMirror commented

@sbrl commented on GitHub (Dec 11, 2017):

@lunny Apparently it doesn't exist!

@sbrl commented on GitHub (Dec 11, 2017): @lunny Apparently it doesn't exist!

GiteaMirror commented

2025-11-02 03:30:17 -06:00

@monofon commented on GitHub (Mar 22, 2018):

I just ran into this same problem with a clean install of Gitea 1.4.0-rc2 on a fully patched Ubuntu 16.04.4 LTS. SSH access to a brand new repository does not work with the following message:

Gitea: Internal error
Failed to get repository: no such table: repository
fatal: Could not read from remote repository.

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

SSH access to the machine with ssh -T git@... works fine and reports:

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.

I was previously running a Gogs instance, where everything worked with this particular SSH key and about 100 others.

@monofon commented on GitHub (Mar 22, 2018): I just ran into this same problem with a clean install of Gitea 1.4.0-rc2 on a fully patched Ubuntu 16.04.4 LTS. SSH access to a brand new repository does not work with the following message: ``` Gitea: Internal error Failed to get repository: no such table: repository fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. ``` SSH access to the machine with `ssh -T git@...` works fine and reports: ``` 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. ``` I was previously running a Gogs instance, where everything worked with this particular SSH key and about 100 others.

GiteaMirror commented

2025-11-02 03:30:17 -06:00

@monofon commented on GitHub (Mar 22, 2018):

Funny. I made it work. Here is what happened:

Database configuration is at default settings:

[database]
DB_TYPE  = sqlite3
PATH     = data/gitea.db

Start Gitea like this:

cd /home/git
./gitea/gitea

Database is created in /home/git/gitea/data/gitea.db.

Try SSH access to a newly created repo, get the error above. Because the error says:

Failed to get repository: no such table: repository

Check /home/git/gitea/data/gitea.db manually. The file exists, but is empty!

Find the actual database in /home/git/data/gitea.db.

Change the database configuration to use an absolute path:

[database]
DB_TYPE  = sqlite3
PATH     = /home/git/gitea/data/gitea.db

Move the database from /home/git/data/gitea.db to /home/git/gitea/data/gitea.db.

Everything works fine.

There seems to confusion as to how to interpret a relative database path. Mostly it seems to be used relative to the current directory, but sometimes relative to the location of the gitea executable.

@monofon commented on GitHub (Mar 22, 2018): Funny. I made it work. Here is what happened: Database configuration is at default settings: ``` [database] DB_TYPE = sqlite3 PATH = data/gitea.db ``` Start Gitea like this: ``` cd /home/git ./gitea/gitea ``` Database is created in ` /home/git/gitea/data/gitea.db`. Try SSH access to a newly created repo, get the error above. Because the error says: ``` Failed to get repository: no such table: repository ``` Check `/home/git/gitea/data/gitea.db` manually. The file exists, but is empty! Find the actual database in `/home/git/data/gitea.db`. Change the database configuration to use an absolute path: ``` [database] DB_TYPE = sqlite3 PATH = /home/git/gitea/data/gitea.db ``` Move the database from `/home/git/data/gitea.db` to `/home/git/gitea/data/gitea.db`. Everything works fine. There seems to confusion as to how to interpret a relative database path. Mostly it seems to be used relative to the current directory, but sometimes relative to the location of the `gitea` executable.

GiteaMirror commented

2025-11-02 03:30:18 -06:00

@sbrl commented on GitHub (Mar 24, 2018):

Hrm. I've got a slightly different error, @monofon:

Gitea: Invalid key ID
Invalid key ID[key-14]: public key does not exist [id: 14]

Thoughts?

@sbrl commented on GitHub (Mar 24, 2018): Hrm. I've got a slightly different error, @monofon: ``` Gitea: Invalid key ID Invalid key ID[key-14]: public key does not exist [id: 14] ``` Thoughts?

GiteaMirror commented

2025-11-02 03:30:18 -06:00

@lunny commented on GitHub (Mar 25, 2018):

@sbrl regenerated sshkeys on the admin panel

@lunny commented on GitHub (Mar 25, 2018): @sbrl regenerated sshkeys on the admin panel

GiteaMirror commented

2025-11-02 03:30:18 -06:00

@sbrl commented on GitHub (Mar 25, 2018):

From the admin panel:

There is no need to do this if you are using the built-in SSH server.

I'm using the inbuilt SSH server, @lunny - so I shouldn't need to?

@sbrl commented on GitHub (Mar 25, 2018): From the admin panel: > There is no need to do this if you are using the built-in SSH server. I'm using the inbuilt SSH server, @lunny - so I shouldn't need to?

GiteaMirror commented

2025-11-02 03:30:19 -06:00

@lunny commented on GitHub (Mar 25, 2018):

@sbrl yes. maybe your public key has been deleted?

@lunny commented on GitHub (Mar 25, 2018): @sbrl yes. maybe your public key has been deleted?

GiteaMirror commented

2025-11-02 03:30:19 -06:00

@sbrl commented on GitHub (Mar 25, 2018):

@lunny Nope, it's still there and doesn't work - even after deleting and readding.

@sbrl commented on GitHub (Mar 25, 2018): @lunny Nope, it's still there and doesn't work - even after deleting and readding.

GiteaMirror commented

2025-11-02 03:30:19 -06:00

@sbrl commented on GitHub (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 commented on GitHub (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.

GiteaMirror commented

@sbrl commented on GitHub (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?

@sbrl commented on GitHub (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?

GiteaMirror commented

@lafriks commented on GitHub (Mar 26, 2018):

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

@lafriks commented on GitHub (Mar 26, 2018): Regenerate ssh authorized keys file using admin section in web UI and try again

GiteaMirror commented

@sbrl commented on GitHub (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 commented on GitHub (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. ```

GiteaMirror commented

2025-11-02 03:30:21 -06:00

@sbrl commented on GitHub (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}

@sbrl commented on GitHub (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} ```

GiteaMirror commented

@techknowlogick commented on GitHub (Jun 4, 2018):

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

@techknowlogick commented on GitHub (Jun 4, 2018): @sbrl are you still using the same version of Gitea?

GiteaMirror commented

2025-11-02 03:30:21 -06:00

@sbrl commented on GitHub (Jun 4, 2018):

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

@sbrl commented on GitHub (Jun 4, 2018): @techknowlogick I'm currently on v1.4.1 of Gitea, on Ubuntu Server 16.04 LTS.

GiteaMirror commented

2025-11-02 03:30:21 -06:00

@adrinux commented on GitHub (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 commented on GitHub (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.

GiteaMirror commented

@adrinux commented on GitHub (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.

@adrinux commented on GitHub (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.

GiteaMirror commented

@sbrl commented on GitHub (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.

@sbrl commented on GitHub (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 :confused: If at all possible, I'd like to avoid giving the git user a shell.

GiteaMirror commented

@adrinux commented on GitHub (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.

@adrinux commented on GitHub (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.

GiteaMirror commented

@sbrl commented on GitHub (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.

@sbrl commented on GitHub (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.

GiteaMirror commented

@adrinux commented on GitHub (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?

@adrinux commented on GitHub (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?

GiteaMirror commented

@sbrl commented on GitHub (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)

@sbrl commented on GitHub (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](https://hastebin.com/fahovadiki.ini) ([screenshot of admin page](https://user-images.githubusercontent.com/9929737/41468001-657846cc-70a0-11e8-9a85-b9ac8a5d95b9.png))

GiteaMirror commented

@adrinux commented on GitHub (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.

@adrinux commented on GitHub (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](https://docs.gitea.io/en-us/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.

GiteaMirror commented