SSD Nodes Learn
指南 Matt Connor作者: Matt Connor · 已更新 2026-07-24

SSH key 管理教學:Ed25519 金鑰與權限設定

本文介紹 SSH key 運作原理,包含使用 ed25519 演算法建立金鑰、遵守 sshd 要求的檔案權限、利用 config 中的 Host 區塊簡化連線,以及裝置遺失時如何從 authorized_keys 移除金鑰。

SSH key 的運作原理

SSH key 是由一對檔案組成:一個保留在您裝置上的 private key,以及一個需要複製到所有目標伺服器的 public key。連線時,伺服器會使用 public key 發送挑戰(challenge),只有對應的 private key 能回應該挑戰。由於 private key 永不離開您的裝置,因此不會有任何秘密資訊在網路傳輸,即使伺服器遭入侵,攻擊者也無法竊取有用資訊。這就是為什麼 key 比 password 更安全。管理 SSH key 的關鍵在於四個習慣:每個裝置使用單一 key、遵守 sshd 要求的檔案權限、使用 ~/.ssh/config 檔案以避免重複輸入選項,以及在筆電遺失時能立即移除該 key。

本指南以 Ubuntu 24.04 為基準說明上述習慣,但大部分內容適用於任何 Linux 伺服器及近期的 OpenSSH 版本。

在開始之前,需先釐清一個術語,以避免錯誤。public key 並非秘密。您可以將其貼上至工單、透過電子郵件傳送或公開,任何人無法藉此登入。private key 才是秘密。對伺服器而言,任何複製該檔案並知道其 passphrase(若有設定)的人,都被視為您本人。

建立金鑰:ed25519 是正確的預設值

請在您的個人電腦(而非伺服器)上執行:

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 用於選擇金鑰類型。Ed25519 是現代的預設值:金鑰長度短、速度快,且自 2014 年起的每個 OpenSSH 版本皆支援。僅在必須與不支援 ed25519 的舊裝置連線時,才改用 ssh-keygen -t rsa -b 4096-C "laptop" 用於設定註解。註解不具備加密功能,但兩年後您能透過它在伺服器的 authorized_keys 檔案中辨識此金鑰,因此請將金鑰存放的裝置名稱填入。

ssh-keygen 會詢問金鑰儲存位置。請接受預設值 ~/.ssh/id_ed25519。接著系統會要求輸入密碼(passphrase)。請設定密碼;下方的密碼章節會解釋為何這不會增加日常操作的負擔。執行後會產生兩個檔案:~/.ssh/id_ed25519 是私鑰,~/.ssh/id_ed25519.pub 是公鑰。查看公鑰內容:

cat ~/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

內容僅為單行:包含金鑰類型、金鑰內容以及您的註解。這行內容最終會被寫入您的伺服器中。

每台裝置使用單一金鑰,而非每台伺服器使用單一金鑰

最常見的問題是:我是否需要為每台伺服器建立新金鑰?不需要。請為每一台輸入指令的裝置建立一個金鑰,並將該公鑰放入所有該裝置需要連線的伺服器中。金鑰是用來識別裝置。每台伺服器上的 authorized_keys 檔案即為允許連線的裝置清單。

這種模式具備擴展性,而其他方案會出現可預見的錯誤。若每台伺服器使用單一金鑰,當筆電需要連線 20 台伺服器時,該筆電將持有 20 個私鑰,導致難以管理。若所有裝置共用同一個金鑰,情況更糟:當筆電遺失時,你無法在不鎖定桌機的情況下撤銷該筆電的權限,因為兩者持有相同的私鑰;你必須在所有地方更換金鑰,並同時重新分發給所有裝置。

若採用每台裝置使用單一金鑰的模式,遺失筆電僅需在每台伺服器上修改一行設定:從 authorized_keys 中刪除該筆電的行,其他裝置即可繼續運作。透過 -C 設定的註解,能讓你輕鬆找到該行設定。

此模式的核心原則:私鑰是在裝置上建立的,且隨裝置報廢而失效。切勿將私鑰複製到第二台機器,也切勿將私鑰上傳至伺服器。當新裝置需要存取權限時,請直接在該裝置上產生新金鑰。

將公鑰部署至伺服器

最簡單的方法是使用 OpenSSH 內建的 ssh-copy-id

ssh-copy-id matt@10.0.0.10

此指令會使用現有的登入方式(通常是密碼)進行連線,將您的公鑰附加至伺服器上的 ~/.ssh/authorized_keys,並在目錄或檔案缺失時自動建立且設定正確的權限。請開啟一個新的 SSH 階段進行測試:伺服器應允許您直接登入,而無需輸入帳號密碼。若您的金鑰設有 passphrase,您的本地端可能會要求輸入該密碼;該提示屬於本地端行為,並非伺服器密碼。

