I have gitea running in a VM, and I use kerberos for SSH authentication within my network. As things stand:
foo
)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.
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.)