《使用安全外殼 (SSH) 的互動和自動化訪問管理的安全性》筆記

    主機訪問其他主機，經常有很高的特權。不幸的是，對自動化和互動式機器對機器的訪問控制幾乎沒有規劃和監督。相反，此類訪問是由系統管理員、供應商和其他專案的一部分的整合人員臨時新增和配置的，而不需要 正規的訪問控制生命週期管理（例如，標準化的供應和終止過程、訪問令牌管理（例如，週期性密碼更改））。本出版物探討了基於SSH的訪問管理領域，重點討論了安全問題以及如何最好地解決這些問題。

    secureshell（SSH）是一種協議，用於安全地登入到遠端主機並在該主機上執行命令（例如，管理命令）。SSH協議與早期的遠端管理協議（如 telnet、remote shell（rsh）、remote login（rlogin）和remote copy（rcp））的區別在於，它內建了對健壯的安全特性的支援，如安全的使用者和裝置身份驗證以及傳輸加密。SSH幾乎完全取代了這些不安全的遠端管理協議

    SSH協議是典型的客戶機/伺服器體系結構。主機A上的SSH客戶端應用程式啟動到主機B上的SSH伺服器應用程式的連線。這兩個主機協商傳輸的加密演算法，然後為伺服器主機（主機B）2建立會話金鑰並執行裝置身份驗證，最後將 客戶端（或使用者）身份驗證憑據（例如使用者名稱和密碼）傳送到伺服器。假設此身份驗證成功，則可以說在主機之間建立了SSH連線，可以使用。

    SSH有三種常見的用例：

互動式 使用：SSH 用於遠端管理和配置Unix和Linux計算機、網路裝置以及各種其他型別的主機。 SSH還用於遠端執行應用程式（特別是基於文字的傳統應用程式）

檔案傳輸.SSH 作為安全複製（SCP）和安全檔案傳輸協議（SFTP）協議的基礎。 這些協議用於在主機之間傳輸檔案，同時利用SSH內建的安全功能。

點對點 隧道：SSH 可用於實現虛擬專用網（VPN）隧道，以保護兩臺主機之間傳輸的資料。 這些主機中的一個或兩個可能充當其後面其他主機的閘道器。

-> 1、伺服器認證（ 與 其它渠道獲得的預存在 known hosts中 的伺服器 公鑰進行一致性比較完成認證）

SSH的機密性和完整性依賴於SSH伺服器和客戶端的強身份驗證。客戶端對SSH伺服器的身份驗證是基於公鑰密碼系統使用（ SSH客戶端顯式信任的）公鑰（ public keys）或使用由證書頒發機構頒發的證書（certificates ） 完成認證——公鑰比證書更常用。

2.1、客戶機認證

    客戶端身份驗證是指對互動使用者（管理員和其他使用者）或在SSH客戶端上執行的自動化程式的身份驗證。對伺服器上的特定帳戶進行身份驗證。

    SSH協議支援多種使用者身份驗證機制，包括密碼、基於主機的身份驗證、Kerberos和公鑰身份驗證。全部這些認證方法基本上依賴於一些秘密資訊，當用於自動訪問時，此機密資訊必須儲存在本地或以其他易於訪問方式儲存。一個可以在每個SSH上啟用一個或多個客戶端身份驗證方法伺服器。每個身份驗證方法的優點和缺點是安全性和靈活性這些優點/缺點對於互動使用者和自動化使用者來說往往是不同的流程、組織必須仔細評估並選擇已批准在其環境中使用的客戶端身份驗證方法，禁用其他方法。本節簡要討論這些形式的客戶端身份驗證，重點討論它們對互動式使用者和自動化流程的相關性和適當性。

->2.2、密碼認證

    SSH中有兩種口令認證機制：基本口令認證和鍵盤互動認證。基本密碼驗證是SSH協議標準定義的傳統方法。鍵盤互動認證在大多數現代環境中使用。 LDAP 可以用來代替本地憑證資料庫（例如，密碼檔案）。透過密碼和鍵盤互動身份驗證，使用者名稱、密碼和質詢響應透過加密的SSH連線從客戶機（HostA）傳送到伺服器（HostB）。這可以保護透過網路傳輸的憑據，但它們仍然會受到中間人攻擊的影響。

1.User1發起登入到HostB

2.hostA使用儲存在User1的known hosts檔案中的HostB的公鑰金鑰 來認證HostB，並與HostB建立加密連線。

3.User1被提示輸入使用者名稱和密碼，以及HostB可能需要的其他憑據（用於鍵盤互動身份驗證）。

4.憑據使用 加密的連線被髮送到HostB 。 HostB使用User1提供的憑據來認證User1。

