阿里雲團隊努力不懈,力求將最新的技術內容更快地以您最熟悉的語言呈現。本文由簡體中文內容自動轉碼而成,過程無人工干預。阿里雲不保證此自動轉碼的準確性、完整性及時效性。因轉碼造成的任何內容錯誤及因此可能帶來的損失,阿里雲概不負責,敬請見諒。本文内容請以簡體中文版本為準。
全部產品
Search
文件中心

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

更新時間: Jan 09, 2020

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

 

概述

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

 

詳細資料

提示:

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

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

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

 

用戶端

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

 

中間網路

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

telnet [$IP] [$Port]

註:

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

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

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

 

PAM安全架構

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

 

Linux系統內容配置

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

 

SSH服務及參數配置

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

 

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

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

 

SSH服務密鑰配置

  1. SSH服務採用非對稱式加密技術,對所傳輸的資料進行加密。用戶端及服務端會交換和校正相關密鑰資訊的有效性。常見案例如下。
  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. 執行如下命令,檢查服務運行狀態。
        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. 執行如下命令,檢查服務監聽狀態。
        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. 通過管理終端登入Linux執行個體,執行如下命令。如果能正常登入,則推斷是系統防火牆或外部安全性群組策略等配置異常,導致用戶端登入失敗。
        ssh 127.0.0.1

 

更多內容

SSH服務在進行資料轉送前,會先進行金鑰交換和協商確認。完成後再對後續資料進行加密傳輸,以提高安全性。以下先對SSH服務所採用的非對稱式加密技術進行簡要介紹,然後對SSH串連過程中的相關互動,及關聯檔案進行說明,內容目錄如下。

 

SSH串連互動過程簡介

非對稱式加密演算法

提示: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,則需要刪除已儲存的條目後再重新串連。 相關操作可以參閱如下文檔。
    • 如果之前已經成功串連,而且公開金鑰指紋對比一致,則會繼續下一步操作。  
  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 的值不需要設定,軟體會根據匯入的私密金鑰資訊自動更新。
    ECS _ SSH Key Pair _ 匯入私密金鑰參數
  3. 單擊 Load。PuTTYgen預設僅顯示副檔名為.ppk的檔案。要找到您的.pem檔案,請選擇顯示所有類型的檔案。
    ECS _ SSH Key Pair _ 開啟待匯入的私密金鑰檔案
  4. 選擇您從阿里雲下載的.pem格式的私密金鑰檔案,然後單擊 開啟
    ECS _ SSH Key Pair _ 載入pem檔案
  5. 單擊 OK(確定)關閉確認對話方塊。
  6. 單擊 Save private key,PuTTYgen會顯示一條關於在沒有口令的情況下儲存密鑰的警告,單擊 是(Y)
    ECS _ SSH Key Pair _ 儲存私密金鑰
  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 環境自動登入

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

 

Linux環境自動登入
  1. Linux環境下,在用戶端直接通過SSH免密碼登入。
    ssh [$Name]@[$Host]
  2. 如果修改了私密金鑰路徑或檔案名稱,則需要通過-i參數進行指定。
    ssh -i [$Path] [$Name]@[$Host]
    註:[$Path]為私密金鑰絕對路徑加檔案名稱。列如/root/.ssh/my_rsa,即為my_rsa密鑰。

 

相關文檔

 

適用於

  • Elastic Compute Service