I checked the /etc/krb5.conf on both a working and non-working machine, no differences at all.  Also checked the files in /var/lib/sss/pubconf/krb5-include.d that are included by krb5.conf, and no differences there.  All Kerberos packages on both machines are same versions.

klist -e Output on Jump Host (C7.4, after 2FA):

Ticket cache: FILE:/tmp/krb5cc_1001
Default principal: jeremy@IPA.TRUSTCHARGE.NET

Valid starting     Expires            Service principal
10/20/17 10:28:15  10/20/17 10:43:15  krbtgt/IPA.TRUSTCHARGE.NET@IPA.TRUSTCHARGE.NET
Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96

klist -e Output on working destination host (C6.9) after login via kerberos:

Ticket cache: FILE:/tmp/krb5cc_1001
Default principal: jeremy@IPA.TRUSTCHARGE.NET

Valid starting     Expires            Service principal
10/20/17 10:28:15  10/20/17 10:43:15  krbtgt/IPA.TRUSTCHARGE.NET@IPA.TRUSTCHARGE.NET
Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96

klist -e Output on failing destination host (C6.9) after failing to login with Kerberos and providing password:

Ticket cache: FILE:/tmp/krb5cc_1001_krZ6B5
Default principal: jeremy@IPA.TRUSTCHARGE.NET

Valid starting     Expires            Service principal
10/20/17 12:49:37  10/20/17 13:04:37  krbtgt/IPA.TRUSTCHARGE.NET@IPA.TRUSTCHARGE.NET
Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96

Thanks for any help you can give me!

Jeremy Utley

On Thu, Oct 19, 2017 at 4:39 PM, Robbie Harwood <rharwood@redhat.com> wrote:
Jeremy Utley writes:

> New FreeIPA deployment, and i have one server that is not allowing
> Kerberos to handle authentication, but instead is prompting for
> password with a valid kerberos ticket.  All other machines are working
> normally.  I've double-checked the /etc/ssh/sshd_config file,
> identical between the one not working, and the one that is.  Done the
> same for SSSD and IPA configuration info.  Entering password on the
> machine does work, and does result in a valid ticket being issued.
> Below is some debug info, generated with "KRB5_TRACE=/dev/stdout ssh
> -vvv {hostname}", and truncated down to only parts that differ:

Well, the machine krb5 configurations don't match.  Your "failing" is
using a FILE ccache, while the "working" is using KEYRING.  (Side note:
KEYRING is to be preferred wherever possible.)

Check that the versions of krb5 components match, and that they're
configured the same way (they're not, but this may not be the problem).

The "failing" machine isn't indicating what went wrong; check ssh error
logs on the server maybe?

Also: Please provide the output of `klist -e` on both the working and
failing machines *after* you've tried to ssh in.

Thanks,
--Robbie