Documentation for SSH is not correct for Alpine linux (fixes in the description) #8684

New Issue

GiteaMirror · 2025-11-02T08:14:25-06:00

GiteaMirror commented

2025-11-02 08:14:25 -06:00

Originally created by @williamdes on GitHub (Mar 12, 2022).

Gitea Version

1.16.x

Git Version

No response

Operating System

No response

How are you running Gitea?

Using docker compose

Database

MySQL

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Description

I have the following error message in my logs by sshd: fatal: reprocess config line 122: AuthorizedKeysCommand must be an absolute path

After applying https://docs.gitea.io/en-us/install-with-docker/#ssh-shell-with-authorizedkeyscommand

What was needed on my Alpine 3.14 was this diff:

- AuthorizedKeysCommand ssh -p 2222 -o StrictHostKeyChecking=no git@127.0.0.1 /usr/local/bin/gitea keys -c /data/gitea/conf/app.ini -e git -u %u -t %t -k %k
+ AuthorizedKeysCommand /usr/bin/ssh -p 2222 -o StrictHostKeyChecking=no git@127.0.0.1 /usr/local/bin/gitea keys -c /data/gitea/conf/app.ini -e git -u %u -t %t -k %k

And after the forwarding worked fine after another tweak

I had this error in my logs and git clone failed fetch commands ..s/setting/setting.go:952:loadFromConf() [F] Expect user 'git' but current user is: root
Solved by adding -u git in the step https://docs.gitea.io/en-us/install-with-docker/#docker-shell-with-authorizedkeyscommand
Please note on the step above the -u git is here, maybe this is also a mistake. See: https://docs.gitea.io/en-us/install-with-docker/#docker-shell-with-authorized_keys

Screenshots

No response

Originally created by @williamdes on GitHub (Mar 12, 2022). ### Gitea Version 1.16.x ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? Using docker compose ### Database MySQL ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Description I have the following error message in my logs by sshd: `fatal: reprocess config line 122: AuthorizedKeysCommand must be an absolute path` After applying https://docs.gitea.io/en-us/install-with-docker/#ssh-shell-with-authorizedkeyscommand What was needed on my Alpine 3.14 was this diff: ```diff - AuthorizedKeysCommand ssh -p 2222 -o StrictHostKeyChecking=no git@127.0.0.1 /usr/local/bin/gitea keys -c /data/gitea/conf/app.ini -e git -u %u -t %t -k %k + AuthorizedKeysCommand /usr/bin/ssh -p 2222 -o StrictHostKeyChecking=no git@127.0.0.1 /usr/local/bin/gitea keys -c /data/gitea/conf/app.ini -e git -u %u -t %t -k %k ``` And after the forwarding worked fine after another tweak I had this error in my logs and git clone failed fetch commands `..s/setting/setting.go:952:loadFromConf() [F] Expect user 'git' but current user is: root` Solved by adding `-u git` in the step https://docs.gitea.io/en-us/install-with-docker/#docker-shell-with-authorizedkeyscommand Please note on the step above the `-u git` is here, maybe this is also a mistake. See: https://docs.gitea.io/en-us/install-with-docker/#docker-shell-with-authorized_keys ### Screenshots _No response_

GiteaMirror closed this issue

2025-11-02 08:14:25 -06:00

GiteaMirror commented

2025-11-02 08:14:26 -06:00

@mscherer commented on GitHub (Mar 12, 2022):

Given openssh man pages, this doesn't seems to be a Alpine specific issue, so I fixed the 1st issue in the doc.

@mscherer commented on GitHub (Mar 12, 2022): Given openssh man pages, this doesn't seems to be a Alpine specific issue, so I fixed the 1st issue in the doc.

GiteaMirror commented

2025-11-02 08:14:26 -06:00

@williamdes commented on GitHub (Mar 13, 2022):

Given openssh man pages, this doesn't seems to be a Alpine specific issue, so I fixed the 1st issue in the doc.

Thank you so much !

What about the -u git one ?

@williamdes commented on GitHub (Mar 13, 2022): > Given openssh man pages, this doesn't seems to be a Alpine specific issue, so I fixed the 1st issue in the doc. Thank you so much ! What about the `-u git` one ?

GiteaMirror commented

2025-11-02 08:14:26 -06:00

