4

I am successfully connecting to my university's network via ssh with Kerberos ticket authentication. Normal, verbose operation (kinit a ticket, then ssh user@hostname) works fine.

The Problem

When setting up ssh aliases in the ~/.ssh/config file, however, ssh completely ignores Kerberos and prompts for my password. (See debugging output below.)

Why is this? How might I configure it to use Kerberos?

Note: normal ssh operation with Kerberos continues to work before and after attempts with ssh aliases. Additionally ssh aliases work as intended when provided with a login pw.

(System: Mac OS 10.11.4, Darwin Kernel Version 15.4.0, OpenSSH_6.9p1, LibreSSL 2.1.8, Kerberos 5 release 1.7)

Debugging Output

When running SSH from the CL I added -vvv for verbose debug info, then diffed the output. I've included the portions that differed significantly.

$ ssh -vvv [ssh-alias]

debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup password debug3: remaining preferred: ,keyboard-interactive,password debug3: authmethod_is_enabled password debug1: Next authentication method: password atmills@login.engin.umich.edu's password: debug2: we sent a password packet, wait for reply debug1: Authentication succeeded (password). Authenticated to login.engin.umich.edu ([141.213.74.56]:22).

$ ssh -vvv [user@host]

debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup gssapi-keyex debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-keyex debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug2: we did not send a packet, disable method debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug3: Trying to reverse map address 141.213.74.58. debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Delegating credentials debug1: Delegating credentials debug1: Authentication succeeded (gssapi-with-mic). Authenticated to login.engin.umich.edu ([141.213.74.58]:22).

  • compare verbose logs (-vvv) from both connections. There should be no difference in using and not-using alias. – Jakuje May 2 '16 at 20:23
  • 1
    A HostName entry with the fully qualified hostname might be a good thing to have. – thrig May 2 '16 at 20:25
  • @Jakuje Thanks for the help. There were significant differences, which I included in a post update. Thoughts? – Alexander Mills May 4 '16 at 2:33
  • @thrig Can you elaborate on this? – Alexander Mills May 4 '16 at 2:33
  • Do you have anything besides this alias in your .config file? Is this just a one-liner or is it complex? – BowlOfRed May 4 '16 at 4:38
1

Kerberos as I've seen it configured deals with fully qualified hostnames (gato.example.org) and not unqualified hosts (gato); using an unqualified hostname produces for me in testing ssh debug lines of:

debug1: Next authentication method: gssapi-with-mic
debug1:  Miscellaneous failure (see text)
Error from KDC: LOOKING_UP_SERVER while looking up 'host/gato@EXAMPLE.ORG' (cached result, timeout in 1089 sec)

This is due to the kerberos hosts typically only having fully qualified host principal entries in their /etc/krb5.keytab file:

[root@gato ~]# strings /etc/krb5.keytab | head -3
EXAMPLE.ORG
host
gato.example.org

Your logs appear to both use the fully qualified login.engin.umich.edu hostname so your problem may be something else, though in general when dealing with kerberos it would be best to force fully qualified hostnames in ~/.ssh/config, either manually:

Host gato.example.org gato bubba
    Hostname gato.example.org

Or instead via the CanonicalizeHostname keyword (see ssh_config(5) for details and caveats).

Another point to note is that login.engin.umich.edu is a pool of hosts; one thing to test would be specific nodes in this pool are misconfigured for kerberos and thus dumping you back to password auth, though that would take editing /etc/hosts to contain something like:

141.213.74.56 login.engin.umich.edu

And remembering to remove the test entries when done. (Using the IP address is no good for kerberos, you need to use the hostname, hence the need to munge /etc/hosts for testing.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.