Separate SSH and app users #4517

New Issue

GiteaMirror · 2025-11-02T05:53:17-06:00

GiteaMirror commented

2025-11-02 05:53:17 -06:00

Originally created by @clarfonthey on GitHub (Dec 19, 2019).

Right now, if you don't use the built-in SSH server, there's no way to specify a custom SSH username to use for git access, as it just uses the currently running user. It'd be nice if we could have this functionality somehow.

At minimum, I think we should have a configuration option for a custom SSH user which is different from both BUILTIN_SSH_SERVER_USER and RUN_USER, and maybe some option to configure a group (in addition to user) that both the Gitea user and the SSH server user are under.

Here's my idea how this configuration would be used:

Your system would have to be set up with a gitea app user, a gitea SSH user (potentially the same as the app user), and a gitea group which contains both users.

Then, gitea serv is somewhat replaced by a custom command, giteasu (name pending). This should be owned by the gitea app user and the gitea group, only be executable by the gitea group, and have the setuid bit set. As a safeguard, giteasu should check if the running user is in the gitea group and immediately exit if this is not the case.

If AuthorizedKeysCommand isn't used, the authorized_keys file would be written to the SSH user's home directory instead of the app user's home directory.

Basically, on most systems, you'd have a gitea user run the app and the git user be used for SSH, with both being members of the gitea group.

Originally created by @clarfonthey on GitHub (Dec 19, 2019). Right now, if you don't use the built-in SSH server, there's no way to specify a custom SSH username to use for git access, as it just uses the currently running user. It'd be nice if we could have this functionality somehow. At minimum, I think we should have a configuration option for a custom SSH user which is different from both `BUILTIN_SSH_SERVER_USER` and `RUN_USER`, and maybe some option to configure a group (in addition to user) that both the Gitea user and the SSH server user are under. Here's my idea how this configuration would be used: Your system would have to be set up with a gitea app user, a gitea SSH user (potentially the same as the app user), and a gitea group which contains both users. Then, `gitea serv` is somewhat replaced by a custom command, `giteasu` (name pending). This should be owned by the gitea app user and the gitea group, only be executable by the gitea group, and have the setuid bit set. As a safeguard, `giteasu` should check if the running user is in the gitea group and immediately exit if this is not the case. If `AuthorizedKeysCommand` isn't used, the `authorized_keys` file would be written to the SSH user's home directory instead of the app user's home directory. Basically, on most systems, you'd have a `gitea` user run the app and the `git` user be used for SSH, with both being members of the `gitea` group.

GiteaMirror added the type/question issue/stale labels 2025-11-02 05:53:17 -06:00

GiteaMirror closed this issue

2025-11-02 05:53:17 -06:00

GiteaMirror commented

2025-11-02 05:53:18 -06:00

@sapk commented on GitHub (Dec 19, 2019):

Hi, I am not sure to understand what is your use-case but the scenario you describe are achievable with gitea and openssh currently. If you plan to use it in such a specific config I can only send your to openssh configuration docs and gitea docs and try to understand how it works under the hood.

For example such cases are also supported by advanced openssh/gitea combo config like http://man.openbsd.org/sshd_config#AuthorizedKeysCommand with https://docs.gitea.io/en-us/command-line/#keys

@sapk commented on GitHub (Dec 19, 2019): Hi, I am not sure to understand what is your use-case but the scenario you describe are achievable with gitea and openssh currently. If you plan to use it in such a specific config I can only send your to openssh configuration docs and gitea docs and try to understand how it works under the hood. For example such cases are also supported by advanced openssh/gitea combo config like http://man.openbsd.org/sshd_config#AuthorizedKeysCommand with https://docs.gitea.io/en-us/command-line/#keys

GiteaMirror commented

2025-11-02 05:53:18 -06:00

@clarfonthey commented on GitHub (Dec 30, 2019):

Okay, so, my original post was really terribly worded but essentially, this is not allowed with current gitea and this is essentially a request to make it possible somehow. I'll try and reword the post to make that clearer.

@clarfonthey commented on GitHub (Dec 30, 2019): Okay, so, my original post was really terribly worded but essentially, this is *not* allowed with current gitea and this is essentially a request to make it possible somehow. I'll try and reword the post to make that clearer.

GiteaMirror commented

2025-11-02 05:53:18 -06:00

@stale[bot] commented on GitHub (Feb 28, 2020):

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

@stale[bot] commented on GitHub (Feb 28, 2020): This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

GiteaMirror commented

2025-11-02 05:53:18 -06:00

@stale[bot] commented on GitHub (Mar 13, 2020):

This issue has been automatically closed because of inactivity. You can re-open it if needed.

@stale[bot] commented on GitHub (Mar 13, 2020): This issue has been automatically closed because of inactivity. You can re-open it if needed.

GiteaMirror referenced this issue

2025-11-02 13:12:07 -06:00

[PR #4517] [MERGED] Fix doc typo #17407

Sign in to join this conversation.