Bug 4681 - Kerberos authentication fails if agent_hostname isn't principal name
Summary: Kerberos authentication fails if agent_hostname isn't principal name
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client (show other bugs)
Version: 4.1.0
Hardware: PC Unknown
: P2 Normal
Target Milestone: LowPrio
Assignee: Peter Åstrand
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-05 11:05 CEST by Aaron Sowry
Modified: 2022-12-06 13:23 CET (History)
0 users

See Also:
Acceptance Criteria:


Attachments

Description Aaron Sowry cendio 2013-06-05 11:05:04 CEST
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 Pierre Ossman cendio 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 cendio 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 cendio 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 cendio 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.

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