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

[sbrl]

• 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
  
  
  • [x] SQLite
  
  
• Can you reproduce the bug at https://try.gitea.io:
  
  
  
  • [ ] Yes (provide example URL)
  
  
  • [ ] No
  
  
  • [x] Not relevant
  
  
• Log gist:

2017/04/06 20:29:44 [T] SSH: Handshaking for 5.198.65.153:42250
2017/04/06 20:29:44 [T] SSH: Connection from 5.198.65.153:42250 (SSH-2.0-OpenSSH_7.3p1 Ubuntu-1)
2017/04/06 20:29:44 [T] SSH: Payload: git-upload-pack 'sbrl/alatael.git'
2017/04/06 20:29:44 [T] SSH: Arguments: [serv key-10 --config=/srv/git/gitea/custom/conf/app.ini]
2017/04/06 20:29:44 [...a/modules/ssh/ssh.go:103 func1()] [E] SSH: Wait: exit status 1

Description

If I create a new repository and then attempt to clone it, it doesn't let me. See the screenshot below.

Note that I've recently undergone a rather (painful) migration from gogs to gitea.

Screenshots

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

[sbrl]

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]

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]

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

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]

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

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]

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

[sbrl]

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

[sbrl]

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]

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]

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

[lunny]

Maybe you can use ssh -vvv [email protected] to debug where is the problem.

[sbrl]

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

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]

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]

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

[lunny]

so did you have ~/.ssh/config to indicate the sbrl_gogs when [email protected]?

[sbrl]

@lunny Yep

[xxdesmus]

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.

[sbrl]

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

[lunny]

How do you resolve your pull issue?

[sbrl]

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

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

[xxdesmus]

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

[lunny]

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

[xxdesmus]

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

[xxdesmus]

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.

[kermorgant]

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.

[lunny]

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

[kermorgant]

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

[sbrl]

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

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

[sbrl]

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.

[IDobrelya]

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.

[sbrl]

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

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

[builderall]

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

[sbrl]

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

[sbrl]

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

[lafriks]

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

[sbrl]

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

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

[lunny]

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

[sbrl]

@lunny Apparently it doesn't exist!

[monofon]

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]

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.

[sbrl]

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?

[lunny]

@sbrl regenerated sshkeys on the admin panel

[sbrl]

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?

[lunny]

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

[sbrl]

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

[sbrl]

Doing ssh -T [email protected] (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 [email protected] (the internal Gitea SSH server) gives nothing, and doesn't return.

[sbrl]

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

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

[sbrl]

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

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 [email protected] -> Hi there, You've successfully authenticated, but Gitea does not provide shell access.
• The test via the inbuilt SSH server hangs indefinitely (ssh -T [email protected]): 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]

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

[sbrl]

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

[adrinux]

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 [email protected]

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 [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype [email protected] 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 [email protected] 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]

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]

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

[adrinux]

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

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 [email protected]: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]

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]

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

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]

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

[sbrl]

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

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" <[email protected]>
USER    = [email protected]
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]

@sbrl maybe you can find the xorm.log.

[sbrl]

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

[lunny]

@sbrl that's a blank URL.

[sbrl]

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

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]

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

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

[sbrl]

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

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]

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]

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

[kratzercanby]

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.

[tanchekwei]

@kratzercanby Thank you so much for saving me A LOT of time. I have been trying to solve the problem for hours. Cheer~

[sbrl]

To an extent, I think the title of this issue is somewhat deceptive, since my specific issue was specifically related to a migration from Gogs to Gitea.

I guess a single error message can have a number of different root causes.