Elastic Compute Service：通過SSH無法遠程登入Linux執行個體的排查指引

免責聲明： 本文檔可能包含第三方產品資訊，該資訊僅供參考。阿里雲對第三方產品的效能、可靠性以及操作可能帶來的潛在影響，不做任何暗示或其他形式的承諾。

概述

本文主要介紹通過SSH無法遠程登入Linux執行個體的排查指引。

詳細資料

提示：

• 以下操作在CentOS 6.5 64位作業系統中進行過測試，在其他Linux發行版中可能存在差異，具體情況請參閱對應Linux發行版的官方文檔。
• 用戶端SSH串連Linux執行個體是營運操作的主要途徑。通過管理終端可以用於臨時營運操作，或者在用戶端SSH登入異常時，用於問題排查和分析。

下圖為SSH登入關聯因素示意圖。

由此可見，通過SSH無法遠程登入Linux執行個體時，可能涉及的關聯因素較多，本文分別對其進行介紹，內容目錄如下。

• 用戶端
• 中間網路
• PAM安全架構
• Linux系統內容配置
• SSH服務及參數配置
• SSH服務關聯目錄或檔案配置
• SSH服務密鑰配置

用戶端

用戶端無法正常登入時，先使用不同的SSH用戶端基於相同賬戶資訊進行登入測試。如果能正常登入，則判斷是用戶端配置問題，需要對用戶端配置或軟體運行情況做排查分析。關於如何使用用戶端SSH登入Linux執行個體，您可以參考遠端連線Linux執行個體。

中間網路

用戶端無法正常通過SSH串連Linux執行個體時，參考如下命令，進行連接埠測試，判斷是否存在中間網路異常。

telnet [$IP] [$Port]

註：

• [$IP]指Linux執行個體的IP地址。
• [$Port]指Linux執行個體的SSH連接埠號碼。

比如執行telnet 192.168.0.1 22命令，正常情況下，系統會返回服務端中SSH的軟體版本號碼，類似如下圖。

如果連接埠測試失敗，參閱下列文檔，對用戶端到伺服器之間的網路做進一步的排查分析。

• ping丟包或不通時鏈路測試說明
• 能ping通但連接埠不通時連接埠可用性探測說明
• 網路異常時抓包操作說明

PAM安全架構

Linux系統的PAM安全架構可以載入相關安全模組，對雲端服務器的賬戶策略、登入策略等進行存取控制。如果相關配置存在異常，或觸發了相關策略，就可能會導致SSH登入失敗。

Linux系統內容配置

Linux內的系統內容，比如中毒、賬戶配置、環境變數配置等，如果出現異常，也可能會導致SSH登入失敗。

SSH服務及參數配置

SSH服務的預設設定檔為/etc/ssh/sshd_config。設定檔中的相關參數配置異常，或啟用了相關特性或策略，也可能會導致 SSH登入失敗。

SSH服務關聯目錄或檔案配置

SSH服務基於安全性考慮，在運行時，會對相關目錄或檔案的許可權配置、屬組等進行檢查。過高或過低的許可權配置，都可能會引發服務運行異常，進而導致用戶端登入失敗。

SSH服務密鑰配置

1. SSH服務採用非對稱式加密技術，對所傳輸的資料進行加密。用戶端及服務端會交換和校正相關密鑰資訊的有效性。常見案例如下。

• • SSH登入時出現如下錯誤：Host key verification failed

1. 如果根據前述問題情境進行排查和處理後，還是無法正常登入。則建議按照如下步驟逐一排查和分析。
   1. 使用不同的用戶端SSH及管理終端做對比訪問測試，判斷是否是個別用戶端自身配置或軟體運行問題所致。
   2. 參閱中間網路問題相關說明，測試網路連通性。
   3. 參閱管理終端，登入雲端服務器，在用戶端進行訪問測試的同時，執行如下命令，查看相關日誌。

       tailf /var/log/secure

   4. 參考如下命令， 比如ssh -v 192.168.0.1 命令，擷取Linux環境中詳細的SSH登入互動日誌。

      ssh -v [$IP]

   5. 通過管理終端登入Linux執行個體，參考如下步驟，檢查SSH服務運行狀態。

