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認證更有效吧.