油灰Kerberos / GSSAPI身份验证

9

我配置了一些Linux服务器，以在RHEL6上使用sssd对Active Directory Kerberos进行身份验证。我还启用了GSSAPI身份验证，以期实现无密码登录。

但是，如果没有密码，我似乎无法让Putty（0.63）进行身份验证。

GSSAPI在配置用于AD身份验证的Linux系统（openSSH客户端）之间工作，使用.ssh / config设置启用GSSAPI。

它也可以在Cygwin（openSSH客户端）中使用相同的.ssh / config设置，并运行kinit命令来获取票证。

Samba还在所有Linux系统上共享，包括从Windows资源管理器工作的主目录，而无需输入密码（我不确定GSSAPI是否在那里发挥作用）

我可以尝试哪种方法来解决此问题？我的大多数用户都使用腻子。另外，我不是Windows管理员，因此我无法在域控制器上执行任何操作。我的帐户仅具有将服务器添加到AD域的特权。

我打开腻子SSH数据包日志记录。我发现这很有趣，但是我不确定该如何处理：

Event Log: Server version: SSH-2.0-OpenSSH_5.3
Event Log: Using SSH protocol version 2
Event Log: We claim version: SSH-2.0-PuTTY_Release_0.63
Outgoing packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
Incoming packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
Event Log: Doing Diffie-Hellman group exchange
Outgoing packet #0x1, type 30 / 0x1e (SSH2_MSG_KEX_DH_GEX_REQUEST)
Incoming packet #0x1, type 31 / 0x1f (SSH2_MSG_KEX_DH_GEX_GROUP)
Event Log: Doing Diffie-Hellman key exchange with hash SHA-256
Outgoing packet #0x2, type 32 / 0x20 (SSH2_MSG_KEX_DH_GEX_INIT)
Incoming packet #0x2, type 33 / 0x21 (SSH2_MSG_KEX_DH_GEX_REPLY)
Outgoing packet #0x3, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Initialised AES-256 SDCTR client->server encryption
Event Log: Initialised HMAC-SHA1 client->server MAC algorithm
Outgoing raw data at 2014-11-25 00:21:08
Incoming packet #0x3, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Initialised AES-256 SDCTR server->client encryption
Event Log: Initialised HMAC-SHA1 server->client MAC algorithm
Outgoing packet #0x4, type 5 / 0x05 (SSH2_MSG_SERVICE_REQUEST)
Incoming packet #0x6, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
...%gssapi-keyex
,gssapi-with-mic
,password.
Event Log: Using SSPI from SECUR32.DLL
Event Log: Attempting GSSAPI authentication
Outgoing packet #0x6, type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
Incoming packet #0x7, type 60 / 0x3c (SSH2_MSG_USERAUTH_GSSAPI_RESPONSE)
Event Log: GSSAPI authentication initialised
Outgoing packet #0x7, type 61 / 0x3d (SSH2_MSG_USERAUTH_GSSAPI_TOKEN)
Incoming packet #0x8, type 61 / 0x3d (SSH2_MSG_USERAUTH_GSSAPI_TOKEN)
Event Log: GSSAPI authentication initialised
Event Log: GSSAPI authentication loop finished OK
Outgoing packet #0x8, type 66 / 0x42 (SSH2_MSG_USERAUTH_GSSAPI_MIC)
Incoming packet #0x9, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
...%gssapi-keyex
,gssapi-with-mic
,password.

— xdaxdb
source

1

在ssh守护进程之夜打开调试显示有用的信息。您始终可以在其他端口上启动第二个实例进行测试。

— 保罗·霍尔丹

7

[如果您还需要票证委派（例如，在登录后在服务器上安装光纤化文件系统），请确保在PuTTY中也启用了GSSAPI委派，并且您在Active Directory中的“委派”选项卡中将登录的服务器标记为： “ 信任此计算机可以委派任何服务（仅Kerberos） ”，默认情况下不启用。奇怪的是，仅在从PuTTY之类的Windows客户端进行委派时，才需要AD中的后一种信任设置。Linux“ ssh -K”客户端不需要它。]