對於自動化過程，通常不建議使用密碼身份驗證，因為它不提供其他身份驗證方法（尤其是公鑰身份驗證）可用的訪問控制級別。

2.3、 基於主機的身份驗證

    基於主機的身份驗證使用伺服器主機（HostA）的host key( 公鑰， 主機金鑰用於驗證主機（機器）本身，而不是使用者或帳戶)——該秘鑰 通常由客戶端使用來驗證伺服器的身份——從而將該伺服器（HostA）驗證到另一個伺服器（HostB）上，併為客戶端伺服器（HostA）上的使用者（User1）的身份提供擔保。配置檔案（.shosts）可與目標伺服器（HostB）上的任何使用者帳戶一起使用，以指定哪些主機上的使用者可以登入到該帳戶而無需進一步驗證。

1.HostB的管理員將HostA的公鑰放入HostB上的knownhosts檔案，並配置shosts（例如~/.shosts或類似shosts)允許 主機A的使用者1進行身份驗證。

2.User1開始登入HostB.

3.HostA使用來自HostB中對應HostA的host key驗證HostB.

4.HostB確認在shosts配置中，User1有權從HostA訪問HostB上的目標帳戶。

    基於主機的身份驗證不允許對訪問時可以在目標伺服器上執行的操作配置命令限制。因此，不建議使用自動訪問主機-基於身份驗證不建議用於互動式使用者，因為它不提供互動式登入，這通常被認為是不好的做法，特別是對於具有提升許可權的帳戶 。

2.4、Kerberos身份驗證

    Kerberos（通常與基於LDAP的目錄（如Active directory）一起）在Windows域或Kerberos域中實現單點登入，一旦使用者使用Kerberos對帳戶進行了身份驗證，就可以登入到具有相同帳戶名且位於相同域（啟用Kerberos身份驗證）中的任何其他伺服器，而無需進一步的身份驗證。

Kerberos在身份驗證票證中包含使用者的IP地址，以確保攻擊者無法複製和重用這些票證系統。 為了方便自動化程式的身份驗證，許多SSH Kerberos實現提供了將憑據儲存在客戶機上名為keytab檔案的檔案中的選項。 這使得無需使用者干預即可自動登入。 Kerberos很少用於自動化程式，因此不建議使用Kerberos，因為它具有隱式訪問的風險，並且缺少命令限制。

-> 2.5、公鑰認證

    SSH中的公鑰驗證使用使用者金鑰或證書來驗證連線——其中使用者金鑰是最常用的方法。可以為互動式使用者和自動化程式配置這樣的金鑰，它們授權使用者或程式訪問資訊系統中的使用者帳戶系統互動SSH客戶端（HostA）上的使用者或自動程式有一個稱為身份金鑰 identity key的使用者金鑰（ User Key： authorized keys公鑰 或 identity keys私鑰），通常是RSA或DSA私鑰，並且伺服器（HostB）必須將相應的公鑰配置為 user Account的授權金鑰，以便提供對該帳戶的訪問。然後，任何擁有 identity key（ 在SSH協議中用於身份驗證的 私鑰 ；授予對相應公鑰已配置為授權金鑰的帳戶的訪問權）的使用者或程式都可以登入到伺服器上的該使用者帳戶，並在為該帳戶配置的許可權下執行操作。

1. User1或管理員為User1生成一個identity key私鑰（和相應的public key公鑰as an authorized key）。

2. HostB管理員將User1的公鑰作為授權金鑰 authorized key（ 一種 公鑰 ，被配置為授權任何能夠在SSH協議中使用相應私鑰（ identity key）的人訪問帳戶）儲存在HostB上的User1帳戶中。

3. User1開始登入HostB.

4. HostA連線到HostB，並使用user1的 identity key嘗試將 User1驗證到HostB（ HostA使用 identity key加密 User 1賬戶資訊併發給 HostB）

5. HostB 使用儲存在HostB上User1的帳戶中的 authorized key 授權金鑰（公鑰）認證User1。 （ HostB 使用 authorized key 解密由 identity key加密的 User 1 賬戶資訊得到User1賬戶資訊內容 ）

    公鑰認證的一個重要優點是它不建立隱式的信任關係，只建立明確定義的信任關係，並且可以透過檢查目標主機來可靠地確定允許的訪問。

Public Key Authentication using PuTTY and WinSCP：

https://www.jscape.com/blog/bid/38946/Public-Key-Authentication-using-PuTTY-and-WinSCP

https://blog.csdn.net/Noob_f/article/details/78944944（PuTTY金鑰認證）

WinSCP是一個支援SSH的SCP檔案傳輸軟體：

