SSH "Permission denied (publickey)"：怎麼修

"Permission denied (publickey)" 是什麼意思

這個報錯的意思是伺服器拒絕了你的認證——網路連線是通的,但伺服器不接受你用戶端遞上來的任何憑證。括號裡寫 (publickey),說明伺服器只允許金鑰認證、而你的金鑰一把都沒匹配上。它幾乎總是五個原因之一:使用者名稱錯、用戶端沒遞對金鑰、公鑰不在伺服器上、~/.ssh 權限不對、或伺服器設定不允許你的認證方式。下面教你幾分鐘定位是哪一個。

五個原因,按可能性排序

1——先查使用者名稱

最常見的原因,尤其在雲端伺服器上:每種映像有自己的預設使用者——ubuntu(Ubuntu)、ec2-user(Amazon Linux)、root(很多 VPS 映像)、pi(舊版樹莓派系統)、debian、admin……使用者名稱錯了,伺服器在看你的金鑰之前就拒絕了,報錯長得一模一樣。

2——確認遞的是對的金鑰

桌面上,ssh -v user@host 會顯示用戶端嘗試了哪些金鑰("Offering public key…")。行動用戶端裡,打開連線設定確認這條連線真的掛了金鑰——一條"用密碼"建的連線根本不會遞金鑰。在 TermAI 裡,編輯連線、把認證切到你的金鑰。

3——把公鑰裝到伺服器上

伺服器只接受列在你登入的那個使用者的 ~/.ssh/authorized_keys 裡的金鑰。如果你還有別的方式能進去(密碼、主控臺):

# 从一台能登录的机器:
ssh-copy-id user@host
# 或手动追加你的公钥:
cat your_key.pub >> ~/.ssh/authorized_keys

在手機上,TermAI 能替你做:它生成 Ed25519 金鑰,並有一鍵部署到伺服器,透過現有的可用登入把公鑰寫進 authorized_keys。注意:金鑰裝在特定使用者的家目錄下——給 root 裝了,不等於能用 ubuntu 登入。

4——修伺服器上的權限

檔案或目錄權限太開放時,OpenSSH 會默默忽略 authorized_keys。在伺服器上:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

也檢查家目錄本身沒有群組/全員可寫。這就是經典的"金鑰裝了還是失敗"的原因——看伺服器的 /var/log/auth.log,它會記"Authentication refused: bad ownership or modes"。

5——看伺服器允許什麼

在 /etc/ssh/sshd_config 裡:如果 PasswordAuthentication no 而你的金鑰沒裝,你就被鎖在失敗的路上;如果 PermitRootLogin no 而你在試 root,那就是拒絕的來源。改設定(或用對的使用者),然後 sudo systemctl restart ssh。見安全地停用 root 登入。

在手機上排查

這個錯在手機上撞見時,痛苦的是讀冗長的報錯、記診斷命令。只要你對這臺機器還有任何能用的工作階段,選中報錯輸出問助手——TermAI 的 AI 讀真實的報錯和伺服器上下文,告訴你是五個原因裡的哪一個,並給出可複核再執行的確切修復命令。

常見問題

Permission denied (publickey) 是什麼意思?
伺服器只接受 SSH 金鑰認證,而你用戶端遞的金鑰都沒匹配。按順序查:使用者名稱、金鑰選擇、authorized_keys、權限。

為什麼我裝了金鑰還是失敗?
通常是權限:~/.ssh 必須 700、authorized_keys 必須 600,且歸登入使用者所有。或者金鑰裝在了另一個使用者名稱下。

怎麼看到底是什麼在失敗?
桌面上跑 ssh -v user@host;伺服器上看 /var/log/auth.log(或 journalctl -u ssh)——它會明確寫出原因。

能從手機上修嗎?
能,只要你還有任何能進去的方式(密碼登入或另一把金鑰)。TermAI 能一鍵把新金鑰部署到伺服器,它的 AI 也能診斷 auth.log 輸出。

快速事實

• 含義:伺服器拒絕認證——沒有遞上的金鑰匹配(是認證問題,不是網路)
• 主因:使用者名稱錯 · 沒遞金鑰 · 不在 authorized_keys · 權限不對 · 伺服器設定
• 權限:~/.ssh 700,authorized_keys 600
• 看真實原因:用戶端 ssh -v,伺服器端 /var/log/auth.log