使用 gssapi-keyex 或 gssapi-with-mic 进行 SSH 身份验证（不允许使用公钥）

Question

我的公司已禁用 SSH 公钥身份验证，因此每次我都必须手动输入密码（我不打算更改/etc/ssh/sshd_config）。

但是gssapi-keyex，gssapi-with-mic身份验证已启用（请参阅下面的ssh调试输出）。

在这种情况下如何使用自动登录？
我可以利用gssapi-keyex和/或gssapi-with-mic身份验证吗？

> ssh -v -o PreferredAuthentications=publickey hostxx.domainxx
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to hostxx.domainxx [11.22.33.44] port 22.
debug1: Connection established.
debug1: identity file /home/me/.ssh/identity type -1
debug1: identity file /home/me/.ssh/id_rsa type -1
debug1: identity file /home/me/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'hostxx.domainxx' is known and matches the RSA host key.
debug1: Found key in /home/me/.ssh/known_hosts:2
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,password
debug1: No more authentication methods to try.
Permission denied (gssapi-keyex,gssapi-with-mic,password).

Answer 1

也许。

• 作为标准登录过程的一部分或手动（kinit，适用于 Windows 的 MIT Kerberos），您能否在您的客户端系统上为您的主体获取票证？
• 服务器是否有 kerberos 主体，或者你能给它一个吗？它应该是这样的形式host/server.example.com@EXAMPLE.COM。
• GSSAPI您的客户端是否启用了身份验证？
• 您的客户端是否通过 DNS TXT 资源记录或本地映射知道服务器属于哪个领域？

如果您对以上所有内容都说“是” ，那么恭喜您，您可以使用GSSAPIAuthentication.

• 您可能还需要启用凭据委派，具体取决于您的设置。

测试步骤：（
假设：domain = example.com ; realm =EXAMPLE.COM）

1. kinit username@EXAMPLE.COM
   • 理想情况下，这是通过你的标准登录过程通过包括处理pam_krb5或pam_sss（与auth_provider = krb5在适当的）pam stack。
2. kvno host/server.example.com@EXAMPLE.COM
   • 这是一个调试步骤。ssh如果您有一个有效的缓存并且您正在与sshd支持gssapi-with-mic或gssapi-keyex.
3. dig _kerberos.example.com txt 应该回来 "EXAMPLE.COM"
   • 或者，映射可以存储在as的[domain_realm]部分中，但该方法的扩展性要好得多。/etc/krb5.conf.example.com = EXAMPLE.COMdns
4. ssh -o GSSAPIAuthentication=yes username@server.example.com
   • 要登录服务器上您的主体的用户名以外的用户名，必须知道将其映射到我没有在这里介绍的详细信息。

Answer 2

4 步方法是正确的（DNS 中还有更优雅的 Kerberos SRV 记录，并且存在于每个 Active Directory 中）。我一直在使用它，并且出于安全和控制相关的原因一直在提倡上述公钥方法。

也就是说，这仅提供交互式登录，尽管一旦您在工作站上获得票证，它就可以是准交互式的。Kerberos 票证的作用很像 SSH 代理；一旦你拥有它，新的连接是即时的且无需密码；尽管有时间限制。

要获得交互式批量登录，您需要获得一个密钥表文件，该文件实质上包含 Kerberos 帐户的密码，很像 SSH 密钥的私有一半。根据安全预防措施适用；特别是因为密钥表未加密或使用密码保护。

我非常不愿意为我的用户提供他们个人帐户的密钥表，但是我积极地使用具有最低权限的服务帐户来处理各种批处理作业，尤其是在将凭据委派给远程系统至关重要的情况下，pubkey 根本无法做到这一点达到。

可以使用 Unix 上的 ktutil 或 Windows 上的 KTPASS.EXE（后者来自 AD Kerberos 服务）创建密钥表。请注意 ktutil 存在两种风格，Heimdal 和 MIT，它们的语法不同。阅读相关系统上的联机帮助页会有所帮助。