Deploy key does not have access to private repository

[TheAssassin]

• Gitea version (or commit ref): 1.2 (Docker image 3e606f47a47e)
• Git version: not relevant
• Operating system: not relevant
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant

Description

I tried to use a deploy key with a private repository on a private instance of Gitea running in a Docker container. Apparently, for private Git repositories, the deploy key doesn't have permission to read the repository, though.

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

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

As soon as I publish the repository, the key works as expected.

It's a bit disruptive to have to switch the state of a repository for every deployment. I'd propose to allow deploy keys to clone the relevant repository even if it's private.

(I think a workaround might be to add a "machine user" or something like that, and add that to the repository.)

Oh, and please, improve that error message a bit. I'm not even sure whether the current behavior is intended, the message in the log extract I posted actually implies it might be an error.

[lunny]

see https://github.com/go-gitea/gitea/blob/master/cmd/serv.go#L208, I have checked the code. It seems it's right. Maybe you can check whether your key [id=1] is exist?

[TheAssassin]

Dump from deploy_key:

----+--------+---------+----------+----------------------------------------------------+--------------+--------------
  3 |      4 |      10 | abcdefgh | SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |   1504190000 |            0

I was pretty sure that the key ID is not 1, as I deleted and recreated that deploy key for that repository a few times before trying it at first.

The repo ID is correct. The key is in the public_key database, and the fingerprints are equal. Mode is 1 and type is 2. All this appears valid to me.

What I don't understand is this error message about key 1. Why does Gitea show it when going private, and work fine when going public with the repository?

[lafriks]

Check authorized keys file is there key id 1 gitea command

[TheAssassin]

@lafriks the key with the ID 4 that I re-added a few times is in there more than once (1, 2, 4). The problem now appears to be that the keys are not purged from this file, even when they're deleted from the database. The SSH key apparently matches the key with ID 1 first, thus, Gitea checks this ID. Since the key does not exist (and is therefore not authorized to access the repository), the client is denied access. (The key is by the way just once in the database).

#1870 should fix such issues and also implements a superior alternative to the authorized_keys file. But as the people mentioned in there, it might break compatibility for some people. I guess the appropriate fix for this bug is to fix the code generating this file.

[lafriks]

You should regenerate it from admin interface and check if that helps

[TheAssassin]

Well, that obviously fixes the problem. Though, I assume something in the process of deleting deploy keys doesn't trigger that function. I'd suggest to fix this issue by doing exactly that.

[lunny]

I think the regenerate should be called when a key delete from the UI. see https://github.com/go-gitea/gitea/blob/master/models/ssh_key.go#L406

[TheAssassin]

Yes. But, thinking about it, it was not regenerated either when adding the key again. I'd say, the best way is to do it in both places to be on the safe side.

[bkcsoft]

#1870 would fix this by not using the generated file at all :)

[lafriks]

@bkcsoft but that requires special openssh server configuration and is it possible to configure it only for single user?

[bkcsoft]

@lafriks

AuthorizedKeysCommand
Specifies a program to be used for lookup of the user's public keys. The program will be invoked with its first argument the name of the user being authorized, and should produce on standard output AuthorizedKeys lines (see AUTHORIZED_KEYS in sshd(8)). By default (or when set to the empty string) there is no AuthorizedKeysCommand run. If the AuthorizedKeysCommand does not successfully authorize the user, authorization falls through to the AuthorizedKeysFile. Note that this option has an effect only with PubkeyAuthentication turned on.

https://linux.die.net/man/5/sshd_config

[TheAssassin]

IIRC from Phabricator (which I cited in the other issue by the way) this requires a second instance of OpenSSH. Also, as stated in that other issue, Dropbear etc. don't provide this option. I guess it's still mandatory to provide this as a fallback solution unless support for anything but OpenSSH 6.2+ is dropped.

[TheAssassin]

Any ETA for #2441 (comment)?

[stale]

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.

[TheAssassin]

So, the key file is still not re-generated when a key is deleted?

[stale]

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]

This is fixed since PR #5939