SSH的GSSAPIAuthentication和KerberosAuthentication的区别

最新推荐文章于 2024-07-09 11:56:02 发布

Laurence　

最新推荐文章于 2024-07-09 11:56:02 发布

阅读量4k

点赞数

CC 4.0 BY-SA版权

分类专栏： Linux与Shell编程文章标签： ssh GSSAPI Kerberos Authentication

本文为博主原创文章，未经博主允许不得转载。

本文链接：https://blog.csdn.net/bluishglc/article/details/125131326

Linux与Shell编程专栏收录该内容

52 篇文章

订阅专栏

本文通过5组测试详细解析了SSH配置中的GSSAPIAuthentication和KerberosAuthentication选项。GSSAPIAuthentication是标准的Kerberos认证，需要用户预先持有Kerberos凭证，登录时不需输入密码。KerberosAuthentication则不是独立的认证方式，它影响常规登录时是否进行Kerberos认证。测试表明KerberosAuthentication对GSSAPI认证无效，主要影响常规登录方式下的凭证获取。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

在SSH的/etc/ssh/sshd_config配置文件中有两个“看上去”很紧密的配置项：GSSAPIAuthentication和KerberosAuthentication，原因是：大家都知道在大多数情况下GSSAPI认证就是Kerberos认证，所以问题来了：那SSH里的这个KerberosAuthentication又是什么呢？和GSSAPIAuthentication有什么关系呢？我们接下来通过5组对比测试把这个问题解释清楚。本文原文链接：https://laurence.blog.csdn.net/article/details/125131326，转载请注明出处。

首先，介绍一下测试环境：

一台测试用的目标服务器：server1.example.com
一个测试用户：user1

服务器：server1.example.com必须已加入Kerberos（即安装了Kerberos客户端并配置了krb5.conf文件）
用户：user1在server1.example.com上有本地Linux账号（或SSSD同步而来LDAP账号），总之，使用普通密码或密钥方式可以登录。

现在开始如下5组测试：

测试1

● 服务器server1.example.com的/etc/ssh/sshd_config配置：

PasswordAuthentication yes
KerberosAuthentication no
GSSAPIAuthentication no

● 登录命令：

ssh -v user1@server1.example.com

● 登录时是否要求输入密码：

需要输入密码

● 登录日志显示的认证方式：

password认证

● 登录后是否获得Kerberos凭证：

登录后无Kerberos凭证

测试2

● 服务器server1.example.com的/etc/ssh/sshd_config配置：

PasswordAuthentication yes
KerberosAuthentication yes
GSSAPIAuthentication no

● 登录命令：

ssh -v user1@server1.example.com

● 登录时是否要求输入密码：

需要输入密码

● 登录日志显示的认证方式：

password认证

● 登录后是否获得Kerberos凭证

登录后自动获得Kerberos凭证

测试3

● 服务器server1.example.com的/etc/ssh/sshd_config配置：

PasswordAuthentication no
KerberosAuthentication no
GSSAPIAuthentication yes

● 登录命令：

# GSSAPI方式登录要求本地必须已获得Kerberos凭证，所以需要先执行kinit
kinit user1
# 参数-K：Enables GSSAPI-based authentication and forwarding (delegation) of GSSAPI credentials to the server.
# -K参数指定将要使用GSSAPI方式登录，且会将本地的Kerberos凭证转发到要登录的服务器上
# 最终的效果就是：登录后，在目标服务器上会自动获得user1的Kerberos凭证
ssh -v -K user1@server1.example.com

● 登录时是否要求输入密码：

不需要输入密码

● 登录日志显示的认证方式：

gssapi-with-mic认证

● 登录后是否获得Kerberos凭证

登录后自动获得Kerberos凭证

测试4

● 服务器server1.example.com的/etc/ssh/sshd_config配置：

PasswordAuthentication no
KerberosAuthentication no
GSSAPIAuthentication yes

● 登录命令：

# GSSAPI方式登录要求本地必须已获得Kerberos凭证，所以需要先执行kinit
kinit user1
# 参数-k：Disables forwarding (delegation) of GSSAPI credentials to the server.
# -k参数指定将要使用GSSAPI方式登录，但不会将本地的Kerberos凭证转发到要登录的服务器上
# 最终的效果就是：登录后，在目标服务器上不会有user1的Kerberos凭证
ssh -v -k user1@server1.example.com

● 登录时是否要求输入密码：

不需要输入密码

● 登录日志显示的认证方式：

gssapi-with-mic认证

● 登录后是否获得Kerberos凭证

登录后无Kerberos凭证

测试5

● 服务器server1.example.com的/etc/ssh/sshd_config配置：

PasswordAuthentication no
KerberosAuthentication yes
GSSAPIAuthentication yes

● 登录命令：

# GSSAPI方式登录要求本地必须已获得Kerberos凭证，所以需要先执行kinit
kinit user1
# 参数-k：Disables forwarding (delegation) of GSSAPI credentials to the server.
# -k参数指定将要使用GSSAPI方式登录，但不会将本地的Kerberos凭证转发到要登录的服务器上
# 最终的效果就是：登录后，在目标服务器上不会有user1的Kerberos凭证
ssh -v -k user1@server1.example.com

● 登录时是否要求输入密码：

不需要输入密码

● 登录日志显示的认证方式：

gssapi-with-mic认证

● 登录后是否获得Kerberos凭证

登录后无Kerberos凭证

备注：测试5和测试4验证结果一致，差别在于测试5开启了KerberosAuthentication yes，但验证结果表明对GSSAPI认证方式无效。

结论

应该说，GSSAPIAuthentication才是标准的Kerberos认证，因为它有两个标志性的特征：一是登录用户必须已经持有Kerberos凭证（即必须先执行一次kinit操作）；二是登录时不会要求输入密码（只会隐式地出示凭证）；而KerberosAuthentication并不是一种独立的认证方式，它不在SSH登录时会依次尝试的四种认证方法（publickey,gssapi-keyex,gssapi-with-mic,password）中。它的配置对于GSSAPI认证方法是无效的，使用GSSAPI登录时会有特有的参数：-K,-k用来控制是否要将本地Kerberos凭证转发到登录服务器上（即在登录后目标服务上是否会有Kerberos凭证）。仅从验证效果上观察，KerberosAuthentication更像是在常规登录（publickey和password）方式下起作用的“二级配置”，它的作用是用来决定当用户以常规方式登录时，是否连带进行一次（服务器本地的）Kerberos认证，以便决定用户在登录时是否可以直接获得Kerberos凭证。

要注意上述测试和结论是有前提的：登录的Kerberos账号在目标服务器上必须有一个对应的Linux账号，不管这个账号是通过useradd创建的本地Linux账号还是通过SSSD或LDAP同步而来的账号，这个Linux账号是必须存在的，否则就会报：“permission denied”错误，因为目标服务器上找不到对应的Linux账号。