1. 1. 1. 執行如下命令，檢查服務運行狀態。

         service sshd status
         service sshd restart

         正常情況下會返回SSH服務的運行狀態及進程PID，系統顯示類似如下。

         [root@centos ~]# service sshd status
         openssh-daemon (pid   31350) is running...
         [root@centos ~]# service sshd restart
         Stopping sshd:                                             [  OK  ]
         Starting sshd:                                             [  OK  ]
         
         
         
         

1. 1. 2. 執行如下命令，檢查服務監聽狀態。

         netstat -ano | grep 0.0.0.0:22

         正常情況下會返回相應連接埠監聽資訊，系統顯示類似如下。

         netstat -ano | grep 0.0.0.0:22
         tcp     0    0 0.0.0.0:22      0.0.0.0:*      LISTEN    off (0.00/0/0)

1. 1. 3. 通過管理終端登入Linux執行個體，執行如下命令。如果能正常登入，則推斷是系統防火牆或外部安全性群組策略等配置異常，導致用戶端登入失敗。

         ssh 127.0.0.1

非對稱式加密演算法

提示：SSH服務主要採用RSA演算法（協議V2預設演算法）和DSA演算法（協議V1僅支援該演算法）來實現非對稱式加密技術。

• SSH服務是基於非對稱式加密（public-key cryptography，也稱公開祕密金鑰加密）演算法實現資料加密傳輸的。非對稱式加密演算法需要兩個密鑰：公開密鑰（publickey:簡稱公開金鑰）和私人密鑰（privatekey:簡稱私密金鑰）。公開金鑰與私密金鑰是一對，如果用公開金鑰對資料進行加密，只有用對應的私密金鑰才能解密。因為加密和解密使用的是兩個不同的密鑰，所以這種演算法叫作非對稱式加密演算法。
• 非對稱式加密演算法實現機密資訊交換的基本過程是：甲方產生一對密鑰並將公開金鑰公開，需要向甲方發送資訊的其他角色(乙方)使用該密鑰(甲方的公開金鑰)對機密資訊進行加密後再發送給甲方；甲方再用自己私密金鑰對加密後的資訊進行解密。甲方想要回複乙方時正好相反，使用乙方的公開金鑰對資料進行加密，同理，乙方使用自己的私密金鑰來進行解密。另一方面，甲方可以使用自己的私密金鑰對機密資訊進行簽名後再發送給乙方；乙方再用甲方的公開金鑰對甲方發送回來的資料進行驗簽。

SSH串連互動過程

SSH服務建立串連時的相關互動過程，主要三個階段，如下圖所示。

詳細說明如下。

服務端準備階段

服務端在每次啟動SSH服務時，都會自動檢查/etc/ssh/目錄下相關檔案的有效性。其中密鑰相關的檔案如果存在，且檢查發現異常，則會導致服務啟動失敗，並拋出相應錯誤資訊。 如果密鑰相關檔案不存在，重啟SSH服務則會預設自動重新建立。

註：SSH串連相關設定檔說明如下。

-rw-r--r-- 1 root root 581843 Jul 22 17:39 moduli                #用於DH-GEX演算法
-rw-r--r-- 1 root root 2276 Jul 22 17:39 ssh_config              #SSH用戶端設定檔
-rw------- 1 root root 3797 Jul 22 17:39 sshd_config             #SSH服務組態檔
-rw------- 1 root root 668 Jul 22 17:39 ssh_host_dsa_key         #DSA演算法私密金鑰（預設自動建立）
-rw-r--r-- 1 root root 618 Jul 22 17:39 ssh_host_dsa_key.pub     #DSA演算法公開金鑰（預設自動建立）
-rw------- 1 root root 963 May 20 14:22 ssh_host_key             #SSH服務V1版RSA演算法私密金鑰（預設自動建立）
-rw-r--r-- 1 root root 627 May 20 14:22 ssh_host_key.pub         #SSH服務V1版RSA演算法公開金鑰（預設自動建立）
-rw-r----- 1 root ssh_keys 1679 Jul 22 17:39 ssh_host_rsa_key    #SSH服務V2版RSA演算法私密金鑰（預設自動建立）
-rw-r--r-- 1 root root 410 Jul 22 17:39 ssh_host_rsa_key.pub     #SSH服務V2版RSA演算法公開金鑰（預設自動建立）

