由SecureCRT引發的思考和學習

前言

由于業務需要，最近在云上新購買了一批centos7.0的服務器,用腳本批量添加了用戶（腳本請見我之前的博客/秘鑰認證用戶自動控制:http://my.oschina.net/pwd/blog/388254）,加完秘鑰之后發現,但是secureCRT 拋出了一下異常。

解決過程：

1.初步懷疑秘鑰有問題,通過命令行去探測是否可以連接,-> ssh -i 秘鑰文件 用戶名@主機 ，發現能正常連接，確認秘鑰是OK的。

2.可能出在secureCRT配置問題，具體操作不詳解了,主要是涉及客戶端一些可視化的設置,搗鼓完以后沒好。

3.根據以上報錯聯想，可能是這個secureCrt 不支持以上的加密算法，上面已經明確的提示了，于是驗證了xshell和putty，以及高版本的SecureCRT是可以連接.

常見終端客戶端的介紹請戳鏈接: http://www.cnblogs.com/276815076/p/4409591.html 

由于低版本 SecreCRT 不支持 AES-128-CBC 這個 Cipher，而 Linux 下用 ssh-keygen 生成的公鑰默認采用這個 Cipher 的，于是對應的私鑰可能會加載不了,所以登陸不上。

思考和學習

參考: http://blog.csdn.net/macrossdzh/article/details/5691924

一、什么是SSH

SSH是英文Secure Shell的簡寫形式。通過使用SSH，你可以把所有傳輸的數據進行加密，這樣"中間人"這種攻擊方式就不可能實現了，而且也能夠防止DNS欺騙和IP欺騙。使用SSH，還有一個額外的好處就是傳輸的數據是經過壓縮的，所以可以加快傳輸的速度。SSH有很多功能，它既可以代替Telnet，又可以為FTP、Pop、甚至為PPP提供一個安全的"通道"。

ssh工作原理簡易介紹:

• 服務器建立公鑰： 每一次啟動 sshd 服務時，該服務會主動去找 /etc/ssh/ssh_host* 的文件，若系統剛剛安裝完成時，由于沒有這些公鑰，因此 sshd 會主動去計算出這些需要的公鑰，同時也會計算出服務器自己需要的私鑰

• 客戶端主動聯機請求： 若客戶端想要聯機到 ssh 服務器，則需要使用適當的客戶端程序來聯機，包括 ssh, putty 等客戶端程序連接

• 服務器傳送公鑰給客戶端： 接收到客戶端的要求后，服務器便將第一個步驟取得的公鑰傳送給客戶端使用 (此時應是明碼傳送，反正公鑰本來就是給大家使用的)

• 客戶端記錄并比對服務器的公鑰數據及隨機計算自己的公私鑰： 若客戶端第一次連接到此服務器，則會將服務器的公鑰記錄到客戶端的用戶家目錄內的 ~/.ssh/known_hosts 。若是已經記錄過該服務器的公鑰，則客戶端會去比對此次接收到的與之前的記錄是否有差異。若接受此公鑰， 則開始計算客戶端自己的公私鑰

• 回傳客戶端的公鑰到服務器端： 用戶將自己的公鑰傳送給服務器。此時服務器：具有服務器的私鑰與客戶端的公鑰，而客戶端則是： 具有服務器的公鑰以及客戶端自己的私鑰，你會看到，在此次聯機的服務器與客戶端的密鑰系統 (公鑰+私鑰) 并不一樣，所以才稱為非對稱加密系統

• 開始雙向加解密： (1)服務器到客戶端：服務器傳送數據時，拿用戶的公鑰加密后送出。客戶端接收后，用自己的私鑰解密 (2)客戶端到服務器：客戶端傳送數據時，拿服務器的公鑰加密后送出。服務器接收后，用服務器的私鑰解密，這樣就能保證通信安全

二、SSH 基本框架

SSH協議框架中最主要的部分是三個協議：

* 傳輸層協議（The Transport Layer Protocol）提供服務器認證，數據機密性，信息完整性 等的支持；（TCP/IP的傳輸層-第3層）