PS C:\windows\system32> choco install winscp        ——ok!

   winscp v5.17.9 [Approved]

   winscp package files install completed. Performing other installation steps.

   The install of winscp was successful.

   Software install location not explicitly set, could be in package or default install location if installer.

由於SSH的標準中，並沒有固定金鑰檔案的格式。而 Putty使用的私鑰格式和OpenSSH生成的有點不同。

2.6、使用者身份驗證摘要

3、基於SSH的訪問中的漏洞

4、管理建議做法

5、基於SSH的訪問管理規劃與實現

6、 解決方案規劃和部署

附錄：

Public and Private Key：

公鑰和私鑰是兩個非常大的數字（透過高等數學）具有獨特的關係，即 用一個數字（金鑰）加密的資訊只能用另一個數字（金鑰）解密， 反之亦然。為了利用這一特性進行安全操作，一旦在數學上選擇（生成）了兩個數字，一個是保密的（私鑰），另一個是共享的（公鑰）。然後，私鑰的持有者可以向擁有公鑰的另一方進行身份驗證。或者，一方可以使用公鑰向相應私鑰的持有者傳送機密訊息。對於SSH，身份金鑰是私鑰，授權金鑰是公鑰。

SSH Client：

允許使用者或自動程式遠端訪問SSH伺服器的軟體實現。SSH客戶機負責可靠地執行確保安全連線所需的所有操作，包括生成標識金鑰、提示使用者驗證主機金鑰、驗證和建立與SSH伺服器的加密連線、提示使用者提供憑據、執行公鑰驗證等。

SSH Server:

一種軟體實現，使SSH能夠從SSH客戶機訪問系統。SSH伺服器可以包含在作業系統或裝置中，也可以是附加軟體。SSH伺服器通常是一組複雜的軟體模組，負責執行大量任務，包括強制執行已配置的SSH設定、驗證使用者、限制對某些使用者和組的訪問、確保安全連線、與其他系統（如PAM和Kerberos）互動、執行檔案傳輸等。

Known Hosts File:

與包含一個或多個主機金鑰的特定帳戶關聯的檔案。 每個主機金鑰都與SSH伺服器地址（IP或主機名）相關聯，以便在啟動連線時對伺服器進行身份驗證。第一次連線到SSH伺服器的使用者或管理員負責驗證該伺服器提供的主機金鑰是否是實際金鑰（不是惡意金鑰），然後再將其放入已知的hosts檔案中。

Host Key:

一種 公鑰，用於在SSH協議中向希望與其通訊的主機驗證主機（每個主機通常也有自己的專用主機金鑰）。一些主機可能有多個主機金鑰（例如，每個演算法一個主機金鑰）。主機金鑰用於驗證主機（機器）本身，而不是使用者或帳戶，而身份金鑰和授權金鑰則與驗證使用者/帳戶以及授權訪問主機上的帳戶有關.

Authorized Key：

一種 公鑰，被配置為授權任何能夠在SSH協議中使用相應私鑰（身份金鑰）的人訪問帳戶。 授權金鑰可以配置有某些限制，最顯著的是強制命令（ Forced Command）和源限制（Source Restriction）。

Forced Command：

為授權金鑰配置的一種限制，在使用該金鑰登入時 阻止執行指定命令以外的命令。在一些SSH實現中，可以透過在 授權金鑰檔案中使用“command=”限制來配置強制命令。

Source Restriction：

為授權金鑰配置的一種限制，用於 限制使用該金鑰進行登入的IP地址或主機名。在一些SSH實現中，可以透過在授權金鑰檔案中使用“from=”限制來配置源限制。

Authorized Keys File：

與儲存一個或多個 Authorized Keys（授權金鑰）和可選 限制的特定帳戶相關聯的檔案。SSH伺服器上允許公鑰身份驗證的每個帳戶都有一個唯一的授權金鑰檔案。

Identity Key：

在SSH協議中用於身份驗證的 私鑰；授予對相應公鑰已配置為授權金鑰的帳戶的訪問權。

User Key（含 authorized keys公鑰 and identity keys私鑰）：

用於透過SSH協議授予對使用者帳戶的訪問許可權的金鑰（與主機金鑰相反，User Key不授予對任何內容的訪問許可權，而是用於驗證主機）。（授權金鑰和身份金鑰） authorized keys and identity keys都是使用者金鑰。使用者金鑰相當於訪問令牌。

Passphrase：

用於保護身份金鑰（identity key）的密碼。在使用者或管理員輸入密碼短語後，密碼短語將在數學上轉換為大數字，作為用於加密身份金鑰的金鑰。為了解密身份，必須再次輸入密碼短語，以便為解密重新生成相同的金鑰。