Automatically forwarding fresh Kerberos tickets?

[John Devitofranceschi]

In an environment where users use smart cards to authenticate on Windows and then use ssh to login to UNIX systems via GSSAPI, it is nigh impossible to renew/refresh the Kerberos credentials in the UNIX session. If the user fails to renew their credentials before they expire, the user is stuck and must log out and log back in to get valid tickets.

Meanwhile it is entirely likely that on the Windows desktop where they ssh'd from, fresh credentials have been served up constantly (when unlocking the screen, for example).

Might it be possible to modify OpenSSH to configure the client to automatically forward fresh Kerberos credentials to the target session (assuming the sshd on the target has been modified to accept such updates)? Or is this a change that the current implementation just couldn’t allow?

jd

[Douglas E Engert]

Post by John Devitofranceschi
In an environment where users use smart cards to authenticate on Windows and then use ssh to login to UNIX systems via GSSAPI, it is nigh impossible to renew/refresh the Kerberos credentials in the UNIX session. If the user fails to renew their credentials before they expire, the user is stuck and must log out and log back in to get valid tickets.
Meanwhile it is entirely likely that on the Windows desktop where they ssh'd from, fresh credentials have been served up constantly (when unlocking the screen, for example).
Might it be possible to modify OpenSSH to configure the client to automatically forward fresh Kerberos credentials to the target session (assuming the sshd on the target has been modified to accept such updates)? Or is this a change that the current implementation just couldn’t allow?

That would be a great feature would would depend on changes to the gssapi key exchange protocol.

As you said: "it is nigh impossible" and for years people have been working around it by using renewable tickets.
Most kerberos KDC would issue tickets for 10 to 24 hours, but renewable for a week.

But to avoid "If the user fails to renew"
I used to have the login session start a refresh.creds.token.sh so the user did not have to think.
about having to do it themselves. It would also get AFS tokens too:

#!/bin/sh
while /usr/bin/true
do
/usr/bin/kinit -R
/usr/afsws/bin/aklog
/usr/bin/sleep 3600
done

Now the Microsoft is starting to use SSH, (Google for: windows 10 powershell ssh)
There may be more of a push to get the gssapi key exchange to send renewed tickets.

Post by John Devitofranceschi
jd
_______________________________________________
openssh-unix-dev mailing list
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[Basney, Jim]

Post by John Devitofranceschi
In an environment where users use smart cards to authenticate on Windows
and then use ssh to login to UNIX systems via GSSAPI, it is nigh
impossible to renew/refresh the Kerberos credentials in the UNIX session.
If the user fails to renew their credentials before they expire, the user
is stuck and must log out and log back in to get valid tickets.
Meanwhile it is entirely likely that on the Windows desktop where they
ssh'd from, fresh credentials have been served up constantly (when
unlocking the screen, for example).
Might it be possible to modify OpenSSH to configure the client to
automatically forward fresh Kerberos credentials to the target session
(assuming the sshd on the target has been modified to accept such
updates)? Or is this a change that the current implementation just
couldn¹t allow?

Does the Cascading Credentials capability in Simon Wilkinson's OpenSSH
Kerberos/GSSAPI patch (http://www.sxw.org.uk/computing/patches/openssh)
provide the desired functionality?

-Jim

[Douglas E Engert]

Post by Basney, Jim

Post by John Devitofranceschi
In an environment where users use smart cards to authenticate on Windows
and then use ssh to login to UNIX systems via GSSAPI, it is nigh
impossible to renew/refresh the Kerberos credentials in the UNIX session.
If the user fails to renew their credentials before they expire, the user
is stuck and must log out and log back in to get valid tickets.
Meanwhile it is entirely likely that on the Windows desktop where they
ssh'd from, fresh credentials have been served up constantly (when
unlocking the screen, for example).
Might it be possible to modify OpenSSH to configure the client to
automatically forward fresh Kerberos credentials to the target session
(assuming the sshd on the target has been modified to accept such
updates)? Or is this a change that the current implementation just
couldn¹t allow?

Does the Cascading Credentials capability in Simon Wilkinson's OpenSSH
Kerberos/GSSAPI patch (http://www.sxw.org.uk/computing/patches/openssh)
provide the desired functionality?

Sure looks like it should.
On Ubuntu 14.4 with OpenSSH_6.6.1p1:
man sshd_config lists GssapiStoreCredentialsOnRekey
man ssh_config lists GSSAPIRenewalForcesRekey

Post by Basney, Jim
-Jim
_______________________________________________
openssh-unix-dev mailing list
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev