github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-09 04:25:18 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

SSH Public Keys not synchronized properly from LDAP, user/settings/keys throws 500 #11609

New Issue
Closed
opened 2025-11-02 09:42:23 -06:00 by GiteaMirror · 2 comments
GiteaMirror commented 2025-11-02 09:42:23 -06:00
Owner
Copy Link

Originally created by @everii-mapi on GitHub (Sep 7, 2023).

Description

As described in the title, upon changing the sshPublicKey Attribute within LDAP and running "Synchronize external user data", SSH key is not updated within Gitea. I also ran the task "Update the '.ssh/authorized_keys' file with Gitea SSH keys."

Debug Log shows

2023/09/07 09:46:09 ...s/asymkey/ssh_key.go:393:SynchronizePublicKeys() [T] synchronizePublicKeys[everii LDAP]: Handling Public SSH Key synchronization for user MYUSER
2023/09/07 09:46:09 ...s/asymkey/ssh_key.go:420:SynchronizePublicKeys() [T] synchronizePublicKeys[everii LDAP]: Public Keys are already in sync for MYUSER (Source:0/DB:0)

doctor check --all

[1] Check paths and basic configuration
 - [I] Configuration File Path:    "/etc/gitea/app.ini"
 - [I] Repository Root Path:       "/var/lib/gitea/data/gitea-repositories"
 - [I] Data Root Path:             "/var/lib/gitea/data"
 - [I] Custom File Root Path:      "/var/lib/gitea/custom"
 - [I] Work directory:             "/var/lib/gitea"
 - [I] Log Root Path:              "/var/lib/gitea/log"
OK

[2] Check Database Version
 - [I] Expected database version: 260
OK

[3] Check if user with wrong type exist
OK

[4] Check if OpenSSH authorized_keys file is up-to-date
OK

[5] Synchronize repo HEADs
 - [I] All 450 repos have their HEADs in the correct state
OK

All done.

Also, the page /user/settings/keys throws an Error 500:

An error occurred:

PANIC: runtime error: index out of range [0] with length 0
/usr/local/go/src/runtime/panic.go:884 (0x43d872)
/source/modules/web/routing/logger_manager.go:116 (0x23104e4)
/usr/local/go/src/runtime/panic.go:884 (0x43d872)
/usr/local/go/src/runtime/panic.go:113 (0x43b75e)
/source/models/asymkey/ssh_key.go:279 (0x131581c)
/source/routers/web/user/setting/keys.go:272 (0x25431f8)
/source/routers/web/user/setting/keys.go:32 (0x2540184)
/usr/local/go/src/reflect/value.go:586 (0x4aae0a)
/usr/local/go/src/reflect/value.go:370 (0x4aa0bb)
/source/modules/web/handler.go:176 (0x2312565)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/source/modules/web/handler.go:186 (0x23125fb)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/source/modules/web/handler.go:186 (0x23125fb)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/go/pkg/mod/github.com/go-chi/chi/v5@v5.0.8/chain.go:31 (0x17dc7cb)
/go/pkg/mod/github.com/go-chi/chi/v5@v5.0.8/mux.go:444 (0x17df6d5)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/source/modules/web/handler.go:186 (0x23125fb)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/source/modules/web/handler.go:186 (0x23125fb)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/source/modules/web/handler.go:186 (0x23125fb)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/go/pkg/mod/github.com/go-chi/chi/v5@v5.0.8/middleware/get_head.go:37 (0x24f5c0d)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/source/modules/web/handler.go:155 (0x231282b)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/source/modules/web/handler.go:186 (0x23125fb)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/source/modules/context/context.go:196 (0x1caaa6b)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/source/modules/web/handler.go:155 (0x231282b)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/go/pkg/mod/gitea.com/go-chi/session@v0.0.0-20230415140235-3182bcc14852/session.go:257 (0x184754a)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/source/modules/web/handler.go:155 (0x231282b)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/go/pkg/mod/github.com/go-chi/chi/v5@v5.0.8/mux.go:73 (0x17dd454)
/go/pkg/mod/github.com/go-chi/chi/v5@v5.0.8/mux.go:316 (0x17dee63)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/go/pkg/mod/github.com/go-chi/chi/v5@v5.0.8/mux.go:444 (0x17df6d5)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/go/pkg/mod/github.com/go-chi/chi/v5@v5.0.8/mux.go:73 (0x17dd454)
/go/pkg/mod/github.com/go-chi/chi/v5@v5.0.8/mux.go:316 (0x17dee63)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/go/pkg/mod/github.com/go-chi/chi/v5@v5.0.8/mux.go:444 (0x17df6d5)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/source/modules/web/routing/logger_manager.go:122 (0x2310313)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/source/modules/web/handler.go:155 (0x231282b)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/go/pkg/mod/github.com/chi-middleware/proxy@v1.1.1/middleware.go:37 (0x246ad16)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/source/modules/web/handler.go:155 (0x231282b)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/source/routers/common/middleware.go:45 (0x246dd14)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/source/modules/web/handler.go:155 (0x231282b)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/source/routers/common/middleware.go:37 (0x246d82f)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/source/modules/web/handler.go:155 (0x231282b)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/source/routers/common/middleware.go:99 (0x246cee9)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/source/modules/web/handler.go:155 (0x231282b)
/usr/local/go/src/net/http/server.go:2122 (0x9b63ce)
/go/pkg/mod/github.com/go-chi/chi/v5@v5.0.8/mux.go:90 (0x17dd40f)
/source/modules/web/route.go:166 (0x2313b0d)
/usr/local/go/src/net/http/server.go:2936 (0x9b99d5)
/usr/local/go/src/net/http/server.go:1995 (0x9b4ef1)
/usr/local/go/src/runtime/asm_amd64.s:1598 (0x475380)

