Deploy key does not have access to private repository #1030

@TheAssassin commented on GitHub (Sep 2, 2017):

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?

@TheAssassin commented on GitHub (Sep 2, 2017): Dump from `deploy_key`: ``` id | key_id | repo_id | name | fingerprint | created_unix | updated_unix ----+--------+---------+----------+----------------------------------------------------+--------------+-------------- 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?

GiteaMirror commented

@lafriks commented on GitHub (Sep 2, 2017):

Check authorized keys file is there key id 1 gitea command

@lafriks commented on GitHub (Sep 2, 2017): Check authorized keys file is there key id 1 gitea command

GiteaMirror commented

@TheAssassin commented on GitHub (Sep 2, 2017):

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

@TheAssassin commented on GitHub (Sep 2, 2017): @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.

GiteaMirror commented

@lafriks commented on GitHub (Sep 2, 2017):

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

@lafriks commented on GitHub (Sep 2, 2017): You should regenerate it from admin interface and check if that helps

GiteaMirror commented

@TheAssassin commented on GitHub (Sep 2, 2017):

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.

@TheAssassin commented on GitHub (Sep 2, 2017): 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.

GiteaMirror commented

@lunny commented on GitHub (Sep 3, 2017):

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

@lunny commented on GitHub (Sep 3, 2017): 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

GiteaMirror commented

@TheAssassin commented on GitHub (Sep 3, 2017):

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.

@TheAssassin commented on GitHub (Sep 3, 2017): 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.

GiteaMirror commented

@bkcsoft commented on GitHub (Sep 4, 2017):

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

@bkcsoft commented on GitHub (Sep 4, 2017): #1870 would fix this by not using the generated file at all :)

GiteaMirror commented

@lafriks commented on GitHub (Sep 4, 2017):

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

@lafriks commented on GitHub (Sep 4, 2017): @bkcsoft but that requires special openssh server configuration and is it possible to configure it only for single user?

GiteaMirror commented

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

@bkcsoft commented on GitHub (Sep 4, 2017):

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

@bkcsoft commented on GitHub (Sep 4, 2017): @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

GiteaMirror commented

@TheAssassin commented on GitHub (Sep 4, 2017):

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 commented on GitHub (Sep 4, 2017): 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.

GiteaMirror commented

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

Any ETA for https://github.com/go-gitea/gitea/issues/2441#issuecomment-326781903?

@TheAssassin commented on GitHub (Jun 4, 2018): Any ETA for https://github.com/go-gitea/gitea/issues/2441#issuecomment-326781903?

GiteaMirror commented

@stale[bot] commented on GitHub (Jan 25, 2019):

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.

@stale[bot] commented on GitHub (Jan 25, 2019): 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.

GiteaMirror commented