SSH-Key 驗證失敗

Question 1

這通常可以解決大多數 SSH 授權金鑰權限問題在伺服器端，假設有人沒有對權限進行其他更改。

# paste these into an SSH session that server (probably from
# another user account or root)

# change this to YOUR username on the server.
YOURUSER=example

# paste these lines verbatim:
sudo chown $YOURUSER:$YOURUSER /home/$YOURUSER/{.,.ssh/,.ssh/authorized_keys}
sudo chmod u+rwX,go-rwX,-t /home/$YOURUSER/{.ssh/,.ssh/authorized_keys}
sudo chmod go-w /home/$YOURUSER/

（這是什麼使用者化根據團隊 Web 儀表板中的變更自動在其「shim」腳本中更新和修復任何權限問題。

如果您的管理員以 root 身分建立了 .ssh/ 目錄或 .ssh/authorized_keys 檔案（這是最常見的損壞方式），則不允許該檔案由其他使用者擁有，即使該使用者是根。

Answer

這通常可以解決大多數 SSH 授權金鑰權限問題在伺服器端，假設有人沒有對權限進行其他更改。

# paste these into an SSH session that server (probably from
# another user account or root)

# change this to YOUR username on the server.
YOURUSER=example

# paste these lines verbatim:
sudo chown $YOURUSER:$YOURUSER /home/$YOURUSER/{.,.ssh/,.ssh/authorized_keys}
sudo chmod u+rwX,go-rwX,-t /home/$YOURUSER/{.ssh/,.ssh/authorized_keys}
sudo chmod go-w /home/$YOURUSER/

（這是什麼使用者化根據團隊 Web 儀表板中的變更自動在其「shim」腳本中更新和修復任何權限問題。

如果您的管理員以 root 身分建立了 .ssh/ 目錄或 .ssh/authorized_keys 檔案（這是最常見的損壞方式），則不允許該檔案由其他使用者擁有，即使該使用者是根。

Question 2

我在兩台伺服器上遇到了完全相同的問題：運行 Debian Stretch 的 Linux 和 NAS (Synology DS715)

事實證明，這兩種情況都是伺服器上的主目錄權限錯誤

伺服器上的 auth.log 非常有幫助

Authentication refused: bad ownership or modes for directory /home/cyril

在Linux上，它有寫/組位（drwxrwxr--x），所以我必須至少刪除組上的寫（chmod gw ~/）然後它就起作用了

在 Synology 上，無論出於何種原因，都有一個棘手的問題

drwx--x--x+ 4 toto users 4096 Jan 6 12:11 /var/services/homes/toto

我不得不改變它

chmod -t ~/

然後我就可以在沒有密碼的情況下連接

Answer

我在兩台伺服器上遇到了完全相同的問題：運行 Debian Stretch 的 Linux 和 NAS (Synology DS715)

事實證明，這兩種情況都是伺服器上的主目錄權限錯誤

伺服器上的 auth.log 非常有幫助

Authentication refused: bad ownership or modes for directory /home/cyril

在Linux上，它有寫/組位（drwxrwxr--x），所以我必須至少刪除組上的寫（chmod gw ~/）然後它就起作用了

在 Synology 上，無論出於何種原因，都有一個棘手的問題

drwx--x--x+ 4 toto users 4096 Jan 6 12:11 /var/services/homes/toto

我不得不改變它

chmod -t ~/

然後我就可以在沒有密碼的情況下連接

Question 3

當使用 CentOS 7 時，我相信也適用於使用 sshd 的其他 Linux 作業系統。透過 root 存取權限，您可以進一步確定身份驗證失敗的原因。去做這個：

為守護程式啟用sshd日誌記錄：sudo vi /etc/ssh/sshd_config
在日誌記錄下取消註解：

SyslogFacility AUTH
LogLevel INFO

更改LogLevel從INFO到DEBUG
儲存並退出
重新啟動 SSH 守護程式sudo systemctl restart sshd
觀看訊息文件tail -l /var/log/messages
使用另一個終端，嘗試透過 ssh 連接
嘗試連接ssh
查看身份驗證日誌以了解確切原因

例如，我遇到了一些與上面提到的相同的問題。

Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys

使用這些步驟，我能夠確認問題是文件的權限authorized_keys。透過chmod 644對authorized_keys我的用戶的文件進行設置，問題得到解決。

Answer

當使用 CentOS 7 時，我相信也適用於使用 sshd 的其他 Linux 作業系統。透過 root 存取權限，您可以進一步確定身份驗證失敗的原因。去做這個：

為守護程式啟用sshd日誌記錄：sudo vi /etc/ssh/sshd_config
在日誌記錄下取消註解：

SyslogFacility AUTH
LogLevel INFO

更改LogLevel從INFO到DEBUG
儲存並退出
重新啟動 SSH 守護程式sudo systemctl restart sshd
觀看訊息文件tail -l /var/log/messages
使用另一個終端，嘗試透過 ssh 連接
嘗試連接ssh
查看身份驗證日誌以了解確切原因

例如，我遇到了一些與上面提到的相同的問題。

Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys

使用這些步驟，我能夠確認問題是文件的權限authorized_keys。透過chmod 644對authorized_keys我的用戶的文件進行設置，問題得到解決。

Question 4

我有過類似的問題，其中 ssh 連線~/.ssh/id_rsa在意外停止之前嘗試密鑰：

debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

就我而言，這是由於.ssh目錄中存在舊的公鑰檔案：

[gitlab-runner@validation-k8s-1 ~]$ ll .ssh/id_rsa*
total 16
-rw------- 1 gitlab-runner gitlab-runner 1675 Sep 18 18:02 id_rsa      --> new private key
-rw-r--r--. 1 gitlab-runner gitlab-runner  423 Jun 12 13:51 id_rsa.pub --> old public key

id_rsa.pub從目錄中移動/刪除.ssh解決了問題。

據我了解：當客戶端存在公鑰時，SSH 首先會根據它驗證私鑰。如果失敗，它不會嘗試使用私鑰進行遠端連線。

我向 openssh 郵件清單發送了一封電子郵件：https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html。

Answer