Problem with passing SSH into a rootless container

[stefanfrede]

👋 I managed to set up Forgejo as a non-root user using Quadlet files:

$HOME/.config/containers/systemd/forgejo/
├── forgejo-config.volume
├── forgejo.container
├── forgejo-data.volume
├── forgejo.network
├── forgejo.pod
├── forgejo-postgres.container
└── forgejo-postgres.volume

As far as I can tell, it is working like a charm.

Except for instance commit signing:
https://forgejo.org/docs/next/admin/advanced/signing/.

I feel like I've tried everything to make it work.

The problem is that the user inside the container is not permitted to access SSH from the host, and I can't work out how to change this.

Or maybe what I think is passing SSH into the container is actually not passing anything at all.

Here is my attempt, where I feel I have come close to finding a solution.

// Inside forgejo.container

…
[Container]

User=1000:1000

Environment=USER_UID=1000
Environment=USER_GID=1000

Environment=SSH_AUTH_SOCK=/ssh-agent

Volume=${SSH_AUTH_SOCK}:/ssh-agent
…

With Exec=echo ${SSH_AUTH_SOCK} I get /run/user/1000/openssh_agent, which I assume is correct.

Inside the container it looks like this:

srw-------    1 root     root           0 Feb 15 19:53 ssh-agent

With echo $SSH_AUTH_SOCK inside the container I get /ssh-agent 🤯

That is where I keep going round in circles without getting any closer.

I would greatly appreciate any push that brings me closer 🙏

[ygalblum]

What O/S are you running on the host? Could this be an SELinux issue?
If you are running with SELinux, have you tried disabling it to see if it works without it (I'm not suggesting this is the way to go, but just for debugging)

[stefanfrede]

My O/S is Debian Trixie and I managed to get it working, but it's a bit of a hack.

I added this in my forgejo.pod:

[Container]
UserNS=keep-id:uid=1000,gid=1000

And I added this in my forgejo.container:

[Container]
Environment=SSH_AUTH_SOCK=/ssh-agent
Volume=${SSH_AUTH_SOCK}:/ssh-agent:Z

I encountered this problem when implementing these changes: https://stackoverflow.com/questions/79776833/pass-ssh-socket-to-podman-quadlet-unit.

After spending some time trying to find a solution, I gave up and opted for the symlink solution too.

In my .bash_profile:

ln -sf $SSH_AUTH_SOCK $HOME/.ssh-auth-sock

And in my forgejo.container:

Environment=SSH_AUTH_SOCK=/ssh-agent
Volume=${HOME}/.ssh-auth-sock:/ssh-agent:Z

I would love to get rid of the symlink, but for now it is doing what it is supposed to do.

[ygalblum]

First, if you needed to add :Z, this means that it was in fact an SELinux issue.

As for the symlink, since you know the value of the environment variable, I would try to use the value in the volume:

Volume=/run/user/1000/openssh_agent:/ssh-agent:Z

I wonder if this is related to some environment variable extrapolation. I saw that it seemed to work for the Exec, but still worth a shot. If this is the case, we'll try to understand what's going on. If not, then we'll look elsewhere

[stefanfrede]

Thank you very much for your reply 🙏

To be honest, I added the :Z because I had seen it used many times before.

It works without it, too.

With

Volume=/run/user/1000/openssh_agent:/ssh-agent:Z

I get the following error:

fatal: failed to write commit object
error: No private key found for public key "/var/lib/gitea/git/.ssh/id_ed25519.pub"?

I reverted back to the symlink and checked again with Exec=echo $SSH_AUTH_SOCK and the response is /run/user/1000/openssh_agent.

Using the symlink appears to produce the same result, but there is definitely something different.

[stefanfrede]

To make it less cryptic, here is a link to my Quadlet files: https://codeberg.org/stefanfrede/quadlets/src/branch/main/.config/containers/systemd/forgejo.