* 用戶認證協議（The User Authentication Protocol） 則為服務器提供客戶端的身份鑒別； （TCP/IP的應用層-第4層）

* 連接協議（The Connection Protocol） 將加密的信息隧道復用成若干個邏輯通道，提供給更高層的應用協議使用； 各種高層應用協議可以相對地獨立于SSH基本體系之外，并依靠這個基本框架，通過連接協議使用SSH的安全機制。  （TCP/IP的應用層-第4層）

同時SSH協議框架中還為許多高層的網絡安全應用協議提供擴展的支持。它們之間的層次關系可以用如下圖來表示：

三、主機密鑰機制

對于SSH這樣以提供安全通訊為目標的協議，其中必不可少的就是一套完備的密鑰機制。由于SSH協議是面向互聯網網絡中主機之間的互訪與信息交換，所以主機密鑰成為基本的密鑰機制。也就是說，SSH協議要求每一個使用本協議的主機都必須至少有一個自己的主機密鑰對，服務方通過對客戶方主機密鑰的認證之后，才能允許其連接請求。一個主機可以使用多個密鑰，針對不同的密鑰算法而擁有不同的密鑰，但是至少有一種是必備的，即通過 DSS算法產生的密鑰。關于DSS算法，請參考[FIPS-186]。

SSH協議關于主機密鑰認證的管理方案有兩種，如下圖所示：

每一個主機都必須有自己的主機密鑰，密鑰可以有多對，每一對主機密鑰對包括公開密鑰和私有密鑰。在實際應用過程中怎樣使用這些密鑰，并依賴它們來實現安全特性呢？如上圖所示，SSH協議框架中提出了兩種方案。

在第一種方案中，主機將自己的公用密鑰分發給相關的客戶機，客戶機在訪問主機時則使用該主機的公開密鑰來加密數據，主機則使用自己的私有密鑰來解密數據，從而實現主機密鑰認證，確定客戶機的可靠身份。在圖2（a）中可以看到，用戶從主機A上發起操作，去訪問，主機B和主機C，此時，A成為客戶機，它必須事先配置主機B和主機C的公開密鑰，在訪問的時候根據主機名來查找相應的公開密鑰。對于被訪問主機（也就是服務器端）來說則只要保證安全地存儲自己的私有密鑰就可以了。

在 第二種方案中，存在一個密鑰認證中心，所有系統中提供服務的主機都將自己的公開密鑰提交給認證中心，而任何作為客戶機的主機則只要保存一份認證中心的公開 密鑰就可以了。在這種模式下，客戶機在訪問服務器主機之前，還必須向密鑰認證中心請求認證，認證之后才能夠正確地連接到目的主機上。

很 顯然，第一種方式比較容易實現，但是客戶機關于密鑰的維護卻是個麻煩事，因為每次變更都必須在客戶機上有所體現；第二種方式比較完美地解決管理維護問題， 然而這樣的模式對認證中心的要求很高，在互聯網絡上要實現這樣的集中認證，單單是權威機構的確定就是個大麻煩，有誰能夠什么都能說了算呢？但是從長遠的發 展來看，在企業應用和商業應用領域，采用中心認證的方案是必要的。

另外，SSH協議框架中還允許對主機密鑰的一個折中處理，那就是首次訪問免認證。首次訪問免認證是指，在某客戶機第一次訪問主機時，主機不檢查主機密鑰，而向該客戶都發放一個公開密鑰的拷貝，這樣在以后的訪問中則必須使用該密鑰，否則會被認為非法而拒絕其訪問。

四、SSH 的工作過程

在整個通訊過程中，為實現 SSH的安全連接，服務器端與客戶端要經歷如下五個階段：

    * 版本號協商階段，SSH目前包括 SSH1和SSH2兩個版本， 雙方通過版本協商確定使用的版本

    * 密鑰和算法協商階段，SSH支持多種加密算法， 雙方根據本端和對端支持的算法，協商出最終使用的算法

    * 認證階段，SSH客戶端向服務器端發起認證請求， 服務器端對客戶端進行認證

    * 會話請求階段， 認證通過后，客戶端向服務器端發送會話請求

    * 交互會話階段 ，會話請求通過后，服務器端和客戶端進行信息的交互

