Kerberos+LDAP+NFSv4 实现单点登陆(续3)--SSH前端
( 附:单点登陆管理图形界面前端 fgsso-ver0.0.8.zip 源代码 下载地址 http://u.163.com/1ZIRCPDE 提取码: YczFnrMn )
( 附:单点登陆 Kerberos+LDAP 一键安装脚本 onekeysso-ver0.0.8.zip 源代码 下载地址 http://u.163.com/qvl6pG4O 提取码: OYkiJzVI )数据库
实验环境 : debian 10
heimdal 非MITapi
实验内容 : ssh登陆经过Kerberos认证(KerberosAuthentication认证、GSSAPIKeyExchange、GSSAPIAuthentication认证、免密码登陆)安全
三台主机:
ssh服务器 : 192.168.1.203 vmsrv
ssh客户机 : 192.168.1.202 vmcl
kdc服务器 : 192.168.1.201 vmkdc 即Kerberos服务器
kdc服务器的安装再也不介绍,请参考前面篇章<Kerberos+LDAP+NFSv4 实现单点登陆>( http://www.javashuo.com/article/p-fooaiypp-kc.html )ssh
debian的基础系统已标配了ssh客/服,如下的ssh客/服都是在基础系统上配置,除ssh客户机要经过GSSAPI认证需安装heimdal-clients外,其它不需额外安装包.ide
一.KerberosAuthentication认证
1.ssh服务器配置
1)修改/etc/ssh/sshd_config为有以下两行
KerberosAuthentication yes
GSSAPIAuthentication no.net
2)ssh服务器必须配置krb5.conf,手工新建/etc/krb5.conf,内容以下:命令行
# 本实验Kerberos的realm取为CTP.NET [libdefaults] default_realm = CTP.NET # The following krb5.conf variables are only for MIT Kerberos. kdc_timesync = 1 ccache_type = 4 # forwardable = true 注释掉 # proxiable = true 注释掉 # The following libdefaults parameters are only for Heimdal Kerberos. fcc-mit-ticketflags = true [realms] CTP.NET = { kdc = 192.168.1.201 admin_server = 192.168.1.201 }
3)ssh服务器需添加同名Kerberos用户的本地用户
除非使用LDAP统一帐号,则需在ssh服务器建立一本地用户,而且本地用户名必须与Kerberos用户名相同,但本地用户密码尽可能不要与Kerberos用户密码相同.由于咱们的实验目的是要经过Kerberos调试
认证,取不一样密码以方便区分那个是本地用户那个是Kerberos用户.
如下假设kdc服务器已建立了名为krblinlin用户主体(principal),咱们就在ssh服务器添加名为krblinlin的本地用户.
root@vmsrv:/home/linlin# adduser krblinlin Adding user `krblinlin' ... ... Enter new UNIX password: 注意密码不要与Kerberos用户密码相同 Retype new UNIX password: ... root@vmsrv:/home/linlin#
2.ssh客户机
就最基本的系统,不需安装配置任何东西,更不需heimdal-clients.
ssh链接远程主机时,一般会依次按publickey、gssapi-with-mic、password、keyboard-interactive等方法认证,前面方法认证成功就没必要继续后面方法,前面方法认证失败就依次继续后面方法.
所以同名krblinlin的Kerberos用户和本地用户取不一样密码就方便实验的验证,知道是经过那个认证方法.
登陆ssh服务器(192.168.1.203)
root@vmcl:~# ssh -o GSSAPIAuthentication=no krblinlin@192.168.1.203 krblinlin@192.168.1.203's password:请输入Kerberos的密码,非本地用户密码
已成功经过Kerberos认证
命令行指定GSSAPIAuthentication=no是由于我没改变ssh客户端默认配置,而默认行为是容许GSSAPIAuthentication,实验为排除GSSAPI干扰,因此命令行指定禁用GSSAPIAuthentication.
假如输入的密码是本地用户密码,照样登陆成功,但不是经过Kerberos认证,而是UNIX password认证.
二.GSSAPIKeyExchange
ssh服务器和ssh客户机都必须配置krb5.conf,都手工新建/etc/krb5.conf,其内容同上第一章节.
ssh服务器不需安装heimdal-clients,但必需有keytab文件,且主机主体取全名vmsrv.ctp.net及设置为应用服务器.
1.到kdc服务器
1)添加ssh服务器主机主体,名为host/vmsrv.ctp.net
root@vmkdc:~# kadmin -l add -r --use-defaults host/vmsrv.ctp.net
2)因上面缺省是disallow-svr,需删除disallow-svr,使host/vmsrv.ctp.net成为应用服务器
root@vmkdc:~# kadmin -l modify -a -disallow-svr host/vmsrv.ctp.net
3)导出keytab
root@vmkdc:~# kadmin -l ext -k /root/krb5.keytab host/vmsrv.ctp.net
4)经过各类途径如U盘,将krb5.keytab复制到ssh服务器的/etc目录下,确保krb5.keytab权限为root拥有及只root读写
2.ssh服务器配置
1)修改/etc/ssh/sshd_config为有以下三行
KerberosAuthentication yes
GSSAPIAuthentication no
GSSAPIKeyExchange yes
2)修改/etc/hostname
确保主机名和主机主体名一致.
root@vmsrv:~# cat /etc/hostname vmsrv.ctp.net root@vmsrv:~#
3)重启系统
3.ssh客户机
ssh链接远程主机时,若是当前用户目录的known_hosts文件中没有远程主机的公钥,一般会看到一个加入远程主机公钥确认身份的提示信息,以下:
The authenticity of host '192.168.1.203 (192.168.1.203)' can't be established.
ECDSA key fingerprint is SHA256:1iC7QAqNJYsP85BFWVcItwxEFOIr07jv76YGUW6CRrw.
Are you sure you want to continue connecting (yes/no)?
而使用GSSAPIKeyExchange便不需上面的确认过程,而且known_hosts文件不需任何内容.
1)安装Kerberos客户端
root@vmcl:/# apt-get install heimdal-clients
2)以root登陆本机
3)为实验GSSAPIKeyExchange的做用,先清空/root/.ssh/known_hosts的内容
4)获取票据
root@vmcl:~# kinit --no-forwardable krblinlin krblinlin@CTP.NET's Password: 输入Kerberos的密码
5)登陆ssh服务器
root@vmcl:~# ssh -o GSSAPIAuthentication=no -o GSSAPIKeyExchange=yes krblinlin@192.168.1.203 krblinlin@192.168.1.203's password: 输入Kerberos的密码或者本地用户密码
这时可留意到通过kinit及GSSAPIKeyExchange=yes,首次登陆ssh服务器不需确认是否加公钥到known_hosts文件.并可验证查看/root/.ssh/known_hosts是为空的.
三.GSSAPIAuthentication认证
1.ssh服务器和ssh客户机配置及安装同上第二章节
2.ssh服务器配置
1)修改/etc/ssh/sshd_config为有以下三行
KerberosAuthentication no
GSSAPIAuthentication yes
GSSAPIKeyExchange no
3.ssh客户机
1)修改/etc/hosts
添加ssh服务器主机名和IP地址对应关系,以便解析主机名.
root@vmcl:~# cat /etc/hosts 127.0.0.1 localhost 192.168.1.203 vmsrv.ctp.net root@vmcl:~#
2)获取票据
root@vmcl:~# kinit --no-forwardable krblinlin krblinlin@CTP.NET's Password: 输入Kerberos的密码
3)登陆ssh服务器
注意:远程主机必须是主机名(vmsrv.ctp.net),不能是IP地址(192.168.1.203).
root@vmcl:~# ssh -o GSSAPIAuthentication=yes krblinlin@vmsrv.ctp.net Linux vmsrv 4.17.0-1-686 #1 SMP Debian 4.17.8-1 (2018-07-20) i686
获取票据后,没必要再输入密码就登陆成功
四.免密码登陆
ssh有多个免密码方案,本文的目的是ssh与Kerberos的集成,因此本章节免密码登陆的方案采用GSSAPIAuthentication.
免密码登陆过程有两个层次:第一个层次仅仅要求交互过程当中不需键盘敲密码;第二个层次完全没有任何交互过程.
第一个层即如没启用GSSAPIKeyExchange,ssh客户机首次登陆某台ssh服务器,需有个确认是否加公钥到known_hosts文件的交互过程(便是否信任ssh服务器).
下面就按第二个层次完全没有任何交互过程
1.ssh服务器和ssh客户机配置及安装同上第三章节
2.到kdc服务器
1)导出主体用户krblinlin的keytab
root@vmkdc:~# kadmin -l ext -k /root/krblinlin.keytab krblinlin
2)经过各类途径如U盘,将krblinlin.keytab复制到ssh客户机的登陆用户目录下,确保权限就为该用户拥有及只读写
本实验ssh客户机是以root登陆,用户目录是/root目录.
3.ssh服务器配置
1)修改/etc/ssh/sshd_config为有以下三行
KerberosAuthentication no
GSSAPIAuthentication yes
GSSAPIKeyExchange yes
4.ssh客户机
1)以root登陆本机
2)清空/root/.ssh/known_hosts的内容
3)为实验目的先销毁票据
root@vmcl:~# kdestroy
root@vmcl:~# klist
klist: No ticket file: /tmp/krb5cc_0
4)免密码获取票据
root@vmcl:~# kinit -t /root/krblinlin.keytab --no-forwardable krblinlin
已指定了keytab,没必要输入密码
root@vmcl:~# klist Credentials cache: FILE:/tmp/krb5cc_0 Principal: krblinlin@CTP.NET Issued Expires Principal Aug 6 02:23:55 2018 Feb 4 17:23:55 2019 krbtgt/CTP.NET@CTP.NET
5)免密码登陆
root@vmcl:~# ssh -o GSSAPIAuthentication=yes -o GSSAPIKeyExchange=yes krblinlin@vmsrv.ctp.net Linux vmsrv 4.17.0-1-686 #1 SMP Debian 4.17.8-1 (2018-07-20) i686 krblinlin@vmsrv:~$
能够看到输入命令并回车后就直接登陆到ssh服务器
五.后记
1.主机主体
调试:
1)只启用GSSAPIKeyExchange
在ssh服务器上运行hostname命令,改变主机名称,到kdc服务器上,查看Kerberos的日志,发现日志中的[host/主机名]随ssh服务器主机名改变而改变.
2)只启用GSSAPIAuthentication
ssh命令行远程主机指定为IP地址(192.168.1.203),到kdc服务器上,查看Kerberos的日志,发现日志中的[host/主机名]是'host/192.168.1.203'.
3)若是[host/主机名]在Kerberos数据库中不存在,则认证失败
结论:
1)GSSAPIKeyExchange和ssh服务器的hostname命令返回的主机名相关
2)GSSAPIAuthentication和ssh命令行远程主机相关
3)主机名、主机DNS域名、主机主体名三者之间的名称要统一
2.免密码登陆安全问题
本实验是导出主体用户的keytab,须要保管好keytab文件;免密码登陆通常用于一开机启动、连续运行的服务,编写在脚本中,但主体用户票据还有个有效期、续期问题.限于本人水平,再也不讨论.或
许传统的PubkeyAuthentication认证更有效吧.