-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Comments
The only choice is use "builtin SSH server" but not use the "OpenSSH server" The document has mentioned that:
|
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? |
I think the document is pretty clear:
Gitea could provide 2 access approaches:
If you believe there is something wrong, feeel free to propose a fix for it. |
Outdated (not related). Hmm, maybe I misunderstood something. I think the root problem of your issue is
|
Well, after making it readable by user Since, to authenticate via SSH, user So it is not possible to change the OpenSSH user |
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) |
I installed Gitea via Arch Linux's official package, which automatically creates a However, I understand that this is not supported and will find a different solution. It seems I may be able to override the |
Then you need to always use 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? |
yes. fine by me. thank you clarifying. |
For future reference: You can hack around it with sudo: Say gitea is installed with RUN_USER sudoers:
sshd_config:
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: With this, it is possible to authenticate to Gitea with an arbitrary SSH user. |
Description
My gitea instance runs as user
gitea
, as configured by the official Arch Linux package. The gitea docs mention the following:I am using OpenSSH, and I would like my ssh user to be
git
.In
sshd_config
, I have: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
:Testing the resulting command with
sudo -u git /usr/bin/gitea --config=/etc/gitea/app.ini serv key-7
fails.git
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
togitea
in SSH's configuration (triedAuthorizedKeysFile
, 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
The text was updated successfully, but these errors were encountered: