由SecureCRT引发的思考和学习
由SecureCRT引發(fā)的思考和學(xué)習(xí)
http://mp.weixin.qq.com/s?__biz=MzAxOTAzMDEwMA==&mid=2652500597&idx=1&sn=ecde4899e96d37849a5f17ac12d03018&scene=0#wechat_redirect
?
由于業(yè)務(wù)需要，最近在云上新購買了一批centos7.0的服務(wù)器,用腳本批量添加了用戶（腳本請見我之前的博客/秘鑰認(rèn)證用戶自動控制:http://my.oschina.net/pwd/blog/388254）,加完秘鑰之后發(fā)現(xiàn),但是secureCRT 拋出了一下異常。
解決過程：
初步懷疑秘鑰有問題,通過命令行去探測是否可以連接,-> ssh -i 秘鑰文件 用戶名@主機(jī) ，發(fā)現(xiàn)能正常連接，確認(rèn)秘鑰是OK的。
可能出在secureCRT配置問題，具體操作不詳解了,主要是涉及客戶端一些可視化的設(shè)置,搗鼓完以后沒好。
根據(jù)以上報錯聯(lián)想，可能是這個secureCrt 不支持以上的加密算法，上面已經(jīng)明確的提示了，于是驗(yàn)證了xshell和putty，以及高版本的SecureCRT是可以連接.
常見終端客戶端的介紹請戳鏈接: http://www.cnblogs.com/276815076/p/4409591.html 。
由于低版本 SecreCRT 不支持 AES-128-CBC 這個 Cipher，而 Linux 下用 ssh-keygen 生成的公鑰默認(rèn)采用這個 Cipher 的，于是對應(yīng)的私鑰可能會加載不了,所以登陸不上。
思考和學(xué)習(xí)
參考: http://blog.csdn.net/macrossdzh/article/details/5691924
一、什么是SSH
SSH是英文Secure Shell的簡寫形式。通過使用SSH，你可以把所有傳輸?shù)臄?shù)據(jù)進(jìn)行加密，這樣"中間人"這種攻擊方式就不可能實(shí)現(xiàn)了，而且也能夠防止DNS欺騙和IP欺騙。使用SSH，還有一個額外的好處就是傳輸?shù)臄?shù)據(jù)是經(jīng)過壓縮的，所以可以加快傳輸?shù)乃俣取SH有很多功能，它既可以代替Telnet，又可以為FTP、Pop、甚至為PPP提供一個安全的"通道"。
ssh工作原理簡易介紹:
服務(wù)器建立公鑰： 每一次啟動 sshd 服務(wù)時，該服務(wù)會主動去找 /etc/ssh/ssh_host* 的文件，若系統(tǒng)剛剛安裝完成時，由于沒有這些公鑰，因此 sshd 會主動去計算出這些需要的公鑰，同時也會計算出服務(wù)器自己需要的私鑰
客戶端主動聯(lián)機(jī)請求： 若客戶端想要聯(lián)機(jī)到 ssh 服務(wù)器，則需要使用適當(dāng)?shù)目蛻舳顺绦騺砺?lián)機(jī)，包括 ssh, putty 等客戶端程序連接
服務(wù)器傳送公鑰給客戶端： 接收到客戶端的要求后，服務(wù)器便將第一個步驟取得的公鑰傳送給客戶端使用 (此時應(yīng)是明碼傳送，反正公鑰本來就是給大家使用的)
客戶端記錄并比對服務(wù)器的公鑰數(shù)據(jù)及隨機(jī)計算自己的公私鑰： 若客戶端第一次連接到此服務(wù)器，則會將服務(wù)器的公鑰記錄到客戶端的用戶家目錄內(nèi)的 ~/.ssh/known_hosts 。若是已經(jīng)記錄過該服務(wù)器的公鑰，則客戶端會去比對此次接收到的與之前的記錄是否有差異。若接受此公鑰， 則開始計算客戶端自己的公私鑰
回傳客戶端的公鑰到服務(wù)器端： 用戶將自己的公鑰傳送給服務(wù)器。此時服務(wù)器：具有服務(wù)器的私鑰與客戶端的公鑰，而客戶端則是： 具有服務(wù)器的公鑰以及客戶端自己的私鑰，你會看到，在此次聯(lián)機(jī)的服務(wù)器與客戶端的密鑰系統(tǒng) (公鑰+私鑰) 并不一樣，所以才稱為非對稱加密系統(tǒng)
開始雙向加解密： (1)服務(wù)器到客戶端：服務(wù)器傳送數(shù)據(jù)時，拿用戶的公鑰加密后送出。客戶端接收后，用自己的私鑰解密 (2)客戶端到服務(wù)器：客戶端傳送數(shù)據(jù)時，拿服務(wù)器的公鑰加密后送出。服務(wù)器接收后，用服務(wù)器的私鑰解密，這樣就能保證通信安全
二、SSH 基本框架
SSH協(xié)議框架中最主要的部分是三個協(xié)議：
傳輸層協(xié)議（The Transport Layer Protocol）提供服務(wù)器認(rèn)證，數(shù)據(jù)機(jī)密性，信息完整性 等的支持；（TCP/IP的傳輸層-第3層）
用戶認(rèn)證協(xié)議（The User Authentication Protocol） 則為服務(wù)器提供客戶端的身份鑒別； （TCP/IP的應(yīng)用層-第4層）
連接協(xié)議（The Connection Protocol） 將加密的信息隧道復(fù)用成若干個邏輯通道，提供給更高層的應(yīng)用協(xié)議使用； 各種高層應(yīng)用協(xié)議可以相對地獨(dú)立于SSH基本體系之外，并依靠這個基本框架，通過連接協(xié)議使用SSH的安全機(jī)制。? （TCP/IP的應(yīng)用層-第4層）
同時SSH協(xié)議框架中還為許多高層的網(wǎng)絡(luò)安全應(yīng)用協(xié)議提供擴(kuò)展的支持。它們之間的層次關(guān)系可以用如下圖來表示：
三、主機(jī)密鑰機(jī)制
對于SSH這樣以提供安全通訊為目標(biāo)的協(xié)議，其中必不可少的就是一套完備的密鑰機(jī)制。由于SSH協(xié)議是面向互聯(lián)網(wǎng)網(wǎng)絡(luò)中主機(jī)之間的互訪與信息交換，所以主機(jī)密鑰成為基本的密鑰機(jī)制。也就是說，SSH協(xié)議要求每一個使用本協(xié)議的主機(jī)都必須至少有一個自己的主機(jī)密鑰對，服務(wù)方通過對客戶方主機(jī)密鑰的認(rèn)證之后，才能允許其連接請求。一個主機(jī)可以使用多個密鑰，針對不同的密鑰算法而擁有不同的密鑰，但是至少有一種是必備的，即通過 DSS算法產(chǎn)生的密鑰。關(guān)于DSS算法，請參考[FIPS-186]。
SSH協(xié)議關(guān)于主機(jī)密鑰認(rèn)證的管理方案有兩種，如下圖所示：
每一個主機(jī)都必須有自己的主機(jī)密鑰，密鑰可以有多對，每一對主機(jī)密鑰對包括公開密鑰和私有密鑰。在實(shí)際應(yīng)用過程中怎樣使用這些密鑰，并依賴它們來實(shí)現(xiàn)安全特性呢？如上圖所示，SSH協(xié)議框架中提出了兩種方案。
在第一種方案中，主機(jī)將自己的公用密鑰分發(fā)給相關(guān)的客戶機(jī)，客戶機(jī)在訪問主機(jī)時則使用該主機(jī)的公開密鑰來加密數(shù)據(jù)，主機(jī)則使用自己的私有密鑰來解密數(shù)據(jù)，從而實(shí)現(xiàn)主機(jī)密鑰認(rèn)證，確定客戶機(jī)的可靠身份。在圖2（a）中可以看到，用戶從主機(jī)A上發(fā)起操作，去訪問，主機(jī)B和主機(jī)C，此時，A成為客戶機(jī)，它必須事先配置主機(jī)B和主機(jī)C的公開密鑰，在訪問的時候根據(jù)主機(jī)名來查找相應(yīng)的公開密鑰。對于被訪問主機(jī)（也就是服務(wù)器端）來說則只要保證安全地存儲自己的私有密鑰就可以了。
在第二種方案中，存在一個密鑰認(rèn)證中心，所有系統(tǒng)中提供服務(wù)的主機(jī)都將自己的公開密鑰提交給認(rèn)證中心，而任何作為客戶機(jī)的主機(jī)則只要保存一份認(rèn)證中心的公開 密鑰就可以了。在這種模式下，客戶機(jī)在訪問服務(wù)器主機(jī)之前，還必須向密鑰認(rèn)證中心請求認(rèn)證，認(rèn)證之后才能夠正確地連接到目的主機(jī)上。
很 顯然，第一種方式比較容易實(shí)現(xiàn)，但是客戶機(jī)關(guān)于密鑰的維護(hù)卻是個麻煩事，因?yàn)槊看巫兏急仨氃诳蛻魴C(jī)上有所體現(xiàn)；第二種方式比較完美地解決管理維護(hù)問題， 然而這樣的模式對認(rèn)證中心的要求很高，在互聯(lián)網(wǎng)絡(luò)上要實(shí)現(xiàn)這樣的集中認(rèn)證，單單是權(quán)威機(jī)構(gòu)的確定就是個大麻煩，有誰能夠什么都能說了算呢？但是從長遠(yuǎn)的發(fā) 展來看，在企業(yè)應(yīng)用和商業(yè)應(yīng)用領(lǐng)域，采用中心認(rèn)證的方案是必要的。
另外，SSH協(xié)議框架中還允許對主機(jī)密鑰的一個折中處理，那就是首次訪問免認(rèn)證。首次訪問免認(rèn)證是指，在某客戶機(jī)第一次訪問主機(jī)時，主機(jī)不檢查主機(jī)密鑰，而向該客戶都發(fā)放一個公開密鑰的拷貝，這樣在以后的訪問中則必須使用該密鑰，否則會被認(rèn)為非法而拒絕其訪問。
四、SSH 的工作過程
在整個通訊過程中，為實(shí)現(xiàn) SSH的安全連接，服務(wù)器端與客戶端要經(jīng)歷如下五個階段：
版本號協(xié)商階段，SSH目前包括 SSH1和SSH2兩個版本， 雙方通過版本協(xié)商確定使用的版本
密鑰和算法協(xié)商階段，SSH支持多種加密算法， 雙方根據(jù)本端和對端支持的算法，協(xié)商出最終使用的算法
認(rèn)證階段，SSH客戶端向服務(wù)器端發(fā)起認(rèn)證請求， 服務(wù)器端對客戶端進(jìn)行認(rèn)證
會話請求階段， 認(rèn)證通過后，客戶端向服務(wù)器端發(fā)送會話請求
?交互會話階段 ，會話請求通過后，服務(wù)器端和客戶端進(jìn)行信息的交互
版本號協(xié)商階段
? 服務(wù)器打開端口 22，等待客戶端連接。
? 客戶端向服務(wù)器端發(fā)起 TCP初始連接請求，TCP連接建立后，服務(wù)器向客戶端發(fā)送第一個報文，包括版本標(biāo)志字符串，格式為“SSH－<主協(xié)議版本號>.<次協(xié)議版本號>－<軟件版本號>”，協(xié)議版本號由主版本號和次版本號組成，軟件版本號主要是為調(diào)試使用。
客戶端收到報文后，解析該數(shù)據(jù)包，如果服務(wù)器端的協(xié)議版本號比自己的低，且客戶端能支持服務(wù)器端的低版本，就使用服務(wù)器端的低版本協(xié)議號，否則使用自己的協(xié)議版本號。
?客戶端回應(yīng)服務(wù)器一個報文，包含了客戶端決定使用的協(xié)議版本號。服務(wù)器比較客戶端發(fā)來的版本號，決定是否能同客戶端一起工作。
?如果協(xié)商成功，則進(jìn)入密鑰和算法協(xié)商階段，否則服務(wù)器端斷開 TCP連接。
Note： 版本號協(xié)商階段報文都是采用明文方式傳輸?shù)摹?br />
密鑰和算法協(xié)商階段
服務(wù)器端和客戶端分別發(fā)送算法協(xié)商報文給對端，報文中包含自己支持的公鑰算法列表、加密算法列表、MAC（Message Authentication Code，消息驗(yàn)證碼）算法列表、壓縮算法列表等;
服務(wù)器端和客戶端根據(jù)對端和本端支持的算法列表得出最終使用的算法。
服務(wù)器端和客戶端利用 DH交換（Diffie-Hellman Exchange）算法、主機(jī)密鑰對等參數(shù)，生成會話密鑰和會話 ID。
??? ?
通過以上步驟，服務(wù)器端和客戶端就取得了相同的會話密鑰和會話ID。
??????? ?
對于后續(xù)傳輸?shù)臄?shù)據(jù)，兩端都會使用會話密鑰進(jìn)行加密和解密，保證了數(shù)據(jù)傳送的安全
在認(rèn)證階段，兩端會使用會話 ID用于認(rèn)證過程。
??? ?
Note：在協(xié)商階段之前，服務(wù)器端已經(jīng)生成 RSA或 DSA密鑰對，他們主要用于參與會話密鑰的生成。
認(rèn)證階段
?客戶端向服務(wù)器端發(fā)送認(rèn)證請求，認(rèn)證請求中包含用戶名、認(rèn)證方法、與該認(rèn)證方法相關(guān)的內(nèi)容（如：password認(rèn)證時，內(nèi)容為密文）。
服務(wù)器端對客戶端進(jìn)行認(rèn)證，如果認(rèn)證失敗，則向客戶端發(fā)送認(rèn)證失敗消息，其中包含可以再次認(rèn)證的方法列表。
客戶端從認(rèn)證方法列表中選取一種認(rèn)證方法再次進(jìn)行認(rèn)證。
該過程反復(fù)進(jìn)行， 直到認(rèn)證成功或者認(rèn)證次數(shù)達(dá)到上限， 服務(wù)器關(guān)閉連接為止。
SSH提供兩種認(rèn)證方式：
password認(rèn)證：客戶端向服務(wù)器發(fā)出 password認(rèn)證請求，將用戶名和密碼加密后發(fā)送給服務(wù)器；服務(wù)器將該信息解密后得到用戶名和密碼的明文，與設(shè)備上保存的用戶名和密碼進(jìn)行比較，并返回認(rèn)證成功或失敗的消息。
publickey 認(rèn)證：采用數(shù)字簽名的方法來認(rèn)證客戶端。目前，設(shè)備上可以利用RSA和 DSA兩種公共密鑰算法實(shí)現(xiàn)數(shù)字簽名。客戶端發(fā)送包含用戶名、公共密鑰和公共密鑰算法的 publickey 認(rèn)證請求給服務(wù)器端。服務(wù)器對公鑰進(jìn)行合法性檢查，如果不合法，則直接發(fā)送失敗消息；否則，服務(wù)器利用數(shù)字簽名對客戶端進(jìn)行認(rèn)證，并返回認(rèn)證成功或失敗的消息
SSH2.0還提供了 password-publickey 認(rèn)證和 any 認(rèn)證:
password-publickey 認(rèn)證：指定該用戶的認(rèn)證方式為 password 和 publickey認(rèn)證同時滿足。客戶端版本為 SSH1的用戶只要通過其中一種認(rèn)證即可登錄；客戶端版本為 SSH2的用戶必須兩種認(rèn)證都通過才能登錄。
any認(rèn)證：指定該用戶的認(rèn)證方式可以是 password，也可以是 publickey。
會話請求階段
服務(wù)器等待客戶端的請求；
認(rèn)證通過后，客戶端向服務(wù)器發(fā)送會話請求；
服務(wù)器處理客戶端的請求。請求被成功處理后， 服務(wù)器會向客戶端回應(yīng) SSH_SMSG_SUCCESS包，SSH進(jìn)入交互會話階段；否則回應(yīng) SSH_SMSG_FAILURE包，表示服務(wù)器處理請求失敗或者不能識別請求。
交互會話階段
在這個模式下，數(shù)據(jù)被雙向傳送：
客戶端將要執(zhí)行的命令加密后傳給服務(wù)器;
服務(wù)器接收到報文，解密后執(zhí)行該命令,將執(zhí)行的結(jié)果加密發(fā)還給客戶端;
客戶端將接收到的結(jié)果解密后顯示到終端上.
五、SSH的應(yīng)用
首先，SSH最常見的應(yīng)用就是，用它來取代傳統(tǒng)的Telnet、FTP等網(wǎng)絡(luò)應(yīng)用程序，通過SSH登錄到遠(yuǎn)方機(jī)器執(zhí)行你想進(jìn)行的工作與命令。在不安全的網(wǎng)路通訊環(huán)境中，它提供了很強(qiáng)的驗(yàn)證（authentication）機(jī)制與非常安全的通訊環(huán)境。實(shí)際上，SSH開發(fā)者的原意是設(shè)計它來取代原UNIX系統(tǒng)上的rcp、rlogin、rsh等指令程序的；但經(jīng)過適當(dāng)包裝后，發(fā)現(xiàn)它在功能上完全可以取代傳統(tǒng)的Telnet、FTP等應(yīng)用程序。
傳統(tǒng) BSD 風(fēng)格的 r 系列指令（如 rcp，rsh，rlogin）往往都被視為不安全的，很容易就被各種網(wǎng)絡(luò)攻擊手段所破解，幾乎所有找得到有關(guān)UNIX安全的書或文件，都會一而再、再而三地警告系統(tǒng)管理者，留心r系列指令的設(shè)定，甚至要求系統(tǒng)管理者將r系列指令通通關(guān)閉。
而用來替代r系列指令的SSH，則在安全方面做了極大的強(qiáng)化，不但對通訊內(nèi)容可以進(jìn)行極為安全的加密保護(hù)，同時也強(qiáng)化了對身份驗(yàn)證的安全機(jī)制，它應(yīng)用了在密碼學(xué)（Cryptography）中已發(fā)展出來的數(shù)種安全加密機(jī)制，如 Symmetric Key Cryptography，Asymmetric Key Cryptography， One-way Hash Function，Random-number Generation等，來加強(qiáng)對于身份驗(yàn)證與通訊內(nèi)容的安全保護(hù)。通訊時資料的加密有IDEA，three-key triple DES，DES，RC4-128，TSS，Blowfish 等數(shù)種多種安全加密算法可供選擇，加密的key則是通過 RSA 進(jìn)行交換的。資料的加密可以對抗IP spoofing，RSA這種非對稱性的加密機(jī)制則可用來對抗DNS spoofing與IP routing spoofing，同時RSA也可以進(jìn)行對主機(jī)身份的驗(yàn)證。
其次，通過使用用SSH可以在本地主機(jī)和遠(yuǎn)程服務(wù)器之間設(shè)置"加密通道"，并且這樣設(shè)置的"加密通道"可以跟常見的Pop應(yīng)用程序、X應(yīng)用程序、Linuxconf應(yīng)用程序相結(jié)合，提供安全保障。
SSH的"加密通道"是通過"端口轉(zhuǎn)發(fā)"來實(shí)現(xiàn)的。你可以在本地端口（沒有用到的）和在遠(yuǎn)程服務(wù)器上運(yùn)行的某個服務(wù)的端口之間建立"加密通道"。然后只要連接到本地端口。所有對本地端口的請求都被SSH加密并且轉(zhuǎn)發(fā)到遠(yuǎn)程服務(wù)器的端口。當(dāng)然只有遠(yuǎn)程服務(wù)器上運(yùn)行SSH服務(wù)器軟件的時候"加密通道"才能工作。
六、SSH Q&A
Q1: SSH的版本和區(qū)別。
SSH2避免了RSA的專利問題，并修補(bǔ)了CRC的缺陷。SSH2用數(shù)字簽名算法（DSA）和Diffie-Hellman（DH）算法代替RSA來完成對稱密鑰的交換，用HMAC來代替CRC。同時SSH2增加了AES和Twofish等對稱加密算法。
A1: SSH(Secure SHell)到目前為止有兩個不兼容的版本——SSH1和SSH2。SSH1又分為1.3和1.5兩個版本。SSH1采用DES、3DES、 Blowfish和RC4等對稱加密算法保護(hù)數(shù)據(jù)安全傳輸，而對稱加密算法的密鑰是通過非對稱加密算法（RSA）來完成交換的。SSH1使用循環(huán)冗余校驗(yàn)碼（CRC）來保證數(shù)據(jù)的完整性，但是后來發(fā)現(xiàn)這種方法有缺陷。
更多內(nèi)容請參考The SSHv1 Protocol & The SSHv2 Protocol
Q2: 什么是HMAC？
A2: HMAC(Hash Message Authentication Code) ，散列消息鑒別碼，基于密鑰的Hash算法的認(rèn)證協(xié)議。消息鑒別碼實(shí)現(xiàn)鑒別的原理是，用公開函數(shù)和密鑰產(chǎn)生一個固定長度的值作為認(rèn)證標(biāo)識，用這個標(biāo)識鑒別消息的完整性。使用一個密鑰生成一個固定大小的小數(shù)據(jù)塊，即MAC，并將其加入到消息中，然后傳輸。接收方利用與發(fā)送方共享的密鑰進(jìn)行鑒別認(rèn)證等。
Q3: 什么是X11 forwarding？
?A3: ssh的X11 forwarding特性可以使X client和X server安全地通訊。使用X11 forwarding后，從X client到X Server方向的數(shù)據(jù)先被送至ssh server，ssh server利用和ssh client的安全通道轉(zhuǎn)發(fā)給ssh client，再由ssh client轉(zhuǎn)發(fā)給X server，從X server到X client的數(shù)據(jù)流同理。這里ssh server和ssh client充當(dāng)了X client和X server間數(shù)據(jù)的轉(zhuǎn)發(fā)器，由于ssh server和X client、ssh client和X server一般在同一臺機(jī)器上，它們之間是一種安全的進(jìn)程間通訊，而ssh server和ssh client間的通訊也是安全的，所以X client和X server間的通訊就是安全的。
?
Q4: 什么是TTY？
A4: 終端是一種字符型設(shè)備，它有多種類型，通常使用tty來簡稱各種類型的終端設(shè)備。tty是 Teletype的縮寫。Teletype是最早出現(xiàn)的一種終端設(shè)備，很象電傳打字機(jī)，是由Teletype公司生產(chǎn)的。設(shè)備名放在特殊文件目錄/dev/下。
Q5: 簡單描述下SSH運(yùn)行的過程？
A5:簡要過程如下：
Client端向Server端發(fā)起SSH連接請求。
Server端向Client端發(fā)起版本協(xié)商。
協(xié)商結(jié)束后Server端發(fā)送Host Key公鑰 Server Key公鑰，隨機(jī)數(shù)等信息。到這里所有通信是不加密的。
Client端返回確認(rèn)信息，同時附帶用公鑰加密過的一個隨機(jī)數(shù)，用于雙方計算Session Key。
進(jìn)入認(rèn)證階段。從此以后所有通信均加密。
認(rèn)證成功后，進(jìn)入交互階段。
補(bǔ)充:
sshd 配置文件詳解
vim /etc/ssh/sshd_config
#1. SSH Server 全局設(shè)定，port ,協(xié)議 ……
# Port 22? #默認(rèn)端口，也可以使用多個端口
Protocol 2 #協(xié)議版本號
# ListenAddress 0.0.0.0 #默認(rèn)值是監(jiān)聽所有接口的 SSH 要求
# PidFile /var/run/sshd.pid #放置 SSHD 這個 PID 的文件
# LoginGraceTime 2m #2分鐘之內(nèi)不輸入密碼，自動斷開
# Compression delayed? #使用壓縮數(shù)據(jù)模式進(jìn)行傳輸，登入后才將數(shù)據(jù)壓縮 (delayed)
#2. 主要私有Key 存放文件
# HostKey /etc/ssh/ssh_host_key # SSH version 1 使用的私鑰
# HostKey /etc/ssh/ssh_host_rsa_key # SSH version 2 使用的 RSA 私鑰
# HostKey /etc/ssh/ssh_host_dsa_key # SSH version 2 使用的 DSA 私鑰
#3. 關(guān)于登錄文件的數(shù)據(jù)與daemon的名稱
SyslogFacility AUTHPRIV #記錄日志/var/log/secure
# LogLevel INFO #日志等級
#4. 安全設(shè)置
# PermitRootLogin yes #是否允許 root 登入
# StrictModes yes #是否讓 sshd 去檢查用戶家目錄或相關(guān)文件的權(quán)限數(shù)據(jù)
# PubkeyAuthentication yes #使用密鑰登錄系統(tǒng)
# AuthorizedKeysFile .ssh/authorized_keys #用戶登錄公鑰存放位置
PasswordAuthentication yes #登錄密碼認(rèn)證
# PermitEmptyPasswords no #否允許以空的密碼登入
# RhostsAuthentication no #系統(tǒng)不使用 .rhosts認(rèn)證
# IgnoreRhosts yes #是否取消使用 ~/.ssh/.rhosts 來做為認(rèn)證
# RhostsRSAAuthentication no #專門給 version 1 用的，使用 rhosts 文件在 /etc/hosts.equiv
# HostbasedAuthentication no #上面的項(xiàng)目類似，不過是給 version 2 使用的
# IgnoreUserKnownHosts no #是否忽略家目錄內(nèi)的 ~/.ssh/known_hosts
ChallengeResponseAuthentication no #允許任何的密碼認(rèn)證
UsePAM yes #利用 PAM 管理使用者認(rèn)證，可以記錄與管理
#5. 登錄后項(xiàng)目
# PrintMotd yes #登入后是否顯示出一些信息
# PrintLastLog yes #顯示上次登入的信息
# TCPKeepAlive yes #當(dāng)達(dá)成聯(lián)機(jī)后，服務(wù)器會一直傳送 TCP 封包給客戶端以判斷對方式否一直存在聯(lián)機(jī)
UsePrivilegeSeparation yes #是否權(quán)限較低的程序來提供用戶操作
MaxStartups 10 #同時允許幾個尚未登入的聯(lián)機(jī)畫面
DenyUsers * #設(shè)定受阻止的使用者名稱
DenyUsers test? #阻止用戶
DenyGroups test #阻止組
#6. SFTP 設(shè)定
Subsystem sftp /usr/lib/ssh/sftp-server
# UseDNS yes #為了要判斷客戶端來源是正常合法的，因此會使用 DNS 去反查客戶端的主機(jī)名，不過在內(nèi)網(wǎng)這項(xiàng)目設(shè)定為 no 會讓聯(lián)機(jī)達(dá)成速度比較快。
總結(jié)
以上是生活随笔為你收集整理的由SecureCRT引发的思考和学习的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Ubuntu 下mysql servic
- 下一篇： Docker入门与七牛kirk工具