1 . 版本號協商階段

   1. 服務器打開端口 22，等待客戶端連接。

   2. 客戶端向服務器端發起 TCP初始連接請求，TCP連接建立后，服務器向客戶端發送第一個報文，包括版本標志字符串，格式為“SSH－<主協議版本號>.<次協議版本號>－<軟件版本號>”，協議版本號由主版本號和次版本號組成，軟件版本號主要是為調試使用。

   3. 客戶端收到報文后，解析該數據包，如果服務器端的協議版本號比自己的低，且客戶端能支持服務器端的低版本，就使用服務器端的低版本協議號，否則使用自己的協議版本號。

   4. 客戶端回應服務器一個報文，包含了客戶端決定使用的協議版本號。服務器比較客戶端發來的版本號，決定是否能同客戶端一起工作。

   5. 如果協商成功，則進入密鑰和算法協商階段，否則服務器端斷開 TCP連接。

Note： 版本號協商階段報文都是采用明文方式傳輸的。

2. 密鑰和算法協商階段

   1. 服務器端和客戶端分別發送算法協商報文給對端，報文中包含自己支持的公鑰算法列表、加密算法列表、MAC（Message Authentication Code，消息驗證碼）算法列表、壓縮算法列表等;

   2. 服務器端和客戶端根據對端和本端支持的算法列表得出最終使用的算法。

   3. 服務器端和客戶端利用 DH交換（Diffie-Hellman Exchange）算法、主機密鑰對等參數，生成會話密鑰和會話 ID。

      通過以上步驟，服務器端和客戶端就取得了相同的會話密鑰和會話ID。

          * 對于后續傳輸的數據，兩端都會使用會話密鑰進行加密和解密，保證了數據傳送的安全

          * 在認證階段，兩端會使用會話 ID用于認證過程。

      Note：

             在協商階段之前，服務器端已經生成 RSA或 DSA密鑰對，他們主要用于參與會話密鑰的生成。

3. 認證階段

   1. 客戶端向服務器端發送認證請求，認證請求中包含用戶名、認證方法、與該認證方法相關的內容（如：password認證時，內容為密碼）。

   2. 服務器端對客戶端進行認證，如果認證失敗，則向客戶端發送認證失敗消息，其中包含可以再次認證的方法列表。

   3. 客戶端從認證方法列表中選取一種認證方法再次進行認證。

   4. 該過程反復進行， 直到認證成功或者認證次數達到上限， 服務器關閉連接為止。

SSH提供兩種認證方式：

   1. password認證：客戶端向服務器發出 password認證請求，將用戶名和密碼加密后發送給服務器；服務器將該信息解密后得到用戶名和密碼的明文，與設備上保存的用戶名和密碼進行比較，并返回認證成功或失敗的消息。

   2. publickey 認證：采用數字簽名的方法來認證客戶端。目前，設備上可以利用RSA和 DSA兩種公共密鑰算法實現數字簽名。客戶端發送包含用戶名、公共密鑰和公共密鑰算法的 publickey 認證請求給服務器端。服務器對公鑰進行合法性檢查，如果不合法，則直接發送失敗消息；否則，服務器利用數字簽名對客戶端進行認證，并返回認證成功或失敗的消息

SSH2.0還提供了 password-publickey 認證和 any 認證:

   1. password-publickey 認證：指定該用戶的認證方式為 password 和 publickey認證同時滿足。客戶端版本為 SSH1的用戶只要通過其中一種認證即可登錄；客戶端版本為 SSH2的用戶必須兩種認證都通過才能登錄。

   2. any認證：指定該用戶的認證方式可以是 password，也可以是 publickey。

4.會話請求階段

   1. 服務器等待客戶端的請求；

   2. 認證通過后，客戶端向服務器發送會話請求；

   3. 服務器處理客戶端的請求。請求被成功處理后， 服務器會向客戶端回應 SSH_SMSG_SUCCESS包，SSH進入交互會話階段；否則回應 SSH_SMSG_FAILURE包，表示服務器處理請求失敗或者不能識別請求。

