www.cendio.com
Bug 4681 - Kerberos authentication requires that agent_hostname is set in vsmagent.hconf
: Kerberos authentication requires that agent_hostname is set in vsmagent.hconf
Status: NEW
: ThinLinc
Client
: 4.1.0
: PC Unknown
: P2 Normal
: LowPrio
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2013-06-05 11:05 by
Modified: 2013-06-18 14:02 (History)
Acceptance Criteria:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From cendio 2013-06-05 11:05:04
Otherwise, ssh is connecting to an IP address and doesn't know the realm. We
should try to avoid this requirement, perhaps by passing the realm as an
argument to ssh.
------- Comment #1 From cendio 2013-06-14 15:25:53 -------
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 From cendio 2013-06-14 15:27:16 -------
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 From cendio 2013-06-18 12:55:49 -------
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 From cendio 2013-06-18 14:02:18 -------
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.