☰

authorized_keys 有我的金鑰，但仍然被拒絕

tag-icon • tag-icon ssh authentication public-key
authorized_keys 有我的金鑰，但仍然被拒絕

我使用 ssh 從機器 M1 連接到機器 M2（連接到另一台機器上的相同使用者）。我還應該提到用戶在兩台機器上共享相同的金鑰。透過密碼驗證，一切正常；公鑰認證則不然；我已確保~/.ssh/authorized_keysM2 上的 RSA 金鑰已獲得授權，但 ssh 仍然退回到密碼驗證。我得到以下資訊ssh -vvv：

debug2: key: /home/joeuser/.ssh/id_rsa (0x7f42679e8200),
debug2: key: /home/joeuser/.ssh/id_dsa ((nil)),
debug2: key: /home/joeuser/.ssh/id_ecdsa ((nil)),
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/joeuser/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/joeuser/.ssh/id_dsa
debug3: no such identity: /home/joeuser/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/joeuser/.ssh/id_ecdsa
debug3: no such identity: /home/joeuser/.ssh/id_ecdsa: No such file or directory
debug2: we did not send a packet, disable method

我應該要提一下，我是能夠使用來自其他電腦的公鑰身份驗證進行連線（不使用相同的金鑰）。

在這種情況下，基於金鑰的身份驗證失敗的潛在原因是什麼？

注意：機器均為 SLES (SuSE Linux Enterprise Server) 11。

答案1

您使用客戶端做了正確的事情ssh -vvv，將其與調試模式下的 sshd 配對，如下所示：

第二個伺服器實例： # /usr/sbin/sshd -p 1234 -dddd

專用客戶端連線： $ ssh -i .ssh/id_rsa-admuser admuser@server -p 1234 -vvvv

就我而言，事實證明關鍵資訊僅列印在客戶端上。伺服器通過了

debug2: user_key_allowed: check options...
debug2: user_key_allowed: advance ...
debug2: key not found

當客戶想出這個時：

debug1: Next authentication method: publickey
debug1: Offering public key: .ssh/id_rsa-admuser RSA SHA256:<censored> explicit agent
debug1: send_pubkey_test: no mutual signature algorithm

那麼這裡發生了什麼事？

伺服器太舊了，無法協商輔助演算法；關鍵還在於過時的，但整體來說還好。

現在的基本方法是什麼？

  1. 在不同的連接埠上啟動專用伺服器
  2. 在新會話中從客戶端連接
  3. 逐步比較雙方的金鑰交換
  4. 使用新產生的第二個金鑰對驗證結果

在這個具體示例中，有一個明確的解釋，即它是一種不安全的舊方法，已被棄用，即此處描述的。 https://confluence.atlassian.com/bitbucketserverkb/ssh-rsa-key-rejected-with-message-no-mutual-signature-algorithm-1026057701.html

為了能夠更新那個舊盒子，我可以透過新增-o PubkeyAcceptedKeyTypes=+ssh-rsa到客戶端上的 ssh 命令列來進行連線。

答案2

檢視基礎知識：

  1. id_rsa 和 id_rsa.pub 存在於 M1 和 M2 上
  2. id_rsa 在 M1 和 M2 上都有權限 600（即只有擁有者可以讀寫）
  3. authorized_keys 檔案將金鑰貼上為單行（無換行符）
  4. authorized_keys的權限為600
  5. 通常，我的 .ssh 資料夾的權限為 600（預設）
  6. 檢查每個資料夾 /home 一直到 .ssh 的權限
  7. 我知道您想使用 RSA，但請嘗試 DSA 金鑰，看看它是否有效。如果是這樣，那麼我們將把 SSH 和 RSA 配置歸零。

答案3

你得到的錯誤是

/home/joeuser/.ssh/id_dsa: No such file or directory

確保此文件存在、包含與您新增的公鑰相對應的私鑰、所屬joeuser的且具有600使用者權限：

sudo chown joeuser /home/joeuser/.ssh/id_dsa
sudo chmod 600 /home/joeuser/.ssh/id_dsa

您還應該嘗試像這樣明確定義私鑰：

ssh -i ~/.ssh/id_rsa [email protected]

如果您不確定這是否是正確的金鑰，那麼我建議建立一個新的 RSA 金鑰對

ssh-keygen -b 4096

並將公鑰內容新增~/.ssh/id_rsa.pub到遠端伺服器的authorized_keys檔案。確保您沒有覆蓋您仍需要登入其他伺服器的現有私鑰！

相關內容