非對稱式加密協商階段

服務端SSH服務正常運行後，用戶端串連服務端需進行如下互動。

1. 用戶端向服務端發送串連請求，相關資訊通過明文發送。
2. 服務端返回公開金鑰資訊，是根據用戶端所使用的服務合約版本及演算法設定。比如，預設情況下，用戶端通過SSHV2版協議，基於 RSA演算法建立串連，則服務端將ssh_host_rsa_key.pub檔案中的內容返回用戶端。相關資訊通過明文發送。
3. 用戶端對服務端公開金鑰資訊進行比對和確認，用戶端接收到服務端公開金鑰資訊後，會進行如下比對，並讓使用者對相關資訊進行確認。
   • 如果是首次串連服務端，用戶端會收到類似如下資訊，讓使用者確認公開金鑰指紋的有效性。

     註：公開金鑰指紋：由於公開金鑰一般較長（採用RSA演算法時間長度達 1024 位）。所以為了簡便起見，通過對其MD5計算，產生一個128位的字串用於資訊對比。

     The authenticity of host '1.1.1.1 (1.1.0.1)' can't be established.
     RSA key fingerprint is c2:49:d9:43:74:d5:ed:bc:28:9b:d2:7b:63:94:cf:bc.
     Are you sure you want to continue connecting (yes/no)?
     
     

     • 如果使用者輸入no ，則串連中斷並報錯Host key verification failed。 
     • 如果使用者輸入yes，則會將相應的公開金鑰資訊，儲存到目前使用者家目錄下.ssh目錄內的known_hosts檔案中。
   • 如果服務端因重裝系統等因素導致公開金鑰指紋出現變化，則會直接導致串連失敗報錯Host key verification failed，則需要刪除已儲存的條目後再重新串連。 相關操作可以參閱如下文檔。
     • SSH 登入時出現錯誤提示為：Host key verification failed
   • 如果之前已經成功串連，而且公開金鑰指紋對比一致，則會繼續下一步操作。  
4. 用戶端產生臨時金鑰組，服務端公開金鑰校正及確認後，用戶端會產生一對臨時密鑰用於用戶端加密。該金鑰組不會儲存到檔案，而是記錄在記憶體中。每次串連都會重建臨時金鑰組。
5. 用戶端發送公開金鑰資訊，用戶端向服務端，發送前述產生的臨時金鑰組中的公開金鑰資訊。相關資訊通過明文發送。
6. 至此，服務端及用戶端都擁有對方的公開金鑰和自身的私密金鑰，完成非對稱式加密協商階段。

後續資料互動過程階段

後續登入校正及正常的資料轉送，都會通過雙向加密方式進行，相關互動說明如下。

• 如果服務端需要發送資料給用戶端，類似流程如下。
  • 服務端使用所持有的用戶端公開金鑰，對需要傳輸的資料進行加密，再發送給用戶端。
  • 用戶端收到資訊後，使用所持有的自身私密金鑰解密後擷取資料。
• 如果用戶端需要發送資料給服務端，類似流程如下。
  • 用戶端使用所持有的服務端公開金鑰，對需要傳輸的資料進行加密，再發送給服務端。
  • 服務端收到資訊後，使用所持有的自身私密金鑰解密後擷取資料。

SSH基於金鑰交換的自動登入原理簡介及配置說明

此處先簡要介紹基於金鑰交換的SSH自動登入的原理，然後對配置方法進行說明。

原理簡介

SSH認證認證登入的基礎是一對唯一匹配密鑰: 私密金鑰（private key）和公開金鑰（public key）。公開金鑰用於對資料進行加密，而且只能用於加密。而私密金鑰只能對使用所匹配的公開金鑰，所加密過的資料進行解密。私密金鑰需要使用者單獨妥善保管。SSH用戶端使用私密金鑰向伺服器證明自已的身份。而公開金鑰是公開的，可以按需將其配置到目標伺服器上自己的相應賬號中。在進行SSH登入認證時，進行私密金鑰和公開金鑰協商。如果匹配，則身份得以證明，認證成功，允許登入。否則，將會繼續使用密碼驗證等其它方式進行登入校正。SSH認證驗證登入配置及登入協商過程，如下圖所示。

