SSH_USER can never be different from RUN_USER

[LunarLambda]

Description

My gitea instance runs as user gitea, as configured by the official Arch Linux package. The gitea docs mention the following:

BUILTIN_SSH_SERVER_USER: %(RUN_USER)s: Username to use for the built-in SSH Server.

SSH_USER: %(BUILTIN_SSH_SERVER_USER)s: SSH username displayed in clone URLs. This is only for people who configure the SSH server themselves; in most cases, you want to leave this blank and modify the BUILTIN_SSH_SERVER_USER.

I am using OpenSSH, and I would like my ssh user to be git.

In sshd_config, I have:

Match User git
        AuthorizedKeysCommandUser gitea
        AuthorizedKeysCommand /usr/bin/gitea keys -e git -u %u -t %t -k %k

This is adapted from the docs.

This works, and produces the correct output when trying to authenticate as git via ssh.

This gets me as far as the following, when testing with git clone:

fatal: unrecognized command '/usr/bin/gitea --config=/etc/gitea/app.ini serv key-7'
fatal: Could not read from remote repository.

Testing the resulting command with sudo -u git /usr/bin/gitea --config=/etc/gitea/app.ini serv key-7 fails.

1. Because /etc/gitea/app.ini is not readable by git
2. Because gitea complains that git is not the RUN_USER (gitea)

I believe this means it is currently impossible to have an SSH user that is different from the Gitea RUN_USER, despite the documentation suggesting that it should be possible if one sets up SSH appropriately. I could not find any other way to "alias" git to gitea in SSH's configuration (tried AuthorizedKeysFile, etc.)

Related issues: #9426, #20568

Gitea Version

1.21.2

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

2.43.0

Operating System

Arch Linux

How are you running Gitea?

Official package

Database

SQLite

[wxiaoguang]

The only choice is use "builtin SSH server" but not use the "OpenSSH server"

The document has mentioned that:

BUILTIN_SSH_SERVER_USER: %(RUN_USER)s: Username to use for the built-in SSH Server.

[LunarLambda]

That makes no sense, the documentation literally says that SSH_USER is "only for people who configure the SSH server themselves", which I take to mean using OpenSSH.

You're saying it's only for use with the built-in server, why have the option at all then? In that case it always has to be equivalent to BUILTIN_SSH_USER, anything else would not work.

The option is completely unusable in either scenario. How is that not a bug?

[wxiaoguang]

That makes no sense, the documentation literally says that SSH_USER is "only for people who configure the SSH server themselves", which I take to mean using OpenSSH.

You're saying it's only for use with the built-in server, why have the option at all then? In that case it always has to be equivalent to BUILTIN_SSH_USER, anything else would not work.

I think the document is pretty clear:

- `SSH_USER`: **%(BUILTIN_SSH_SERVER_USER)s**: SSH username displayed in clone URLs.
    This is only for people who configure the SSH server themselves;
     in most cases, you want to leave this blank and modify the `BUILTIN_SSH_SERVER_USER`.

1. It is ONLY for the SSH username displayed in clone URLs, it affects nothing else.
2. "This is only for people who configure the SSH server themselves;" In this document, the SSH Server always means "Builtin SSH Server", eg: the - `START_SSH_SERVER`: **false**: When enabled, use the built-in SSH server. above, the "SSH_SERVER" just means the builtin SSH server, but it doesn't mean OpenSSH server.
3. Some users would like to play the "SSH passthrough trick" or something else, for these advanced users they might need it

The option is completely unusable in either scenario. How is that not a bug?

Gitea could provide 2 access approaches:

1. The OpenSSH Server: by the OS, Gitea itself should respect the OpenSSH user
2. The (builtin) SSH Server

If you believe there is something wrong, feeel free to propose a fix for it.

[wxiaoguang]

Outdated (not related).

Hmm, maybe I misunderstood something.

I think the root problem of your issue is fatal: unrecognized command '/usr/bin/gitea --config=/etc/gitea/app.ini serv key-7'

Because /etc/gitea/app.ini is not readable by git It doesn't seem right IMO. Maybe there is something wrong in the document. Could you try to make it readable?

[LunarLambda]

Well, after making it readable by user git, the error becomes that gitea is not being run as the correct user.

Since, to authenticate via SSH, user git needs to be able to run gitea serv, but Gitea only allows to be run as the gitea user (RUN_USER).

So it is not possible to change the OpenSSH user

[wxiaoguang]

OK, I checked some more details, I think the root problem is: the OpenSSH server should run Gitea as a subcommand and share the same data as Gitea web app.

The official document also says: just add a new "git" user: https://docs.gitea.com/installation/install-from-binary

So, from my understanding, maybe my comment above should still be right for this case: Just use the same user, there is no other way from my knowledge. (I have no more thought about this problem)

[LunarLambda]

I installed Gitea via Arch Linux's official package, which automatically creates a gitea user. It would be challenging to reconfigure everything to use a different user (and it would require disabling systemd-tmpfiles configuration)

However, I understand that this is not supported and will find a different solution.

It seems I may be able to override the tmpfiles.d configuration, then chown everything to git and set RUN_USER to git.

[wxiaoguang]

Then you need to always use gitea user, but never git user if the official uses gitea.

And "It seems I may be able to override the tmpfiles.d configuration, then chown everything to git and set RUN_USER to git." seems a good approach if it doesn't break anything.

---

Update: maybe the Arch Linux's official package document should be updated, to clarify this problem.

So I think this issue can be closed?

[LunarLambda]

yes. fine by me. thank you clarifying.