若伺服器已停用密碼登入,ssh-copy-id 將無法連線,此時必須手動新增內容。請透過仍可使用的連線方式或供應商的 Web console 登入,並在伺服器上執行以下指令:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

請將您的實際公鑰內容貼入引號內,即來自 id_ed25519.pub 的完整單行內容。authorized_keys 的格式為每行一個公鑰,這就是完整的存取清單:新增裝置即是新增一行,撤銷裝置即是刪除一行。在全新的伺服器上,此步驟應包含在 新 VPS 的前 10 分鐘 流程中,並於停用密碼登入之前完成。

導致金鑰登入失敗的權限問題

這是金鑰登入失敗最常見的原因,且在用戶端會靜默失敗。在 Ubuntu 24.04 上,sshd 預設以 StrictModes yes 執行,這代表它會拒絕使用任何其他使用者可以編輯的 authorized_keys 檔案。若該檔案、~/.ssh 目錄或您的家目錄可被您以外的任何人寫入,sshd 會忽略您的金鑰並改為要求輸入密碼,且用戶端不會顯示任何說明。(Ubuntu 的 OpenSSH 僅容許一種特殊情況:檔案群組可寫入,但該群組僅包含您本人。請勿依賴此特性;請維持下方的權限設定。)錯誤原因僅會顯示在伺服器日誌中:

sudo grep 'Authentication refused' /var/log/auth.log

若使用不含 rsyslog 的精簡映像檔,則不會有 auth.log;相同的內容會記錄在 journal 中:sudo journalctl -u ssh | grep 'Authentication refused'

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

解決方法是在伺服器上以受影響的使用者身份執行兩項權限變更與一項所有權檢查:

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

請記住此規則:.ssh 目錄應設定為 700,其內部所有內容應設定為 600。相同的設定也適用於您的電腦,因為用戶端也會進行檢查。若私鑰可被其他使用者讀取,會導致 ssh 直接拒絕該金鑰,且此次會顯示錯誤訊息:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/matt/.ssh/id_ed25519' are too open.

使用 chmod 600 ~/.ssh/id_ed25519 即可修復。

~/.ssh/config:停止重複輸入參數

在您的電腦中建立一個 ~/.ssh/config 檔案,即可為每台伺服器設定簡短名稱,並記錄您經常輸入的參數。請使用 600 權限建立此檔案,並為每台伺服器新增一個 Host 區塊:

Host web1
    HostName 10.0.0.10
    User matt
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host db1
    HostName 10.0.0.11
    User matt
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

現在 ssh web1 可以取代 ssh -p 22 matt@10.0.0.10,且相同的簡短名稱也能用於 scprsyncgit,因為這些工具都會讀取此檔案。HostName 是實際的位址,User 可省去輸入帳號名稱的步驟,而 IdentityFile 則指定要使用的金鑰。

IdentitiesOnly yes 值得特別說明,因為它可以解決一個常見的錯誤。當您的 agent 持有多把金鑰時,client 會依序嘗試每一把金鑰,而伺服器會將每一次嘗試都視為一次失敗嘗試。若載入的金鑰過多,在嘗試正確的金鑰之前,您就會遇到 Received disconnect: Too many authentication failures。使用 IdentitiesOnly yes 可讓 client 僅嘗試 IdentityFile 指定的金鑰,從而避免此錯誤。

Passphrases 與 ssh-agent

Passphrase 會對磁碟上的 private key 檔案進行加密。若未設定 passphrase,任何人複製該檔案後即可直接使用;若有設定,在破解 passphrase 前,被盜的檔案將無法使用。對於筆記型電腦上的 key 而言,這正是必要的保護措施,因為筆記型電腦可能會遺失,且備份檔案也可能外洩。

實務上使用 passphrase 並不會增加額外負擔,原因在於 ssh-agent。Agent 會將解密後的 key 儲存在記憶體中,因此您在每次登入階段只需輸入一次 passphrase,之後的所有連線皆可立即完成。大多數的桌面版 Linux 發行版與 macOS 已預先執行 agent。請使用以下指令將 key 載入 agent:

ssh-add ~/.ssh/id_ed25519

ssh-add -l 會列出 agent 目前持有的 keys。請注意:agent forwarding (ssh -A) 允許遠端伺服器在您連線期間,利用您的 agent 進行後續驗證,因此請僅對您完全信任的伺服器啟用此功能,並建議預設將其關閉。

輪換與撤銷:筆電遺失演練

撤銷一般的 SSH key,僅需從所有含有該 key 的伺服器中,將其對應的行從 authorized_keys 中移除。無需通知憑證授權單位 (CA),也不需等待過期。一旦該行被刪除,使用該 key 的新登入嘗試將會失敗。

