Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SSH_USER can never be different from RUN_USER #28563

Closed
LunarLambda opened this issue Dec 20, 2023 · 10 comments
Closed

SSH_USER can never be different from RUN_USER #28563

LunarLambda opened this issue Dec 20, 2023 · 10 comments
Labels
issue/needs-feedback For bugs, we need more details. For features, the feature must be described in more detail issue/workaround it is or has a workaround

Comments

@LunarLambda
Copy link

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
Copy link
Contributor

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.

@wxiaoguang wxiaoguang added issue/not-a-bug The reported issue is the intended behavior or the problem is not inside Gitea and removed type/bug labels Dec 21, 2023
@LunarLambda
Copy link
Author

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
Copy link
Contributor

wxiaoguang commented Dec 21, 2023

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 wxiaoguang added issue/needs-feedback For bugs, we need more details. For features, the feature must be described in more detail and removed issue/not-a-bug The reported issue is the intended behavior or the problem is not inside Gitea labels Dec 21, 2023
@wxiaoguang
Copy link
Contributor

wxiaoguang commented Dec 21, 2023

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
Copy link
Author

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
Copy link
Contributor

wxiaoguang commented Dec 21, 2023

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
Copy link
Author

LunarLambda commented Dec 21, 2023

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
Copy link
Contributor

wxiaoguang commented Dec 21, 2023

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
Copy link
Author

yes. fine by me. thank you clarifying.

@LunarLambda
Copy link
Author

For future reference: You can hack around it with sudo:

Say gitea is installed with RUN_USER gitea, and we want to allow git:

sudoers:

Defaults env_keep += "SSH_ORIGINAL_COMMAND GIT_PROTOCOL"
git, gitea ALL=(gitea) NOPASSWD: /usr/bin/gitea

sshd_config:

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

Gitea app.ini:

SSH_AUTHORIZED_KEYS_COMMAND_TEMPLATE = /usr/bin/sudo -u gitea {{.AppPath}} --config={{.CustomConf}} serv key-{{.Key.ID}}

Make sure the git user does not use a restricted shell (default: git-shell on Arch, change to sh or bash)

With this, it is possible to authenticate to Gitea with an arbitrary SSH user.

@lunny lunny added the issue/workaround it is or has a workaround label Dec 21, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 5, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
issue/needs-feedback For bugs, we need more details. For features, the feature must be described in more detail issue/workaround it is or has a workaround
Projects
None yet
Development

No branches or pull requests

3 participants