I’m trying to setup Gitea as Nixos Module which has runnig as docker container until now.
Hower since users.users.<name>.openssh.authorizedKeys.keyFiles requires the file to be in store it can’t be used for gitea.
The second best option i’ve been trying to use is services.openssh.authorizedKeysCommand without much sucess. The following appears in my ssh log when trying to clone via ssh:
Dec 10 17:02:08 ks3 sshd[60777]: AuthorizedKeysCommand /run/wrappers/bin/gitea-keys git failed, status 127
Dec 10 17:02:08 ks3 sshd[60777]: AuthorizedKeysCommand /run/wrappers/bin/gitea-keys git failed, status 127
Dec 10 17:02:08 ks3 sshd[60777]: error: PAM: Authentication failure for git from xxxx.22.45
Dec 10 17:02:08 ks3 sshd[60777]: Connection closed by authenticating user git xxx.22.45 port 59400 [preauth]
I was actually quite surprised that the gitea module didn’t include the necessary functionality to setup ssh, leading me to belive that an solution might not be so trival.
You even ask gitea to use the system ssh, so even though you get gitea to kind-of-but-not launch its own ssh process it ends up being unused:
And this is outright false:
Those keys are not used for git authentication in general, gitea instead will use whichever keys you configure it to use for your user in its UI. I think setting that setting for the gitea user might break that functionality.
If you wanted to reuse those keys, you could probably set something up with ExecStartPre to copy over the keys so gitea knows about them as well, but I wouldn’t recommend doing so without fully understanding gitea’s user management.
You’re overthinking the configuration. It should all work out of the box, if it does not, perhaps double check you don’t have some leftover state from your previous docker configuration.
Just delete anything regarding the gitea and git users, delete their accounts, wipe their home directories (to make sure you don’t have leftover state from your experimentation), remove all the ssh, auth and git related settings for services.gitea, delete the gitea configuration file for good measure if it’s not a symlink and redeploy. It should work, at least it does for me.
Note: Make sure to back up data from those users before you mess with them too much. Or try out nixos-rebuild build-vm to test it in a safe environment.
Yep, the NixOS gitea module does that by default. Your settings configure an ssh server which is not the host ssh server that gitea uses by default, and then you ask it not to launch it.
The git user of the NixOS module defaults to gitea rather than git, because that way you don’t have to maintain a second user and handle permissions between them, by the way.
You can refer to files not in /nix/store, but you have to put them in place using systemd units, and the module you’re using has to support accessing file paths at runtime rather than evaluation time (i.e., not use builtins.readFile). I’d recommend against trying this for now, let’s just get your service running
I think my configuration might have confused you further, my system ssh runs on port 2222. I can access both gitea and my general ssh server from port 2222, with one single sshd process.
What I’m trying to say is that your configuration sets up a separate process, but fails to launch it. Just remove all of your ssh-related configuration, and gitea will function as you want, reusing the system ssh.