Cannot clone private repo from organization

[Governa]

• Gitea version (or commit ref):
• Git version:
• Operating system:
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No - Server down
  • Not relevant
• Log gist:

Description

I have two users and an organization:

• user_1: User that created the repo inside the organization
• user_2: Jenkins user
• org: Org with one added team(read only access, user_2 as member) and Owner team with user_1

Cloning an private repository with user_1 works.

Trying to clone an organization's private repository with user_2, fails with the following message:

  Cloning into 'my_repo'...
  Gitea: Key access denied
  Deploy key access denied: [key_id: 6, repo_id: 58]
  fatal: Could not read from remote repository.
  
  Please make sure you have the correct access rights
  and the repository exists

If I simply make the repository public, user_2 is able to clone it.

[lafriks]

Could be that same key has added multiple times?

[Governa]

I don't think so. Would it cause this problem only on private repositories?

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

[lunny]

This maybe resolved? @Governa could you confirm that?

[jorgefuertes]

Not resolved, I have the same problem at v1.7. I can't clone a private repo with a deploy (read-only) rsa key, auth works but clone is denied.

Making it public it works.

And yes, key is duped but I can't select an already uploaded key for a new repo, GUI makes you recreate the key for every repo you need to clone.

[jorgefuertes]

I don't think so. Would it cause this problem only on private repositories?

Absolutely, duped key doesn't work in private repos, but there's no way to have no duplicated keys cause they are needed at every repo you need to clone.

[lunny]

Could you run Update the '.ssh/authorized_keys' file with Gitea SSH keys. (Not needed for the built-in SSH server.) on Admin UI before you do that?

[lunny]

Have you deleted some public keys? It seems #5684 resolved a key deleted issue.

[jorgefuertes]

Did rebuild the Keys and it doesn't works. Its a bug, not happenning with internal ssh server, change to it and you can clone without problem.

[zeripath]

Ok so that log message is coming from cmd/serv.go:

// Check if this deploy key belongs to current repository.
			has, err := private.HasDeployKey(key.ID, repo.ID)
			if err != nil {
				fail("Key access denied", "Failed to access internal api: [key_id: %d, repo_id: %d]", key.ID, repo.ID)
			}
			if !has {
				fail("Key access denied", "Deploy key access denied: [key_id: %d, repo_id: %d]", key.ID, repo.ID)
			}

So it seems that in the original bug report the problem was that key 6 wasn't associated with repo 58.

@jorgefuertes is your error the same? That is it is basically:

Deploy key access denied: [key_id: x, repo_id: y]

If so could you check that you don't have two copies of the same key in the db and which repo key X is associated with. It shouldn't happen that two copies of the same keys end up with different IDs but I guess it's possible.

In terms of the difference between the builtin server vs. external they both use this code path in cmd/serv.go - the only difference is the determination of the keyid, so my suspicion is that this key has multiple IDs.

[jorgefuertes]

Certenly, that's the error, an yes, key are duped across different repos, because you can't select a previously uploaded key from another repo.

Beside the bug (normal user doesn't need to know about internal or external SSH server, or duped keys), I think I would love to have a common pubkey store, system or organization wide, to choose deploy keys for a project.

Thanks everyone.

[zeripath]

This isn't an internal external SSH issue. The problem is the duplicated key id for the same key.

It's just that the external SSH and the internal SSH just have slightly different orders for choosing which key id matches a particularly key. There will be repos you can access when using the internal that you can't when using the external and vice versa.

Now on master it shouldn't be possible for you to have two deploy key IDs for the same deploy key content so what version are you running?

[jorgefuertes]

I'm running 1.7 right now but tried several versions before.

I don't have duped keys into the same repo, I want to make it clear. There are duped keys in a system wide view and that fails using external SSH server.

I have no issue with internal SSH server until now.