git-shell won't work with ssh container passthrough #11224

Closed
opened 2025-11-02 09:31:17 -06:00 by GiteaMirror · 7 comments
Owner

Originally created by @scruel on GitHub (Jul 13, 2023).

Description

Currently, I can have the ssh docker passthrough works fine just by following the instructions on the official document page, however, the ssh key which set for docker container inner ssh, will also be available for the host, consider we just copied/pasted or mounted .ssh/authorized_keys, the host and the contaniner will have the same file for identifiying users, which will cause user can just use the same private key login to the host and the docker container.
git-shell is built for preventing this problem, however for passthrough usage, it won't work anymore, I will always get the following error if I want to auth the user to use gitea:

fatal: unrecognized command '/usr/local/bin/gitea --config=/data/gitea/conf/app.ini serv key-4'

Gitea Version

1.20.0+rc0 built with GNU Make 4.4.1, go1.20.5 : bindata, timetzdata, sqlite, sqlite_unlock_notify

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

2.41.0, Wire Protocol Version 2 Enabled

Operating System

No response

How are you running Gitea?

With docker

Database

None

Originally created by @scruel on GitHub (Jul 13, 2023). ### Description Currently, I can have the ssh docker passthrough works fine just by following the instructions on the official document page, however, the ssh key which set for docker container inner ssh, will also be available for the host, consider we just copied/pasted or mounted `.ssh/authorized_keys`, the host and the contaniner will have the same file for identifiying users, which will cause user can just use the same private key login to the host and the docker container. `git-shell` is built for preventing this problem, however for passthrough usage, it won't work anymore, I will always get the following error if I want to auth the user to use gitea: ``` fatal: unrecognized command '/usr/local/bin/gitea --config=/data/gitea/conf/app.ini serv key-4' ``` ### Gitea Version 1.20.0+rc0 built with GNU Make 4.4.1, go1.20.5 : bindata, timetzdata, sqlite, sqlite_unlock_notify ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version 2.41.0, Wire Protocol Version 2 Enabled ### Operating System _No response_ ### How are you running Gitea? With docker ### Database None
GiteaMirror added the type/bug label 2025-11-02 09:31:17 -06:00
Author
Owner

@techknowlogick commented on GitHub (Jul 13, 2023):

You'll note that in the authorized key file there is a "command" listed to each of the keys. This means that users can't run arbitrary commands with their key. Please re-open if that command isn't there for any key, or Gitea is inserting keys into that file without command.

@techknowlogick commented on GitHub (Jul 13, 2023): You'll note that in the authorized key file there is a "command" listed to each of the keys. This means that users can't run arbitrary commands with their key. Please re-open if that command isn't there for any key, or Gitea is inserting keys into that file without command.
Author
Owner

@scruel commented on GitHub (Jul 13, 2023):

@techknowlogick
Check your own doc and read my issue carefully before you choose to close it...
https://docs.gitea.com/next/installation/install-with-docker#ssh-container-passthrough

/home/git/.ssh/authorized_keys should then look somewhat like

# SSH pubkey from git user
ssh-rsa <Gitea Host Key>

# other keys from users
command="/usr/local/bin/gitea --config=/data/gitea/conf/app.ini serv key-1",no-port-forwarding,no-X11-> forwarding,no-agent-forwarding,no-pty <user pubkey>
@scruel commented on GitHub (Jul 13, 2023): @techknowlogick Check your own doc and read my issue carefully before you choose to close it... https://docs.gitea.com/next/installation/install-with-docker#ssh-container-passthrough > /home/git/.ssh/authorized_keys should then look somewhat like > ``` > # SSH pubkey from git user > ssh-rsa <Gitea Host Key> > > # other keys from users > command="/usr/local/bin/gitea --config=/data/gitea/conf/app.ini serv key-1",no-port-forwarding,no-X11-> forwarding,no-agent-forwarding,no-pty <user pubkey> > ```
Author
Owner

@techknowlogick commented on GitHub (Jul 13, 2023):

Yes, the internal key could be used for ssh purposes. But hopefully you aren't sharing that outside the connection between the host and container. Gitea needs the "Serv" command to be run so it can determine permissions and what not. Keys uploaded by users can't be used to run arbitrary commands. Unfortunately due to how git-she'll works it is incompatible with Gitea.

@techknowlogick commented on GitHub (Jul 13, 2023): Yes, the internal key could be used for ssh purposes. But hopefully you aren't sharing that outside the connection between the host and container. Gitea needs the "Serv" command to be run so it can determine permissions and what not. Keys uploaded by users can't be used to run arbitrary commands. Unfortunately due to how git-she'll works it is incompatible with Gitea.
Author
Owner

@scruel commented on GitHub (Jul 13, 2023):

Yes, the internal key could be used for ssh purposes. But hopefully you aren't sharing that outside the connection between the host and container. Gitea needs the "Serv" command to be run so it can determine permissions and what not. Keys uploaded by users can't be used to run arbitrary commands. Unfortunately due to how git-she'll works it is incompatible with Gitea.

Then you still won't reopen this issue?

@scruel commented on GitHub (Jul 13, 2023): > Yes, the internal key could be used for ssh purposes. But hopefully you aren't sharing that outside the connection between the host and container. Gitea needs the "Serv" command to be run so it can determine permissions and what not. Keys uploaded by users can't be used to run arbitrary commands. Unfortunately due to how git-she'll works it is incompatible with Gitea. Then you still won't reopen this issue?
Author
Owner

@techknowlogick commented on GitHub (Jul 13, 2023):

I'm still unclear on what the bug is as 1. Gitea itself can't function using git-shell due to the serv subcommand that is used for ssh connections, and 2. that special key should only be used for the connection between the host and the container, so other than that key leaking no one can use it, and it would only leak if they already have access to the key itself through other means.

@techknowlogick commented on GitHub (Jul 13, 2023): I'm still unclear on what the bug is as 1. Gitea itself can't function using git-shell due to the serv subcommand that is used for ssh connections, and 2. that special key should only be used for the connection between the host and the container, so other than that key leaking no one can use it, and it would only leak if they already have access to the key itself through other means.
Author
Owner

@scruel commented on GitHub (Jul 14, 2023):

You are unclear, then you just closed it, did you ever try to read my issue's description carefully? Or try to find some solutions for me to solve this issue?
You admit it's a problem which "Gitea can't function using git-shell", then you still won't reopen it???
I really hate what you have done: close my issue without right reason. You suck.

@scruel commented on GitHub (Jul 14, 2023): You are unclear, then you just closed it, did you ever try to read my issue's description carefully? Or try to find some solutions for me to solve this issue? You admit it's a problem which "Gitea can't function using git-shell", then you still won't reopen it??? I really hate what you have done: close my issue without right reason. You suck.
Author
Owner

@techknowlogick commented on GitHub (Jul 14, 2023):

I did read your issue, and I'm struggling to see what the bug is because everything you are reporting is behaving as expected.

You suck.

Please go and self-reflect on your behaviour and how it is not appropriate to attack others in such a way.

@techknowlogick commented on GitHub (Jul 14, 2023): I did read your issue, and I'm struggling to see what the bug is because everything you are reporting is behaving as expected. > You suck. Please go and self-reflect on your behaviour and how it is not appropriate to attack others in such a way.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#11224