5.交互會話階段

在這個模式下，數據被雙向傳送：

   1. 客戶端將要執行的命令加密后傳給服務器;

   2. 服務器接收到報文，解密后執行該命令,將執行的結果加密發還給客戶端;

   3. 客戶端將接收到的結果解密后顯示到終端上.

五、SSH的應用

首先，SSH最常見的應用就是，用它來取代傳統的Telnet、FTP等網絡應用程序，通過SSH登錄到遠方機器執行你想進行的工作與命令。在不安全的網路通訊環境中，它提供了很強的驗證（authentication）機制與非常安全的通訊環境。實際上，SSH開發者的原意是設計它來取代原UNIX系統上的rcp、rlogin、rsh等指令程序的；但經過適當包裝后，發現它在功能上完全可以取代傳統的Telnet、FTP等應用程序。

傳統 BSD 風格的 r 系列指令（如 rcp，rsh，rlogin）往往都被視為不安全的，很容易就被各種網絡攻擊手段所破解，幾乎所有找得到有關UNIX安全的書或文件，都會一而再、再而三地警告系統管理者，留心r系列指令的設定，甚至要求系統管理者將r系列指令通通關閉。

而用來替代r系列指令的SSH，則在安全方面做了極大的強化，不但對通訊內容可以進行極為安全的加密保護，同時也強化了對身份驗證的安全機制，它應用了在密碼學（Cryptography）中已發展出來的數種安全加密機制，如 Symmetric Key Cryptography，Asymmetric Key Cryptography， One-way Hash Function，Random-number Generation等，來加強對于身份驗證與通訊內容的安全保護。通訊時資料的加密有IDEA，three-key triple DES，DES，RC4-128，TSS，Blowfish 等數種多種安全加密算法可供選擇，加密的key則是通過 RSA 進行交換的。資料的加密可以對抗IP spoofing，RSA這種非對稱性的加密機制則可用來對抗DNS spoofing與IP routing spoofing，同時RSA也可以進行對主機身份的驗證。

其次，通過使用用SSH可以在本地主機和遠程服務器之間設置"加密通道"，并且這樣設置的"加密通道"可以跟常見的Pop應用程序、X應用程序、Linuxconf應用程序相結合，提供安全保障。

SSH的"加密通道"是通過"端口轉發"來實現的。你可以在本地端口（沒有用到的）和在遠程服務器上運行的某個服務的端口之間建立"加密通道"。然后只要連接到本地端口。所有對本地端口的請求都被SSH加密并且轉發到遠程服務器的端口。當然只有遠程服務器上運行SSH服務器軟件的時候"加密通道"才能工作。

六、SSH Q&A

    Q1: SSH的版本和區別。

    SSH2避免了RSA的專利問題，并修補了CRC的缺陷。SSH2用數字簽名算法（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等對稱加密算法保護數據安全傳輸，而對稱加密算法的密鑰是通過非對稱加密算法（RSA）來完成交換的。SSH1使用循環冗余校驗碼（CRC）來保證數據的完整性，但是后來發現這種方法有缺陷。

    更多內容請參考The SSHv1 Protocol & The SSHv2 Protocol

     Q2: 什么是HMAC？

    A2: HMAC(Hash Message Authentication Code) ，散列消息鑒別碼，基于密鑰的Hash算法的認證協議。消息鑒別碼實現鑒別的原理是，用公開函數和密鑰產生一個固定長度的值作為認證標識，用這個標識鑒別消息的完整性。使用一個密鑰生成一個固定大小的小數據塊，即MAC，并將其加入到消息中，然后傳輸。接收方利用與發送方共享的密鑰進行鑒別認證等。

    Q3: 什么是X11 forwarding？

    A3: sh的X11 forwarding特性可以使X client和X server安全地通訊。使用X11 forwarding后，從X client到X Server方向的數據先被送至ssh server，ssh server利用和ssh client的安全通道轉發給ssh client，再由ssh client轉發給X server，從X server到X client的數據流同理。這里ssh server和ssh client充當了X client和X server間數據的轉發器，由于ssh server和X client、ssh client和X server一般在同一臺機器上，它們之間是一種安全的進程間通訊，而ssh server和ssh client間的通訊也是安全的，所以X client和X server間的通訊就是安全的。

    Q4: 什么是TTY？

    A4: 終端是一種字符型設備，它有多種類型，通常使用tty來簡稱各種類型的終端設備。tty是 Teletype的縮寫。Teletype是最早出現的一種終端設備，很象電傳打字機，是由Teletype公司生產的。設備名放在特殊文件目錄/dev/下。

    Q5: 簡單描述下SSH運行的過程？

    A5:簡要過程如下：

        * Client端向Server端發起SSH連接請求。

        * Server端向Client端發起版本協商。

        * 協商結束后Server端發送Host Key公鑰 Server Key公鑰，隨機數等信息。到這里所有通信是不加密的。

        * Client端返回確認信息，同時附帶用公鑰加密過的一個隨機數，用于雙方計算Session Key。

        * 進入認證階段。從此以后所有通信均加密。

        * 認證成功后，進入交互階段。

