Kjell,
I have a working solution using Kerberos TGTs to ssh between servers within the realm
using OTP. This solution requires that you log into one realm server with password and
otp. From there you can ssh to the rest of the realm via kerberos tickets.
I only got to this state by trial and error so some of my statements and assumptions could
be wrong. My servers are a mix of Rhel 7.9 and Rhel8.x My IDM servers are Rhel8 latest.
On the ssh server you need to enable GSSAPIAuthentication in sshd_config.
On all the clients you also need to enable GSSAPIAuthentication in ssh_config,
There are some gotchas.
You can't ssh to the ssh server by IP address. GSSAPIAuthentication passes the
request to IDM by hostname. So ssh user(a)192.168.1.101 will fail back to password via
pam.sss
On Rhel7 you can only ssh to the FQDN of the ssh server. So you should do: ssh
user(a)myserver.realm.com .
If the Client is Rhel8 you should be able to ssh to the short hostname such as ssh
user@myserver .
On Rhel7 clients getting the ssh to work with short hostnames is problematic. You can
resolve the problem with the following settings in ssh_config:
CanonicalizeHostname always
CanonicalDomains
myrealm.com
CanonicalizeFallbackLocal yes
CanonicalizeMaxDots 0
GSSAPITrustDns yes
Host *.myrealm.com
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes
Host ! *.myrealm.com
GSSAPIAuthentication no
Your experience with users that don't have an OTP being unable to log into a host that
requires OTP is expected.
There are plenty of edge cases around caching, so test before production.
It is also problematic to get a new ticket with kinit if you use OTP. There are steps to
get around it, but I am waiting for the solution to be a native Redhat process.
We regularly get this TGT ssh method to fail, when there are too may expired tickets on
the ssh server. Once logged into the ssh server by password OtP, you can run kdestroy -A
to clear cache and you can again ssh via TGTs.
Obviously ssh and sshd should be configured to failback to username/password+otp with:
ChallengeResponseAuthentication yes