mirror of
https://github.com/go-gitea/gitea.git
synced 2026-07-16 13:20:06 -05:00
UpdatePublicKey: Failed to update public key: public key does not exist #843
Closed
opened 2025-11-02 03:38:41 -06:00 by GiteaMirror
·
21 comments
No Branch/Tag Specified
main
release/v1.25
release/v1.24
release/v1.23
release/v1.22
release/v1.21
release/v1.20
release/v1.19
release/v1.18
release/v1.17
release/v1.16
release/v1.15
release/v1.14
release/v1.13
release/v1.12
release/v1.11
release/v1.10
release/v1.9
release/v1.8
v1.25.3
v1.25.2
v1.25.1
v1.25.0
v1.24.7
v1.25.0-rc0
v1.26.0-dev
v1.24.6
v1.24.5
v1.24.4
v1.24.3
v1.24.2
v1.24.1
v1.24.0
v1.23.8
v1.24.0-rc0
v1.25.0-dev
v1.23.7
v1.23.6
v1.23.5
v1.23.4
v1.23.3
v1.23.2
v1.23.1
v1.23.0
v1.23.0-rc0
v1.24.0-dev
v1.22.6
v1.22.5
v1.22.4
v1.22.3
v1.22.2
v1.22.1
v1.22.0
v1.23.0-dev
v1.22.0-rc1
v1.21.11
v1.22.0-rc0
v1.21.10
v1.21.9
v1.21.8
v1.21.7
v1.21.6
v1.21.5
v1.21.4
v1.21.3
v1.21.2
v1.20.6
v1.21.1
v1.21.0
v1.21.0-rc2
v1.21.0-rc1
v1.20.5
v1.22.0-dev
v1.21.0-rc0
v1.20.4
v1.20.3
v1.20.2
v1.20.1
v1.20.0
v1.19.4
v1.21.0-dev
v1.20.0-rc2
v1.20.0-rc1
v1.20.0-rc0
v1.19.3
v1.19.2
v1.19.1
v1.19.0
v1.19.0-rc1
v1.20.0-dev
v1.19.0-rc0
v1.18.5
v1.18.4
v1.18.3
v1.18.2
v1.18.1
v1.18.0
v1.17.4
v1.18.0-rc1
v1.19.0-dev
v1.18.0-rc0
v1.17.3
v1.17.2
v1.17.1
v1.17.0
v1.17.0-rc2
v1.16.9
v1.17.0-rc1
v1.18.0-dev
v1.16.8
v1.16.7
v1.16.6
v1.16.5
v1.16.4
v1.16.3
v1.16.2
v1.16.1
v1.16.0
v1.15.11
v1.17.0-dev
v1.16.0-rc1
v1.15.10
v1.15.9
v1.15.8
v1.15.7
v1.15.6
v1.15.5
v1.15.4
v1.15.3
v1.15.2
v1.15.1
v1.14.7
v1.15.0
v1.15.0-rc3
v1.14.6
v1.15.0-rc2
v1.14.5
v1.16.0-dev
v1.15.0-rc1
v1.14.4
v1.14.3
v1.14.2
v1.14.1
v1.14.0
v1.13.7
v1.14.0-rc2
v1.13.6
v1.13.5
v1.14.0-rc1
v1.15.0-dev
v1.13.4
v1.13.3
v1.13.2
v1.13.1
v1.13.0
v1.12.6
v1.13.0-rc2
v1.14.0-dev
v1.13.0-rc1
v1.12.5
v1.12.4
v1.12.3
v1.12.2
v1.12.1
v1.11.8
v1.12.0
v1.11.7
v1.12.0-rc2
v1.11.6
v1.12.0-rc1
v1.13.0-dev
v1.11.5
v1.11.4
v1.11.3
v1.10.6
v1.12.0-dev
v1.11.2
v1.10.5
v1.11.1
v1.10.4
v1.11.0
v1.11.0-rc2
v1.10.3
v1.11.0-rc1
v1.10.2
v1.10.1
v1.10.0
v1.9.6
v1.9.5
v1.10.0-rc2
v1.11.0-dev
v1.10.0-rc1
v1.9.4
v1.9.3
v1.9.2
v1.9.1
v1.9.0
v1.9.0-rc2
v1.10.0-dev
v1.9.0-rc1
v1.8.3
v1.8.2
v1.8.1
v1.8.0
v1.8.0-rc3
v1.7.6
v1.8.0-rc2
v1.7.5
v1.8.0-rc1
v1.9.0-dev
v1.7.4
v1.7.3
v1.7.2
v1.7.1
v1.7.0
v1.7.0-rc3
v1.6.4
v1.7.0-rc2
v1.6.3
v1.7.0-rc1
v1.7.0-dev
v1.6.2
v1.6.1
v1.6.0
v1.6.0-rc2
v1.5.3
v1.6.0-rc1
v1.6.0-dev
v1.5.2
v1.5.1
v1.5.0
v1.5.0-rc2
v1.5.0-rc1
v1.5.0-dev
v1.4.3
v1.4.2
v1.4.1
v1.4.0
v1.4.0-rc3
v1.4.0-rc2
v1.3.3
v1.4.0-rc1
v1.3.2
v1.3.1
v1.3.0
v1.3.0-rc2
v1.3.0-rc1
v1.2.3
v1.2.2
v1.2.1
v1.2.0
v1.2.0-rc3
v1.2.0-rc2
v1.1.4
v1.2.0-rc1
v1.1.3
v1.1.2
v1.1.1
v1.1.0
v1.0.2
v1.0.1
v1.0.0
v0.9.99
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
Mirrored from GitHub Pull Request
No Label
type/bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/gitea#843
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @gsantner on GitHub (Jun 25, 2017).
735676267e[x]):Description
Sometimes i'm not able to pull from gitea because of an
UpdatePublicKeyerror. As also the CI service pulls from gitea repos, this creates a lot of build errors every day. The keys are all added to the gitea account and do have access to repos. I also deleted, readded the keys and did a (gite admin)-ssh key rewrite.gitea serv.log:
database entry (freshly added today):
client:
@ethantkoenig commented on GitHub (Jun 26, 2017):
@gsantner The
INSERTcommand you posted isn't valid; the column count doesn't match the value count, andcreatedandupdatedare not columns in the public_key table.Are you sure there is a key with id 20 in the database (i.e.
SELECT * FROM public_key WHERE id=20returns something)?If for some reason you're not able to directly run the
SELECTcommand, you could instead use theGET /api/v1/users/:username/keysAPI endpoint to double-check that the key does in fact exist in the database.@gsantner commented on GitHub (Jun 26, 2017):
Sorry maybe I accidentally removed one during pasting to github. below is the export again.
Yes, the query gets exactly this line, so I'm sure theres ID 20 in there.
API: tried
https://DOMAIN/gitea/api/v1/users/gregor/keysand it just shows me a white page without any error (accessed via browser). Theres also no error or other message in the log from this api query.Did
tail -f *.loginsidecode.gitea.io/gitea/logIt does, I directly accessed the database gitea is using.
As said above, I can access/clone/push. But sometimes (multiple times a day, and often at CI) it just gives this error. The keys are correctly setted up at my clients.
@ethantkoenig commented on GitHub (Jun 29, 2017):
@gsantner What is the value of
setting.LocalURLin your setup (specifically inside theservsubcommand)?The request
POST {setting.LocalURL}/api/internal/ssh/20/update(made here) is returning a 500, because whatever gitea instance is running at that URL is talking to a different database than the one that contains your key.@gsantner commented on GitHub (Jun 29, 2017):
I dont have any debugging tools or like that installed on the system. What shall I do, and where I can find the piece of information then?
@gsantner commented on GitHub (Jun 29, 2017):
Btw: There is just one Gitea instance running on the system
@ethantkoenig commented on GitHub (Jun 29, 2017):
@gsantner From looking at the logs you've posted,
setting.LocalURLishttp://localhost:5642. Can do you the following:custom/conf/app.ini) is correct? Specifically the database config?http://localhost:5642/user/settings/keys(authenticated as the user with id 1), and confirm that you see the key you inserted (SHA256:arjdRrafsdfsdfadsfsd)If neither of these reveal anything, then I'm stuck 😕
@gsantner commented on GitHub (Jun 29, 2017):
1 ) Well, it's localhost at a port yes, but apache is serving in front. (Which shouldn't matter anyway as I'm cloning via SSH)
@lafriks commented on GitHub (Jul 2, 2017):
Does in your app.ini config file has
INTERNAL_TOKENvalue?@gsantner commented on GitHub (Jul 3, 2017):
@lafriks Yep, under
[security]@lafriks commented on GitHub (Jul 3, 2017):
and it is not empty, right? (do not post it here just confirm it is not empty)
@gsantner commented on GitHub (Jul 3, 2017):
of course it is there
@lunny commented on GitHub (Jul 13, 2017):
Could you reproduce that? Maybe take a look at the xorm.log?
@gsantner commented on GitHub (Jul 13, 2017):
Yes, reproducible. serv.log.txt / xorm.log.txt. I deleted all logs before starting the script.
Maybe some kind of race condition? Maybe related to a timestamp?
outputs: (59 clones out of 100 worked actually / loaded repo fully).
@lafriks commented on GitHub (Jul 13, 2017):
Thanks for detailed info, I will look into this
@gsantner commented on GitHub (Jul 20, 2017):
@lafriks
Thanks for your fixes! Tried the script above again, and there are no warnings/erorrs anymore now. But still about half of the clones do not work.
In the Logs I can find
2017/07/20 16:15:08 [T] UpdatePublicKeyUpdated: http://localhost:PORT/api/internal/ssh/19/updatelines, but no public key error anymore. I don't know where the problem lies now, but there is still a bug.The problem may not occur so often when using it with one time push/pull for code updates, but if theres e.g. jenkins behind who does pull and make checks
@lafriks commented on GitHub (Jul 20, 2017):
@gsantner It works correctly wait before bash script finishes to execute and than check cloned repository count. Because at the end of git clone you have
&so ls executes faster than git commands are finished cloning repositories that's way you get wrong count. If you will wait a bit longer and run ls manually you will see correct count@gsantner commented on GitHub (Jul 20, 2017):
Thats what I tried too (before multiple script execution). fail2ban turned off. heres a log. I did check if some git is running too
log.txt
I tried the script too with 10 clones, that works. 100 may be a little heavy and unnatural, I'm just somewhat suprised it cannot be handled even if cloning is running from/to localhost. From the log: maybe an upstream bug in openssh?
@lafriks commented on GitHub (Jul 20, 2017):
@gsantner try adding sleep before ls, might be that when scripts exits it child processes are also killed
@gsantner commented on GitHub (Jul 20, 2017):
I did execute the commands manually after some time. as said, I'm sure no git clone was running. (At the multi-test two above yes, but not in the manual clones where the log comes from.)
log.txt
Am 20. Juli 2017 18:18:31 MESZ schrieb Lauris BH notifications@github.com:
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
@lafriks commented on GitHub (Jul 22, 2017):
@gsantner I found out why are you having problem with 100 parallel clones. It is actually not a gitea fault but ssh servers anti ddos protection. By default ssh configuration has
MaxStartups 10:30:60that means that it will start drop connections at rate 30% after it has 10 parallel yet unauthorized connections or more than 60 connections in total. When settingMaxStartups 100:30:120in/etc/ssh/sshd_configand restarting ssh server I had no problems and all 100 copies get cloned without errors.@gsantner commented on GitHub (Jul 22, 2017):
@lafriks Wow, thanks for finding that out 👍, and of course for fixing the bug