Gitea: Read / Write deploy key not working

[abueschel]

• Gitea version (or commit ref): a2a49c9 (from Docker image gitea/gitea)
• Git version: 2.15.0
• Operating system: Official docker image running on CentOS 7
• 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:

Mar 14 16:58:20 syslogd started: BusyBox v1.27.2
/etc/ssh/sshd_config line 32: Deprecated option UsePrivilegeSeparation
Mar 14 15:58:20 sshd[15]: Server listening on :: port 22.
Mar 14 15:58:20 sshd[15]: Server listening on 0.0.0.0 port 22.
2018/03/14 16:58:20 [T] AppPath: /app/gitea/gitea
2018/03/14 16:58:20 [T] AppWorkPath: /app/gitea
2018/03/14 16:58:20 [T] Custom path: /data/gitea
2018/03/14 16:58:20 [T] Log path: /data/gitea/log
2018/03/14 16:58:20 Serving [::]:3000 with pid 14
[...]
Mar 14 15:59:15 sshd[56]: rexec line 32: Deprecated option UsePrivilegeSeparation
Mar 14 15:59:15 sshd[56]: Accepted publickey for git from 172.19.0.1 port 34068 ssh2: RSA SHA256:[...]
Mar 14 15:59:15 sshd[58]: Received disconnect from 172.19.0.1 port 34068:11: disconnected by user
Mar 14 15:59:15 sshd[58]: Disconnected from user git 172.19.0.1 port 34068

Description

If i add a deploy key to one of my repositories without enabling "Allow write access" I can clone/pull. If I add the exact same key to the repo with Read / Write access, i get an error:

git clone ssh://[email protected]:2222/user/repo.git
Cloning into 'repo'...
Gitea: Key access denied
Deploy key access denied: [key_id: 2, repo_id: 10]
fatal: Could not read from remote repository.

I also could reproduce the issue with the newest 1.4 Docker image.

I hope this is all the relevant information but I can provide more if needed.

[techknowlogick]

In the admin panel have you tried running the Rewrite '.ssh/authorized_keys' file (for Gitea SSH keys). operation?

[abueschel]

Yes I tried that with no success. I also updated the Image to c28bf94 and ran it again today, the error still persists.

[manuelmohr]

I have the exact same problem. Rewriting authorized_keys did not help either.

[sphrak]

Can confirm this issue still persists on 1.4.3. To clarify what breaks is the write mode -- not read mode, that works. Rewriting the authorized_keys does not change anything it still doesnt work.

[MarAvFe]

I had the same issue yesterday. I was running gitlab and migrated all repos to gitea. After all the config, ssh keys wouldn't work. Rewriting the ssh file wouldn't work. But I had to add a new config to workingDirectory/custom/conf/app.ini:

; https://github.com/go-gitea/gitea/blob/master/custom/conf/app.ini.sample#L153
[server]
; Root path of SSH directory, default is '~/.ssh', but you have to use '/home/git/.ssh'.
SSH_ROOT_PATH = /var/opt/gitlab/.ssh

Of course, the value is dependent of your server config. After that, I added the key to my user, and it didn't work.

But I tried the Rewrite '.ssh/authorized_keys' file (for Gitea SSH keys). operation and it worked.

This is on Gitea v1.5.1

[westhom]

Also ran into the issue on 1.5.3. I added a read-only deploy key but I got the error when cloning:

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

Running the rewrite authorized_keys command from the dashboard fixed the issue.

[pew]

I have this issue as well with gitea 1.5.3, setting the SSH_ROOT_PATH and rewriting the keys didn't work.

Gitea: Key access denied
Deploy key access denied: [key_id: 16, repo_id: 56]
fatal: Could not read from remote repository.

However, when giving the deploy key also write access it works. Which is something I don't want though.

[lunny]

I think this should be a design error on public_key table. We have to keep Fingerprint unique so that there is no duplicated public key on the authorized_keys file.

[lunny]

I will try to send a PR to fix that and migrate old data to new struct.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[zeripath]

Fixed by #5939