在不属于Active Directory域的自我管理（个人）Windows计算机上，您仍然可以通过PuTTY使用Kerberos / GSSAPI身份验证（和票证委派），但是您必须自己获取票证。不幸的是，Windows 7并未安装任何等效的kinit程序（供您手动请求票证），并且PuTTY也不会提示您输入Kerberos密码（如果您没有票证）。因此，您必须为Windows安装MIT Kerberos软件包，其中包括常用的kinit / klist / kdestroy命令行工具以及简洁的GUI工具“ MIT Kerberos Ticket Manager”。使用这些来获取您的票，然后PuTTY将自动使用MIT GSSAPI库而不是Microsoft SSPI库，它应该可以正常工作。如果“ MIT Kerberos票证管理器”正在运行，则当PuTTY需要票证时，它将自动提示您输入Kerberos密码，因此从“启动”文件夹进行链接是一个好主意。

— 马库斯·库恩（Markus Kuhn）
source

1

从那以后，我了解到Windows实际上确实具有一种与MIT Kerberos' kinit命令等效的命令cmdkey。

— Markus Kuhn

1

关于启用票证委派，如果您是了解Active Directory实际上只是幕后的Microsoft LDAPv3的人之一：请确保您希望能够委派Kerberos票证的服务主体的LDAP条目包含在其userAccountControl中。置位TRUSTED_FOR_DELEGATION = 0x80000 = 524288。

— Markus Kuhn

仅供参考，考虑配置“信任此计算机以委派任何服务（仅Kerberos）”（例如不受约束的Kerberos委派）的任何人，这对您应该考虑的安全性有严重的影响。建议您先阅读adsecurity.org/?p=1667。

— Brad

3

首先，仔细检查您在运行PuTTY的Windows框中的klist输出是否显示有效的TGT。然后在您的PuTTY会话的配置中，确保已在中启用了Attempt GSSAPI身份验证Connection - SSH - Auth - GSSAPI。最后，请确保已将其配置为使用您的用户名自动登录Connection - Data。您可以显式指定用户名，也可以选择“ 使用系统用户名 ”单选按钮。

从历史上看，这就是通过Kerberos使无密码SSH登录工作所需要做的。

— 瑞安·博尔格（Ryan Bolger）
source

1

klist tgt看起来对我来说很有意义。说它也是可转发的。klist显示5个键，例如Exchange。我也有要尝试使用的Linux服务器的门票。我已经检查了腻子配置100次。所有在线文档/指南几乎都说相同的话，因此我确信该部分设置正确。

— xdaxdb 2014年

3

问题出在Windows Kerberos设置中。我认为我们的Active Directory设置很时髦，我真的不知道我不是Windows管理员。

但是我通过在Windows 7 CLI中使用ksetup手动配置Kerberos来解决此问题。

重新启动到远程工作站后，我无法登录到PC。那是因为在原始配置中，我的领域域的TLD部分始终不存在（域\用户），但是在手动配置它之后，我不得不更改登录域以反映完整的领域域名（domain.TLD \ user），并且我现在可以登录Windows PC，尽管现在似乎需要更长的时间才能进行身份验证。

更改之前，ksetup的输出仅显示我的默认领域，并且使用小写形式。

我使用了“ nslookup -type = SRV _kerberos._tcp.domain.TLD”来获取我领域的所有kdc服务器。

我没有设置任何标志。

我设置了映射的用户名“ ksetup / mapuser user@domain.TLD用户”

我使用的资源：https : //wiki.ncsa.illinois.edu/display/ITS/Windows+7+Kerberos+Login+using+External+Kerberos+KDC

https://www.cgl.ucsf.edu/Security/CGLAUTH/CGLAUTH.html

如果有人有任何建议，我可以向Windows管理员介绍如何解决此问题（是否损坏？），我会继续进行下去。

— xdaxdb
source