各步驟補充說明如下。

產生認證

1. 用戶端產生金鑰組。
2. 將公開金鑰資訊寫入目標伺服器、目標賬戶的設定檔。該操作隱含表示了用戶端擁有對目標伺服器的控制權。

協商互動過程

1. 用戶端向目標伺服器發送登入請求。在SSH服務啟用了認證驗證登入方式後，會優先通過認證驗證方式進行登入驗證。 
2. 目標伺服器根據SSH服務配置，在使用者對應目錄及檔案中讀取到有效公開金鑰資訊。
3. 目標伺服器產生一串隨機數，然後使用相應的公開金鑰對其加密。
4. 目標伺服器將加密後的密文發回用戶端。
5. 用戶端使用預設目錄或-i參數指定的私密金鑰嘗試解密。
6. 如果解密失敗，則會繼續嘗試密碼驗證等其它方式進行登入校正。如果解密成功，則將解密後的原文資訊重新發送給目標伺服器。意思類似於： “看，這是這段話的原文。我能讀懂發過來的密文，我擁有伺服器的控制權，請讓我登入。”
7. 目標伺服器對用戶端返回的資訊進行比對。如果比對成功，則表示認證成功，用戶端可以登入。如果對比失敗，則表示認證失敗，則會繼續嘗試密碼驗證等其它方式進行登入校正。

自動登入配置

產生金鑰組

SSH協議V1隻使用RSA演算法，而SSH協議V2對RSA演算法和DSA演算法都支援。目前所有OpenSSH版本都應該對兩種演算法都支援。兩種演算法的密鑰的產生指令和使用方法相同，本文僅以RSA演算法為例進行相關說明。產生金鑰組的時候，可以按需決定是否設定密碼。但需要注意的是，如果設定了密碼，還需結合SSH-Agent代理和SSH-Add配置才能實現自動登入。同時，相關配置只對SSH-Agent啟動的相應Shell生效，使用者退出後重新登入時還需重新設定。所以，為簡便起見，本文以常見的、不配置密碼的情況進行說明。可以在任意支援環境下產生金鑰組。Windows和Linux環境下，配置分別說明如下。

Windows環境下產生金鑰組

在Windows環境下，通常藉助各種應用軟體來建立和管理金鑰組。以常見的PuTTYgen為例，建立金鑰組步驟參考如下。

1. 啟動 PuTTYgen。本樣本中的PuTTYgen版本為0.68。
2. 在 Parameters > Type of key to generate 中，選中 RSA，其中 Number of bits in a generated key 的值不需要設定，軟體會根據匯入的私密金鑰資訊自動更新。
   
3. 單擊 Load。PuTTYgen預設僅顯示副檔名為.ppk的檔案。要找到您的.pem檔案，請選擇顯示所有類型的檔案。
   
4. 選擇您從阿里雲下載的.pem格式的私密金鑰檔案，然後單擊 開啟。
   
5. 單擊 OK（確定）關閉確認對話方塊。
6. 單擊 Save private key，PuTTYgen會顯示一條關於在沒有口令的情況下儲存密鑰的警告，單擊 是(Y)。
   
7. 指定與金鑰組相同的私密金鑰名稱，儲存。PuTTYgen會自動為檔案添加.ppk副檔名。

Linux 環境下產生金鑰組

在Linux環境下，通常使用系統內建的SSH-Keygen軟體來建立和管理金鑰組，建立金鑰組步驟參考如下。