LDAP sync seems to work otherwise, as new users get added successfully.

Gitea Version

1.20.2

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

Debian 11

How are you running Gitea?

Binary download launched via systemd Service.

Database

MySQL/MariaDB

Originally created by @everii-mapi on GitHub (Sep 7, 2023). ### Description As described in the title, upon changing the sshPublicKey Attribute within LDAP and running "Synchronize external user data", SSH key is not updated within Gitea. I also ran the task "Update the '.ssh/authorized_keys' file with Gitea SSH keys." Debug Log shows ``` 2023/09/07 09:46:09 ...s/asymkey/ssh_key.go:393:SynchronizePublicKeys() [T] synchronizePublicKeys[everii LDAP]: Handling Public SSH Key synchronization for user MYUSER 2023/09/07 09:46:09 ...s/asymkey/ssh_key.go:420:SynchronizePublicKeys() [T] synchronizePublicKeys[everii LDAP]: Public Keys are already in sync for MYUSER (Source:0/DB:0) ``` doctor check --all ``` [1] Check paths and basic configuration - [I] Configuration File Path: "/etc/gitea/app.ini" - [I] Repository Root Path: "/var/lib/gitea/data/gitea-repositories" - [I] Data Root Path: "/var/lib/gitea/data" - [I] Custom File Root Path: "/var/lib/gitea/custom" - [I] Work directory: "/var/lib/gitea" - [I] Log Root Path: "/var/lib/gitea/log" OK [2] Check Database Version - [I] Expected database version: 260 OK [3] Check if user with wrong type exist OK [4] Check if OpenSSH authorized_keys file is up-to-date OK [5] Synchronize repo HEADs - [I] All 450 repos have their HEADs in the correct state OK All done. ``` Also, the page /user/settings/keys throws an Error 500: ``` An error occurred: PANIC: runtime error: index out of range [0] with length 0 /usr/local/go/src/runtime/panic.go:884 (0x43d872) /source/modules/web/routing/logger_manager.go:116 (0x23104e4) /usr/local/go/src/runtime/panic.go:884 (0x43d872) /usr/local/go/src/runtime/panic.go:113 (0x43b75e) /source/models/asymkey/ssh_key.go:279 (0x131581c) /source/routers/web/user/setting/keys.go:272 (0x25431f8) /source/routers/web/user/setting/keys.go:32 (0x2540184) /usr/local/go/src/reflect/value.go:586 (0x4aae0a) /usr/local/go/src/reflect/value.go:370 (0x4aa0bb) /source/modules/web/handler.go:176 (0x2312565) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /source/modules/web/handler.go:186 (0x23125fb) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /source/modules/web/handler.go:186 (0x23125fb) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /go/pkg/mod/github.com/go-chi/chi/v5@v5.0.8/chain.go:31 (0x17dc7cb) /go/pkg/mod/github.com/go-chi/chi/v5@v5.0.8/mux.go:444 (0x17df6d5) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /source/modules/web/handler.go:186 (0x23125fb) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /source/modules/web/handler.go:186 (0x23125fb) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /source/modules/web/handler.go:186 (0x23125fb) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /go/pkg/mod/github.com/go-chi/chi/v5@v5.0.8/middleware/get_head.go:37 (0x24f5c0d) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /source/modules/web/handler.go:155 (0x231282b) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /source/modules/web/handler.go:186 (0x23125fb) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /source/modules/context/context.go:196 (0x1caaa6b) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /source/modules/web/handler.go:155 (0x231282b) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /go/pkg/mod/gitea.com/go-chi/session@v0.0.0-20230415140235-3182bcc14852/session.go:257 (0x184754a) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /source/modules/web/handler.go:155 (0x231282b) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /go/pkg/mod/github.com/go-chi/chi/v5@v5.0.8/mux.go:73 (0x17dd454) /go/pkg/mod/github.com/go-chi/chi/v5@v5.0.8/mux.go:316 (0x17dee63) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /go/pkg/mod/github.com/go-chi/chi/v5@v5.0.8/mux.go:444 (0x17df6d5) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /go/pkg/mod/github.com/go-chi/chi/v5@v5.0.8/mux.go:73 (0x17dd454) /go/pkg/mod/github.com/go-chi/chi/v5@v5.0.8/mux.go:316 (0x17dee63) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /go/pkg/mod/github.com/go-chi/chi/v5@v5.0.8/mux.go:444 (0x17df6d5) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /source/modules/web/routing/logger_manager.go:122 (0x2310313) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /source/modules/web/handler.go:155 (0x231282b) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /go/pkg/mod/github.com/chi-middleware/proxy@v1.1.1/middleware.go:37 (0x246ad16) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /source/modules/web/handler.go:155 (0x231282b) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /source/routers/common/middleware.go:45 (0x246dd14) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /source/modules/web/handler.go:155 (0x231282b) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /source/routers/common/middleware.go:37 (0x246d82f) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /source/modules/web/handler.go:155 (0x231282b) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /source/routers/common/middleware.go:99 (0x246cee9) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /source/modules/web/handler.go:155 (0x231282b) /usr/local/go/src/net/http/server.go:2122 (0x9b63ce) /go/pkg/mod/github.com/go-chi/chi/v5@v5.0.8/mux.go:90 (0x17dd40f) /source/modules/web/route.go:166 (0x2313b0d) /usr/local/go/src/net/http/server.go:2936 (0x9b99d5) /usr/local/go/src/net/http/server.go:1995 (0x9b4ef1) /usr/local/go/src/runtime/asm_amd64.s:1598 (0x475380) ``` LDAP sync seems to work otherwise, as new users get added successfully. ### Gitea Version 1.20.2 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System Debian 11 ### How are you running Gitea? Binary download launched via systemd Service. ### Database MySQL/MariaDB
GiteaMirror added the type/bug label 2025-11-02 09:42:23 -06:00
GiteaMirror commented 2025-11-02 09:42:24 -06:00
Author
Owner
Copy Link

