gitea: AuthorizedKeysCommand failed, status 1 with rootless container

Description

I followed the rootless docker install method described here mostly: https://docs.gitea.io/en-us/install-with-docker-rootless/ Deviations:

  • using single docker run inside a systemd unit file instead of docker compose
  • database is located on the host so 172.yada instead
  • my git user is UID/GID 998, it’s a carry over from my old gogs installation im migrating from (note im not doing any of the migration guides, starting fresh except for the host system user)

I’m currently stuck trying to get the git user’s ssh passthrough authentication working so that the host’s sshd can be the only ssh server. https://docs.gitea.io/en-us/install-with-docker-rootless/#ssh-container-passthrough

When I have the sshd_config set as described in the documentation, I see in journalctl for ssh an error executing the command:

Jun 15 07:58:11 HOSTNAME-REDACTED sshd[10553]: AuthorizedKeysCommand /usr/bin/docker exec -i gitea /usr/local/bin/gitea keys -e git -u git -t ssh-rsa -k AAAAPUBLICKEY-REDACTED failed, status 1
Jun 15 07:58:11 HOSTNAME-REDACTED sshd[10553]: Connection closed by authenticating user git 192.168.1.1 port 58756 [preauth]

So I start debugging:

  • Copy and pasted the command and am able to run it manually and successfully as both my personal user and as sudo su git, so gitea itself is working, awesome
  • Trying some other commands to see which executable in the command chain SSH doesn’t like:
    • AuthorizedKeysCommand /usr/bin/docker exec -i gitea /bin/bash -c "echo hai" failed, status 1
    • /usr/bin/docker --help didn’t produce an error in the log, so it seems to have at least been able to execute and get output
    • made sure user git is in the docker group
    • checked permissions on /usr/bin/docker and it looks good and based on docker --help not reporting status 1 in ssh logs i think the host docker executable is fine probably

Gitea Version

1.16.8-rootless

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

docker rootless on a debian buster (10)

How are you running Gitea?

here’s my unit file and all it’s dirty hacks

[Unit]
Description=Gitea Server Docker Container
After=docker.service
Requires=docker.service

[Service]
User=git
Group=git
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill gitea
ExecStartPre=-/usr/bin/docker rm gitea
#ExecStartPre=/usr/bin/docker pull gitea/gitea:1.16.8-rootless
ExecStart=/usr/bin/docker run --name gitea \
    --user 998 \
    -e "USER_UID=998" \
    -e "USER_GID=998" \
    -e "GITEA__database__DB_TYPE=postgres" \
    -e "GITEA__database__HOST=172.17.0.1:5432" \
    -e "GITEA__database__NAME=giteadb" \
    -e "GITEA__database__USER=REDACTED" \
    -e "GITEA__database__PASSWD=REDACTED" \
    -v "/tank/git/gitea/data:/var/lib/gitea" \
    -v "/tank/git/gitea/conf:/etc/gitea" \
    -v "/etc/timezone:/etc/timezone:ro" \
    -v "/etc/localtime:/etc/localtime:ro" \
    -p 3002:3000 \
    gitea/gitea:1.16.8-rootless
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Database

PostgreSQL

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 17 (7 by maintainers)

Most upvoted comments

I may have found the problem… I am running Debian 11 Bullseye. It uses OpenSSH_8.4p1. Quoting OpenSSH release notes:

Security

sshd(8) from OpenSSH 6.2 through 8.7 failed to correctly initialise supplemental groups when executing an AuthorizedKeysCommand or AuthorizedPrincipalsCommand, where a AuthorizedKeysCommandUser or AuthorizedPrincipalsCommandUser directive has been set to run the command as a different user. Instead these commands would inherit the groups that sshd(8) was started with.

Thus, the git user cannot inherit the docker group, thus can’t run docker. I have tried to use sudo, but it is cumbersome and ultimately failed. I have set the AuthorizedKeysCommandUser to root, and it works. You may also add root to the docker group, but any AuthorizedKeysCommandUser would gain the permission to run docker.

Not a Gitea bug, nor a docker related one. OpenSSH in Debian is just too old I guess 😕

Oh man I love me a debian bug, good eye! I agree with your assessment that this isn’t a gitea bug and given how niche the issue is and the fact that it’s fixed in newer releases, this doesn’t even warrant a callout in the documentation in my opinion. I appreciate you coming back and solving this mystery!

I may have found the problem… I am running Debian 11 Bullseye. It uses OpenSSH_8.4p1. Quoting OpenSSH release notes:

Security

sshd(8) from OpenSSH 6.2 through 8.7 failed to correctly initialise supplemental groups when executing an AuthorizedKeysCommand or AuthorizedPrincipalsCommand, where a AuthorizedKeysCommandUser or AuthorizedPrincipalsCommandUser directive has been set to run the command as a different user. Instead these commands would inherit the groups that sshd(8) was started with.

Thus, the git user cannot inherit the docker group, thus can’t run docker. I have tried to use sudo, but it is cumbersome and ultimately failed. I have set the AuthorizedKeysCommandUser to root, and it works. You may also add root to the docker group, but any AuthorizedKeysCommandUser would gain the permission to run docker.

Not a Gitea bug, nor a docker related one. OpenSSH in Debian is just too old I guess 😕