1. 以任意具有SSH-Keygen執行許可權的使用者登入伺服器。
2. 執行如下命令，基於RSA演算法建立金鑰組。

   ssh-keygen -t rsa

   系統顯示類似如下。
   
   建立密鑰各步驟說明，參考如下。
   

   Generating public/private rsa key pair.
   Enter file in which to save the key (/root/.ssh/id_rsa):          #預設儲存路徑和檔案名稱，可以按需修改。
   Enter passphrase (empty for no passphrase):                       #如前面所述，不設定密碼，斷行符號確認即可。
   Enter same passphrase again:                                      #不設定密碼，斷行符號確認即可。
   Your identification has been saved in /root/.ssh/id_rsa.          #建立的私密金鑰檔案。
   Your public key has been saved in /root/.ssh/id_rsa.pub.          #建立的公開金鑰檔案。
   The key fingerprint is:
   17:b8:0e:76:cb:57:21:3b:f2:bb:8b:a2:42:2b:54:be root@iZ233gr74jvZ
   The key's randomart image is:
   +--[ RSA 2048]----+
   | |
   | . |
   | . o . |
   | . . + . |
   | o o S + . |
   | ... . = = o |
   |.. .. + o |
   |. oE . o . |
   | . ... .. +o |
   +-----------------+
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   

   提示：

   • 如果.ssh目錄不存在，程式會自動建立。
   • 產生的金鑰組是預設儲存在目前使用者家目錄下的.ssh目錄，檔案名稱預設為id_rsa（私密金鑰）和id_rsa.pub（公開金鑰）。使用者可以按需設定儲存路徑和檔案名稱。

   
   
   
   

密鑰配置

產生金鑰組後，進行如下處理。

私密金鑰的處理

私密金鑰用於資訊校正，請確保安全。可以將私密金鑰上傳到其它原始伺服器上，或者直接參閱前述說明建立新的金鑰組。

公開金鑰的處理

1. 公開金鑰資訊需要寫入目標伺服器、目標使用者的設定檔中，預設設定檔為對應使用者家目錄下.ssh目錄的authorized_keys檔案中，如下所示。

   ~/.ssh/authorized_keys

2. 在用戶端執行如下命令，傳遞公開金鑰到目標伺服器的指定使用者下。

   cat ~/.ssh/id_rsa.pub | ssh [$Name]@[$Host] 'cat >> ~/.ssh/authorized_keys'

   提示：

   • [$Name]使用者名稱。
   • [$Host]目標伺服器主機名稱或IP地址。

參數與許可權檢查確認

要順利完成自動登入，還需對SSH服務相關參數及關聯檔案、檔案夾的許可權進行確認或調整。

注意：如果對相關參數做了修改，需要重啟SSH服務生效。

• SSH服務參數設定。
  • SSH服務預設開啟了認證認證支援。編輯SSH服務組態檔（預設為/etc/ssh/sshd_config），確保如下參數沒有設定為no。否則需將參數值修改為yes，或者注釋（在最開頭添加#號）該參數配置。

    RSAAuthentication
    PubkeyAuthentication

  • 如果修改了預設的公開金鑰存放路徑或檔案名稱，確認如下參數的值與新公開金鑰路徑或檔案名稱一致。

    AuthorizedKeysFile

• 相關使用權限設定。
  • SSH服務憑證驗證方式登入，對相關目錄和檔案的許可權都有要求，許可權配置異常可能會導致登入失敗。
  • 在指定使用者下執行如下命令，修改.ssh目錄，只有所有者才有權寫入。

    chmod 700 ~/.ssh

  • 在指定使用者下執行如下命令，修改authorized_keys檔案的許可權配置，使其它使用者對authorized_keys檔案沒有修改許可權。

    chmod 600 ~/.ssh/authorized_keys

  •  在指定使用者下，依次執行如下命令，修改authorized_keys檔案的許可權配置，使其他使用者無任何許可權，並對.ssh目錄添加immutable位許可權，防止檔案被修改。

    chmod 400 ~/.ssh/authorized_keys
    chattr +i ~/.ssh/authorized_keys
    chattr +i ~/.ssh
    
    

Windows 環境自動登入

登入步驟您可以參閱如下文檔。

• 使用SSH金鑰組串連Linux執行個體

Linux環境自動登入

1. Linux環境下，在用戶端直接通過SSH免密碼登入。

   ssh [$Name]@[$Host]

2. 如果修改了私密金鑰路徑或檔案名稱，則需要通過-i參數進行指定。

   ssh -i [$Path] [$Name]@[$Host]

   註：[$Path]為私密金鑰絕對路徑加檔案名稱。列如/root/.ssh/my_rsa，即為my_rsa密鑰。

相關文檔

• OpenSSH官方使用手冊
• Wikipedia 上關於 SSH 的介紹和討論

適用於

• Elastic Compute Service