請在非緊急狀態下立即進行演練。選擇一台伺服器,開啟 ~/.ssh/authorized_keys,並透過 comment 找到該 key。使用編輯器刪除該行,或透過 comment 過濾掉它:

grep -v ' laptop$' ~/.ssh/authorized_keys > ~/.ssh/authorized_keys.tmp
mv ~/.ssh/authorized_keys.tmp ~/.ssh/authorized_keys

接著,從剛撤銷該 key 的裝置確認登入已失敗,並從另一台裝置確認登入仍可正常運作。請注意一個細節:移除 key 並不會關閉已建立的連線,因為 key 僅在登入時進行驗證。若您正在撤銷遺失裝置的權限,請同時檢查伺服器上的 who,並結束所有不明的連線。

輪換 (Rotation) 的操作流程相同,僅順序不同:在裝置上產生新 key,使用 ssh-copy-id 安裝它,確認新 key 可成功登入,最後再刪除舊的行。當裝置移交、key 可能已外洩,或團隊成員離職時,請執行此操作。手動處理兩台伺服器尚可接受;若涉及二十台伺服器,則需透過自動化處理,管理多台 Linux 伺服器 說明了如何將相同的 authorized_keys 狀態推送到整個裝置群。

錯誤做法

  • 請勿在所有裝置上共用同一個 private key。若其中一個裝置遺失,你將無法單獨撤銷該裝置的權限,而必須更換所有裝置的 key。
  • 請勿將 private key 提交至 git repository,即使是 private repository 亦然。自動化掃描工具會在 push 後幾分鐘內偵測公開 repository 中的洩漏 key;若 repository 之後轉為公開,其完整歷史紀錄也會隨之洩漏。
  • 請勿將筆記型電腦的 private key 上傳至伺服器,以供該伺服器存取其他伺服器。請直接在目標伺服器上生成獨立的 key,並僅針對該需求進行授權。
  • 請勿將 private key 貼上至聊天軟體、電子郵件或 ticket 中。只有 public key(即 .pub 檔案)可以被分享。

當你的 key 能穩定登入後,請執行下一步:關閉 password authentication,以防止針對伺服器的暴力破解嘗試。相關的配置方法請參閱 SSH hardening on a VPS

FAQ

SSH keys 如何在不傳送密碼的情況下運作?

伺服器將您的 public key 儲存在 ~/.ssh/authorized_keys。登入時,伺服器會發送一個 challenge,您的 client 使用 private key 對該 challenge 進行簽章,接著伺服器使用 public key 驗證簽章。private key 永遠不會離開您的裝置,因此傳輸過程中沒有內容可被攔截,伺服器上也沒有可被竊取的重複使用資訊。即使伺服器遭入侵,洩漏的也僅是 public keys,無法用於登入其他地方。

我應該在所有伺服器上使用相同的 SSH key 嗎?

只要該 key 僅保留在單一裝置上,在多台伺服器使用同一個 key 是正確的做法。原則是「每個裝置使用一個 key」,而非「每個伺服器使用一個 key」:將您 laptop 的 public key 放入該 laptop 需要登入的所有伺服器,而您的 desktop 則應使用自己的 key。這能簡化撤銷流程,因為遺失裝置只需從每台伺服器中移除一行特定的識別資訊,其他裝置仍可正常運作。

.ssh 目錄與 authorized_keys 的權限應為何?

請對 ~/.ssh 設定 700,並對 600 以及每個 private key 設定 authorized_keys,且所有權必須屬於使用該 key 的帳戶。sshd 預設以 StrictModes yes 執行,因此若檔案或 home directory 允許除您以外的任何人寫入,sshd 會靜默忽略您的 key,唯一的紀錄會顯示在伺服器的 auth log 或 journal 中的 Authentication refused: bad ownership or modes

如何從伺服器移除 SSH key?

從該帳戶的 ~/.ssh/authorized_keys 中刪除該 key 的行。請透過 key 內容後的註解(comment)來尋找正確的行。使用該 key 的新登入會立即失敗,但已開啟的 session 會保持開啟,因此若裝置遺失,請同時結束該裝置的所有活動 session。請在所有曾複製過該 key 的伺服器上重複此操作。

我的 SSH key 需要設定 passphrase 嗎?

若 key 位於 laptop 或 desktop,則需要。passphrase 會加密 key 檔案,因此即使副本被竊或洩漏,單憑該檔案也無法使用;使用 ssh-agent 則代表您每場 session 僅需輸入一次,而非每次連線都要輸入。伺服器上用於 unattended automation 的 key 通常沒有 passphrase,因為現場沒有人類可以輸入;請透過限制目標帳戶的權限來保護這些 key。