Why can't I access gitea with SSH using Kerberos

I have gitea running in a VM, and I use kerberos for SSH authentication within my network. As things stand:

I have my normal user on my daily driver (foo)
The gitea server has two relevant users: foo, and gitea. The latter is the user that runs the gitea process.

In order to ssh into the server, I get a TGT as the principal foo@LOCALDOMAIN, which allows me to ssh into the gitea server as foo. I also added a .k5login file to the gitea user's home directory that specifies foo@LOCALDOMAIN as a valid principal, meaning that I can also authenticate to the server as the gitea user using this principal.

I would therefore expect to be able to interact with a gitea repository whose upstream URL is: gitea@gitea.localdomain:foo/repo_name.git. Instead, before getting a TGT, the error is:

gitea@gitea.localdomain: Permission denied (publickey,gssapi-with-mic).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

And after getting the TGT, the error is:

fatal: 'foo/repo_name.git' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Solution

before getting a TGT, the error is:
gitea@gitea.localdomain: Permission denied (publickey,gssapi-with-mic).

That's normal, because you don't have a TGT (and a service ticket for host/gitea.localdomain) so you cannot authenticate via Kerberos.

And after getting the TGT, the error is:
fatal: 'foo/repo_name.git' does not appear to be a git repository

This happens because those repositories don't actually exist directly in the ~gitea/ home directory. Public-key auth serves an additional purpose here: the ~gitea/.ssh/authorized_keys file has a custom command for each key, which forces your remote 'git' commands through a wrapper script – which redirects the Git operations to another location, and is also how the server can distinguish different Gitea users when they all come in through the same SSH account (i.e. the wrapper script enforces per-repository permissions).

But this is all bypassed when you use GSSAPI authentication.

In order to use Kerberos here, you'd need a custom wrapper – defined via global sshd_config for the gitea user – which would look at $SSH_USER_AUTH and run the Gitea wrapper accordingly.

GSSAPIAuthentication yes
ExposeAuthInfo yes
[...]
Match user gitea
    ForceCommand /usr/local/bin/kerbgitea

...where the kerbgitea script has to read the file from $SSH_USER_AUTH, take the user principal from the 2nd field, and execute the same command that you find in the gitea user's authorized_keys file.

If you only have one Gitea user and one pubkey, you can simplify it to directly running the command. (Personally, with a single-user system, I don't use Gitea or anything like it; just direct repository access.)