use per GSSAPIClientIdentity kerberos credential cache

[calestyo]

Hey.

It would be nice if the patch would provide some way to let it use a (private) kerberos credential cache.

My usage scenario is about the following:

• I have accounts in multiple kerberos realms
• SSH to nodes from multiple of them at the same time
• I use a keytab file to automatically obtain a ticket

The patch is already so smart, so that it automatically requests a ticket using the keytab file when I connect to a host, for which GSSAPI authentication is configured.

So I can log in fully automated (without any need to enter a passphrase, if my keytab file contains it) and get a ticket (including for AFS).

That ticket is however stored in the "main" ticket cache (i.e. the one I'd also see by a plain klist).

If a ticket exists already, say for realm A, no new ticket would be created when I try to login to a host using realm B.

Therefore, login (via GSSAPI) would fail to nodes that don't use realm A.

Not sure what would be the best solution to handle this.

• Let SSH generally use a "private" credential cache per GSSAPIClientIdentity value?
• Try to look up the "main" credential cache first, and use that it a matching ticket already exists?
• Never create a ticket in the "main" credential cache, even when empty?

Thanks,
Chris.

[calestyo]

Meanwhile I've seen that there's:

https://bugzilla.mindrot.org/show_bug.cgi?id=2775

and also

https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/openssh-7.7p1-gssapi-new-unique.patch

Maybe these do more or less what I'm looking for (and should be merged into the GSSAPI patch?).

[Jakuje]

I intentionally left out that patch from this repository, as this repository is limited to the gssapi key exchange implementation.

What you are asking is implemented as separate patch as asked by some of our users and you are free to use it. Should work in Fedora (and if not, feel free to open bugs there). I can not comment for upstream nor other distributions if they are interested in supporting this.

[calestyo]

I intentionally left out that patch from this repository, as this repository is limited to the gssapi key exchange implementation.

Okay I see, but since OpenSSH upstream is probably not going to merge any of these GSSAPI patch soon, woulnd't it make sense if all distros share some common upstream repo for those patches?
Especially also with respect to security?

[Jakuje]

Indeed, it would be better, but each and every distribution has different aims and what might make sense for one is completely unrelated for other and what might be a useful feature might be considered maintenance burden.

[panlinux]

Meanwhile I've seen that there's: https://bugzilla.mindrot.org/show_bug.cgi?id=2775 and also https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/openssh-7.7p1-gssapi-new-unique.patch

Maybe these do more or less what I'm looking for (and should be merged into the GSSAPI patch?).

In Ubuntu we are evaluating[1] the inclusion of the new-unique patch. We have daily builds applying that patch on top of our packaging, and also added autopkgtests[2] that exercise the "gssapi-new-unique" functionality. For now, during this period, the patched builds are in a separate package and we use update-alternatives to avoid a conflict between patched and unpatched sshd.

1. https://launchpad.net/~canonical-server/+archive/ubuntu/openssh-server-default-ccache-testing
2. https://git.launchpad.net/~canonical-server/ubuntu/+source/openssh/tree/debian/tests/ssh-gssapi?h=openssh-split-unique-gssapi

[calestyo]

Indeed, it would be better, but each and every distribution has different aims and what might make sense for one is completely unrelated for other and what might be a useful feature might be considered maintenance burden.

I anyway just meant this for a the "base patches", i.e. only based on upstream's git with no further distro specific modifications.

That way there could have been some more eyes on that at least that (and the possible security implications of it).

In Ubuntu we are evaluating[1] the inclusion of the new-unique patch.

I've asked a few days ago whether Debian could add it.