@everii-mapi commented on GitHub (Sep 7, 2023):

Apparently this happens after changing the authentication source to a different LDAP server. After removing the old keys from public_key table, the 500 error disappears.

The keys still do not get synchronized from the new directory, claiming Public Keys are already in sync (with no keys in place for many users).

To prevent loss of authentication, I readded the public_key table from backup and the 500 immediately reappears.

@everii-mapi commented on GitHub (Sep 7, 2023): Apparently this happens after changing the authentication source to a different LDAP server. After removing the old keys from `public_key` table, the 500 error disappears. The keys still do not get synchronized from the new directory, claiming `Public Keys are already in sync` (with no keys in place for many users). To prevent loss of authentication, I readded the `public_key` table from backup and the 500 immediately reappears.
GiteaMirror commented 2025-11-02 09:42:24 -06:00
Author
Owner
Copy Link

@everii-mapi commented on GitHub (Sep 7, 2023):

After further investigation, this was a combination of problems.

  • The authentication source for the old LDAP server had been removed, resulting in invalid login_source_id entries within public_key
  • The new LDAP server had ACL in place that prevented reading the sshPublicKey Attribute, which was not obvious from Gitea logs showing "Public Keys are already in sync".

After correcting the ACL on the LDAP side and deleting the entries with wrong login_source_id from public_key, everything works again.

@everii-mapi commented on GitHub (Sep 7, 2023): After further investigation, this was a combination of problems. * The authentication source for the old LDAP server had been removed, resulting in invalid `login_source_id` entries within `public_key` * The new LDAP server had ACL in place that prevented reading the `sshPublicKey` Attribute, which was not obvious from Gitea logs showing "Public Keys are already in sync". After correcting the ACL on the LDAP side and deleting the entries with wrong `login_source_id` from `public_key`, everything works again.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
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
Mirrored from GitHub 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
No Label type/bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#11609
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?