補充:

sshd 配置文件詳解

vim /etc/ssh/sshd_config

#1. SSH Server 全局設定，port ,協議 ……

• # Port 22  #默認端口，也可以使用多個端口

• Protocol 2 #協議版本號

• # ListenAddress 0.0.0.0 #默認值是監聽所有接口的 SSH 要求

• # PidFile /var/run/sshd.pid #放置 SSHD 這個 PID 的文件

• # LoginGraceTime 2m #2分鐘之內不輸入密碼，自動斷開

• # Compression delayed  #使用壓縮數據模式進行傳輸，登入后才將數據壓縮 (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. 關于登錄文件的數據與daemon的名稱

• SyslogFacility AUTHPRIV #記錄日志/var/log/secure

• # LogLevel INFO #日志等級

#4. 安全設置

• # PermitRootLogin yes #是否允許 root 登入

• # StrictModes yes #是否讓 sshd 去檢查用戶家目錄或相關文件的權限數據

• # PubkeyAuthentication yes #使用密鑰登錄系統

• # AuthorizedKeysFile .ssh/authorized_keys #用戶登錄公鑰存放位置

• PasswordAuthentication yes #登錄密碼認證

• # PermitEmptyPasswords no #否允許以空的密碼登入

• # RhostsAuthentication no #系統不使用 .rhosts認證

• # IgnoreRhosts yes #是否取消使用 ~/.ssh/.rhosts 來做為認證

• # RhostsRSAAuthentication no #專門給 version 1 用的，使用 rhosts 文件在 /etc/hosts.equiv

• # HostbasedAuthentication no #上面的項目類似，不過是給 version 2 使用的

• # IgnoreUserKnownHosts no #是否忽略家目錄內的 ~/.ssh/known_hosts

• ChallengeResponseAuthentication no #允許任何的密碼認證

• UsePAM yes #利用 PAM 管理使用者認證，可以記錄與管理

#5. 登錄后項目

• # PrintMotd yes #登入后是否顯示出一些信息

• # PrintLastLog yes #顯示上次登入的信息

• # TCPKeepAlive yes #當達成聯機后，服務器會一直傳送 TCP 封包給客戶端以判斷對方式否一直存在聯機

• UsePrivilegeSeparation yes #是否權限較低的程序來提供用戶操作

• MaxStartups 10 #同時允許幾個尚未登入的聯機畫面

• DenyUsers * #設定受阻止的使用者名稱

• DenyUsers test  #阻止用戶

• DenyGroups test #阻止組

#6. SFTP 設定

• Subsystem sftp /usr/lib/ssh/sftp-server

• # UseDNS yes #為了要判斷客戶端來源是正常合法的，因此會使用 DNS 去反查客戶端的主機名，不過在內網這項目設定為 no 會讓聯機達成速度比較快

來自： http://my.oschina.net/pwd/blog/599071