Comment 1 Pierre Ossman 2013-06-14 15:25:53 CEST

The original comment is actually incorrect. SSH needs to know the principal of the remote server, not just the realm. So the information we get from the master is insufficient.

Comment 2 Pierre Ossman 2013-06-14 15:27:16 CEST

The patch referenced in bug 4707 also adds support for doing a reverse lookup of the ip address to figure out the principal. Not sure about the security implications of doing that though, and it is disabled by default.

Comment 3 Pierre Ossman 2013-06-18 12:55:49 CEST

Things are apparently a bit more odd that we first suspected. We've found a system where we can connect to SSH even when using an ip address. We do not yet know what is different about this system.

We have discovered some things in the process of debugging this though:

1. ssh does indeed give GSSAPI the ip address for the requested token name (e.g. "host@1.2.3.4").

2. GSSAPI (at least MIT's) will by itself do a reverse lookup and use that when requesting a service ticket ("1.2.3.4" => "server.example.com" => "host/server.example.com@EXAMPLE.COM").

3. ssh will get a proper service ticket both in the working and non-working cases

4. Some servers still reject this ticket for unknown reasons.

Comment 4 Pierre Ossman 2013-06-18 14:02:18 CEST

More confusion. I cannot reproduce this problem on Linux, but it does happen on Windows.

There is however a setting with MIT kerberos that controls this, called "rdns". It is enabled by default, but some distributions (e.g. Fedora 19) explicitly disables it. Aaron was using a Fedora 19 for his testing, so that is probably why he saw the problem initially.

It is also disabled on Windows. No idea if there is a way to enable that behaviour.