ssh to IP literal

[Brian Candler]

On Mon, Dec 13, 2010 at 06:52:08AM +0000, Victor Sudakov wrote:
> I still don't quite understand why it should try to contact a weird
> realm while I have 
> 
> [libdefaults]
>  default_realm = SIBPTUS.TOMSK.RU
> 
> in /etc/krb5.conf. Shouldn't it request a ticket for
> host/10.14.134.5 at SIBPTUS.TOMSK.RU  by default?

I had the same misunderstanding as you when I came to Kerberos.

The default_realm is used to qualify principals with no realm, e.g.
'kinit foo' becomes 'kinit foo at SIBPTUS.TOMSK.RU'

But it is not used to form the realm when connecting to a remote host.
There is a series of steps which is followed, which involves DNS lookups
(if enabled), hostname to realm mapping, and the fallback is to use the
uppercased domain from the FQDN.

e.g. ssh to foo.example.com would fall back to EXAMPLE.COM as the realm.

Greg's very clear explanation to me is in this thread:
http://www.mail-archive.com/kerberos@mit.edu/msg17150.html

> > If you add an explicit domain_realm mapping for each IP address to the
> > [domain_realm] section of your krb5.conf file, it will probably work, but
> > it's generally a much better idea to use real host names (possibly in some
> > private domain ending in .local or some similar marker).
> 
> I agree in general but DNS is sometimes yet another point of failure.

You can always use /etc/hosts to map each IP to a hostname, and then map
hostnames (or groups of hostnames) to realms in krb5.conf

DNS as a point of failure shouldn't really be any more of a concern than
your KDC being a point of failure. You need resilience in both.

The security issues of using DNS for Kerberos are not as great as you might
think.  If an attacker causes you to fetch a service ticket for the wrong
realm, then it will simply be rejected by the target host (there are some
edge cases involving cross-realm trust to a domain controlled by the
attacker, in which case the trust is probably misplaced anyway :-)

Regards,

Brian.