@mscherer commented on GitHub (Mar 13, 2022):

For the 2nd part, I am not sure to really understand where the problem come from. Is the issue in the docker-shell wrapper, as there is already a -u on the AuthorizedKeysCommand.

If you could make a PR, it would be clearer to me

@mscherer commented on GitHub (Mar 13, 2022): For the 2nd part, I am not sure to really understand where the problem come from. Is the issue in the docker-shell wrapper, as there is already a -u on the AuthorizedKeysCommand. If you could make a PR, it would be clearer to me

GiteaMirror commented

2025-11-02 08:14:27 -06:00

@williamdes commented on GitHub (Mar 13, 2022):

For the 2nd part, I am not sure to really understand where the problem come from. Is the issue in the docker-shell wrapper, as there is already a -u on the AuthorizedKeysCommand.

If you could make a PR, it would be clearer to me

There is no -u git in the shell wrapper of https://docs.gitea.io/en-us/install-with-docker/#docker-shell-with-authorizedkeyscommand
But there is one in the wrapper of https://docs.gitea.io/en-us/install-with-docker/#docker-shell-with-authorized_keys

Does it make more sense ?

@williamdes commented on GitHub (Mar 13, 2022): > For the 2nd part, I am not sure to really understand where the problem come from. Is the issue in the docker-shell wrapper, as there is already a -u on the AuthorizedKeysCommand. > > If you could make a PR, it would be clearer to me There is no `-u git` in the shell wrapper of https://docs.gitea.io/en-us/install-with-docker/#docker-shell-with-authorizedkeyscommand But there is one in the wrapper of https://docs.gitea.io/en-us/install-with-docker/#docker-shell-with-authorized_keys ![image](https://user-images.githubusercontent.com/7784660/158062110-db453edf-fa95-4574-ad37-0ec3c21d210c.png) ![image](https://user-images.githubusercontent.com/7784660/158062126-b52982ac-c5e4-4afb-ac23-5d024b5fe970.png) Does it make more sense ?

GiteaMirror commented

2025-11-02 08:14:27 -06:00

@mscherer commented on GitHub (Mar 13, 2022):

Seems the bug was closed by error (or rather closed automatically), I can't reopen myself it seems.

And yes, the wrapper is not the same but I wonder if it should be fixed on the Dockerfile side to force the container to run as the user git, as it would make the doc simpler.

@mscherer commented on GitHub (Mar 13, 2022): Seems the bug was closed by error (or rather closed automatically), I can't reopen myself it seems. And yes, the wrapper is not the same but I wonder if it should be fixed on the Dockerfile side to force the container to run as the user git, as it would make the doc simpler.

GiteaMirror commented

2025-11-02 08:14:27 -06:00

@williamdes commented on GitHub (Mar 14, 2022):

Seems the bug was closed by error (or rather closed automatically), I can't reopen myself it seems.

And yes, the wrapper is not the same but I wonder if it should be fixed on the Dockerfile side to force the container to run as the user git, as it would make the doc simpler.

Well I tried running the container as git user and that was not the right fix for this issue, I lost quite a lot of time trying this solution.
Finally the -u git worked like a charm and did not destroy my setup
Would you mind making a PR for that ? (I could make one too but I am not setup for gitea dev)

@williamdes commented on GitHub (Mar 14, 2022): > Seems the bug was closed by error (or rather closed automatically), I can't reopen myself it seems. > > And yes, the wrapper is not the same but I wonder if it should be fixed on the Dockerfile side to force the container to run as the user git, as it would make the doc simpler. Well I tried running the container as git user and that was not the right fix for this issue, I lost quite a lot of time trying this solution. Finally the `-u git` worked like a charm and did not destroy my setup Would you mind making a PR for that ? (I could make one too but I am not setup for gitea dev)

GiteaMirror commented

2025-11-02 08:14:28 -06:00

@mscherer commented on GitHub (Mar 14, 2022):

yes, but the docker container should already run as the git user (or I think it should). Forcing the git user on the Docker exec seems like a workaround for something that shouldn't be needed, as adding USER should make it work out of the box.

@mscherer commented on GitHub (Mar 14, 2022): yes, but the docker container should already run as the git user (or I think it should). Forcing the git user on the Docker exec seems like a workaround for something that shouldn't be needed, as adding USER should make it work out of the box.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#8684