So apparently this GSSAPITrustDns is not available.
Several GSSAPI options including GSSAPITrustDns are not actually part of standard OpenSSH – they are added by downstream patches, so they are only available in Debian/Ubuntu (and perhaps Fedora/RHEL), whereas Arch keeps its OpenSSH patching to a minimum.
As far as I know, GSSAPITrustDns is more or less equivalent to [libdefaults] rdns =, and in any case rDNS usage is enabled by default in current MIT Krb5 versions. I think the CERN documentation only asks you to enable this option for SSH because they're disablingrdns in their global /etc/krb5.conf. (I guess it kind of makes sense because they're using AD Kerberos?)
Note that your first example (SSH option) enables rDNS usage, while your own answer disables it, which seems to me like it's the opposite of what you tried to achieve and I'm not really sure what makes you say "this works".
It expires in 1 day, but it is there (will I have to renew this once a day? That is a problem for my future self).
That's normal for Kerberos tickets. By default, you will indeed have to kinit again once a day.
Typically you can use kinit -r 7d to get a ticket that can be renewed for up to 7 days without a password (exchanging the old ticket for a new one) simply by running kinit -R. Note that your realm administrator might have adjusted the possible renewal time – if it's shorter or disabled, the KDC will just quietly cap the renewal time to the maximum allowed, so check klist afterwards.
The krenew tool (found in the AUR "kstart" package) can be used to refresh tickets in background, as a somewhat smarter alternative to just scheduling a kinit -R cronjob.
The same package comes with a k5start tool which works in a very similar way, but can also acquire new tickets from a keytab – if you're allowed to save your password on disk, in Kerberos it's usually done by creating a "keytab" file which contains a hashed form of your password and can be used with kinit (or k5start).
User keytabs can be created using ktutil. (It's the same kind of keytab as in /etc/krb5.keytab, except it holds your user credentials and not a service's, so it is not obtained using the same tools – the "msktutil" and "cern-get-keytab" tools do not apply.)
$ ktutil ktutil: addent -password -p [email protected] -k 0 -f ktutil: wkt foo.keytab $ kinit -k -t foo.keytab
If you're allowed to use a user keytab, recent versions of MIT Krb5 can use it directly – all you need is to set the KRB5_CLIENT_KTNAME environment variable to the keytab path, and GSSAPI-using programs will automatically obtain or refresh tickets as necessary – without even needing to use kinit nor k5start.
