<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=376766) </details> <!--IssueSummary end--> ## What is the GitLab engineering productivity problem to solve? GitLab Shell usually [logs `gl_project_path`](https://gitlab.com/gitlab-org/gitlab-shell/-/blame/v13.15.1/internal/handler/exec.go#L87-92). However, in case of `Internal API unreachable` events for requests to `api/v4/internal/authorized_keys` that field is not logged (and nothing else, which a customer could easily provide). See [these examples in our GitLab.com logs](https://log.gprd.gitlab.net/goto/709f09f0-454e-11ed-b0ec-930003e0679c): No ID-able information, except for the `key` parameter. Using the first part of the key, up to the first `+` for example seems to be helpful for finding specific events, though. Supporting customers who report such problems or `Permission denied (publickey)` errors would get easier, if Gitaly/GitLab-Shell logs contained more details about those requests. ### Problem identification checklist - [x] The root cause of the problem is identified. - [x] The surface of the problem is as small as possible. ## What are the potential solutions? - Add [relevant fields](https://gitlab.com/gitlab-org/gitlab/-/blob/v15.4.2-ee/doc/administration/logs/index.md#gitlab-shelllog) to the `Internal API unreachable` event log - And/or add details to [the `connection: initServerConn: failed to initialize SSH connection` error](https://gitlab.com/gitlab-org/gitlab-shell/-/blob/v14.12.0/internal/sshd/connection.go#L71-79) - [ ] All potential solutions are listed. - [ ] A solution has been chosen for the first iteration: `PUT THE CHOSEN SOLUTION HERE` ## Verify that the solution has improved the situation <!-- Ideally, looking at the charts from the first part, we should see an improvement after the implementation is merged/deployed/released. --> - [ ] The solution improved the situation. - If yes, check this box and close the issue. Well done! :tada: - Otherwise, create a new "Productivity Improvement" issue. You can re-use the description from this issue, but another solution should be chosen this time.