SSH 遠端連線教學：金鑰建立、登入操作與錯誤排解

SSH 遠端連線，指的是用 SSH 協定從自己的電腦登入另一台主機，在一條加密通道裡操作遠端系統。它做的事情可以壓成兩件：遠端登入，取得一個文字介面的 shell，以及不進 shell、直接下一道指令讓主機執行。對經營 WordPress 網站的人來說，這是打開主機後端的那串鑰匙：檔案權限改不動、主機商請你用 SSH 執行 WP-CLI、租了 VPS 卻發現根本沒有圖形介面可以點，這些情境全都要從一條 SSH 連線開始。

這套協定的歷史比多數人想的久。維基百科對 SSH 的記載從 1995 年說起：芬蘭研究者 Tatu Ylönen 在校園網路發生密碼側錄事件後設計了 SSH，用來取代把帳號密碼以明文送過網路的 Telnet 與 Berkeley rsh 家族。連接埠 22 這個號碼，當時就刻意選在 Telnet 的 23 與 FTP 的 21 之間。2006 年，SSH-2 成為標準。RFC 4251 說明協定架構，並界定傳輸層、使用者驗證層與連線層的職責。

這份教學按實際動手的順序走：先看懂一條連線裡發生的三件事，確認自己電腦上的客戶端，下第一次連線指令並處理指紋確認，接著建立 SSH 金鑰、把公鑰裝到主機、用設定檔簡化日常連線，後段整理五個常見錯誤的排查方法、基礎安全強化，以及連上主機之後能做些什麼。讀完你會有一把可用的金鑰、一份看得懂的設定檔，以及連不上時的判斷流程。

內容以 OpenSSH 官方手冊、IETF 協定文件（RFC 4251、4252、4253）、Microsoft Learn、GitHub 文件與 NIST 出版品為準，資料分別於 2026 年 9 月 19 日及 9 月 25 日查閱。指令與畫面以 OpenSSH 為準，主機商自行客製的後台畫面可能略有差異，但指令語法與原理相同。文中的主機位址、帳號與連接埠都是示意值，換成主機商提供的那組即可。

SSH 是什麼：在不受信任的網路上加密操作遠端主機

SSH 的全名是 Secure Shell，IETF 在協定架構文件 RFC 4251 裡給它的定義是「在不受信任的網路上，進行安全遠端登入與其他安全網路服務的協定」。拆開來看有兩個關鍵詞。遠端登入，指你人在自己的電腦前，取得另一台機器的操作權。安全，指這條通道上的所有內容都經過加密，經手的設備看不到你輸入的帳號密碼，也看不到你下的指令。OpenBSD 的 ssh(1) 官方手冊對 ssh 這支程式的描述也是同一件事：登入遠端機器並在上面執行指令，目的是在兩台互不信任的主機之間，於不安全的網路上提供加密通訊。

加密對站長的意義可以講得更白。你管理主機的時候，輸入的不只是帳號密碼，還有你下的每道指令、搬的每個檔案。官方對 OpenSSH 的說明把防護對象列得很清楚：加密全部流量，消除竊聽、連線劫持與其他攻擊。在咖啡店的 Wi-Fi 上改網站設定、在共享辦公室重啟服務、透過旅館網路拉一份資料庫備份下來，中間經過的每一台設備理論上都看得到明文流量，SSH 把這條路整段封起來。對需要從終端機管理主機的人來說，這條加密通道是基本配備。

容易混淆的地方先說清楚。SSH 是協定，OpenSSH 是這套協定最普遍的實作，1999 年由 OpenBSD 專案的開發者以開源授權釋出。OpenSSH 官方網站對它的定位是使用 SSH 協定進行遠端登入的首要連線工具，加密所有流量以消除竊聽、連線劫持與其他攻擊。如今它在 macOS、多數 Linux 發行版等常見系統上都有內建，連 Windows 也將它納入系統功能。你在終端機裡輸入的 ssh 指令、主機上等待連線的 sshd 服務、產生金鑰的 ssh-keygen，都是 OpenSSH 套件的一員。實作會改版，官方首頁在 2026 年 8 月 11 日公告的最新版本是 OpenSSH 10.5，協定的基本架構則從 SSH-2 定為標準後保持穩定。

協定本身有兩個版本，規格上區分為 SSH-1 與 SSH-2。SSH-1 有先天設計缺陷，一般認為已過時，應該避免使用並明確停用協定回退。OpenSSH 也早在 7.6 版就把 SSH-1 支援從程式碼庫移除。現在談 SSH，除非特別聲明，指的都是 SSH-2。這對使用者的意義很簡單：市面上主流的客戶端與主機方案，走的都是 SSH-2，不需要在設定裡傷腦筋。

那為什麼一個經營網站的人需要學這個？圖形介面的後台提供哪些操作，取決於主機商的功能與方案。SSH 登入後能取得遠端 shell，在主機上執行指令。檔案權限、日誌、WP-CLI 與資料庫操作能否使用，仍須看帳號權限及主機環境。租用 VPS 或雲端主機時更是如此：你拿到的是一台沒有畫面的機器與一組 IP 位址，初始設定都從一條 SSH 連線開始。站上VPS 主機的介紹談過這類主機的選擇邏輯，這裡補上的是連進去之後那一步。

一條 SSH 連線裡發生的三件事

輸入連線指令到畫面出現提示字元，中間發生的事可以分成三層來理解，這個切法來自協定本身的結構。第一層是傳輸層，負責建立加密通道，並對伺服器做身分驗證，提供機密性與完整性。第二層是使用者驗證層，在已加密的通道裡，向伺服器證明你的身分，用的方法就是後面會實作的密碼或金鑰。第三層是連線層，把加密通道多工成多個邏輯頻道，你在同一條連線裡開 shell、傳檔案、轉發連接埠，各走各的頻道互不干擾。

第一層裡有個新手遲早會撞上的概念：主機金鑰。伺服器第一次被連上時，會用一把主機金鑰向客戶端證明「我就是你要連的那台機器」。客戶端會把這把金鑰記在使用者家目錄的 ~/.ssh/known_hosts 裡，之後每次連線都核對一次。這套機制防的是中間人攻擊：如果有人劫走你的流量、假冒主機，金鑰對不上，客戶端就會擋下來。你第一次連線時看到的那串「指紋是否信任」的確認訊息，就是在決定要不要把這把金鑰寫進 known_hosts。

指紋是主機金鑰的摘要，用途是讓人可以用短短一串字核對一大把鑰匙，核對的是同一個東西。known_hosts 裡記的是你登入過、且不在系統層清單上的主機金鑰。行為上還有一個可以調的選項：StrictHostKeyChecking，官方手冊的說明是它控制遇到金鑰未知或已變更的主機時要不要放行登入。預設行為對新手已經夠安全，第一次問你、變更時擋你，把它改成自動接受全部主機的教學文章不少，那等於把這道防線拆掉，不建議跟做。

傳輸的預設落點是 TCP 連接埠 22。傳輸層協定文件 RFC 4253 記載這個號碼已在 IANA 註冊、正式配置給 SSH，客戶端與伺服器都以它為預設，所以多數教學指令裡看不到連接埠，那是因為走預設。伺服器若改聽其他連接埠，連線時就要帶上指定埠，後面的指令段會示範。連接埠設定與身分驗證是不同的設定，金鑰仍須妥善管理。

「加密」這個詞在網站經營的脈絡裡出現過很多次，位置要擺對。HTTPS 保護的是瀏覽器到網站之間的網頁流量，靠的是站上的 TLS 憑證，這在SSL 憑證的介紹與HTTP 換 HTTPS 的說明裡談得很完整。SSH 保護的則是你與主機之間的操作通道，兩者都做加密，保護的對象不同，也不互相取代：網站要 HTTPS，管主機要 SSH，一個網站經營者兩個都會碰到。

連線之前：確認電腦裡有 SSH 客戶端

SSH 採客戶端與伺服器架構：你這邊跑客戶端程式（指令叫 ssh），主機那邊跑常駐服務（指令叫 sshd），由 sshd 接受遠端連線。連線前也要確認主機端的 sshd 已開放連線，並準備自己電腦上的 SSH 客戶端。各系統的客戶端確認方式如下。

macOS 與多數 Linux 發行版內建 OpenSSH 客戶端，打開終端機就能用，不需要安裝任何東西。Windows 的門檻也不高，依Microsoft 的 OpenSSH 安裝說明，Windows 10 組建 1809 起、Windows Server 2019 起，OpenSSH 客戶端是系統的隨選功能，在設定裡的「選用功能」新增即可。到了 Windows Server 2025，OpenSSH 更改為預先安裝。裝好後建議用一道指令驗收：在終端機輸入 ssh -V，畫面印出 OpenSSH 的版本號就代表客戶端可用，這也是日後回報問題時最先會被問的資訊。

偏好圖形介面的人有替代方案。Windows 生態裡的 PuTTY 是老牌的 SSH 連線工具，檔案管理軟體 WinSCP 便是以 PuTTY 作為後端來處理連線。這類工具把連線資訊做成表單填寫，對不想碰指令列的人比較親切，但原理與指令版完全相同：一樣要填主機、連接埠、帳號，一樣要處理金鑰。教學以指令列為主軸，一來它是跨平台共通的語言，二來主機商文件與自動化腳本寫的都是它。

如果連終端機本身都還陌生，先別急著連線。終端機的路徑概念、指令格式、家目錄的位置，是 SSH 操作的地基，站上的CLI 命令列入門把這層講完了，讀完再回來這份教學，後面每個指令你都會知道自己在做什麼。

第一次連線：指令、指紋確認與 known_hosts

基本連線指令長這樣：ssh [email protected]。@ 前面是主機上的帳號名稱，後面是主機位址（網域或 IP 皆可），協定文件把它寫成 [user@]hostname 的形式，也接受 ssh:// 開頭、把連接埠帶在裡面的 URI 寫法。假設主機商給你的資訊是帳號 whoops、主機 ssh.whoops.example、連接埠 2222，指令就是 ssh -p 2222 [email protected]。-p 用來指定連接埠，不寫就走預設的 22，這個參數也可以寫進設定檔，不必每次輸入。

按下去之後，第一次會先遇到指紋確認。客戶端會告訴你這台主機的身分無法建立，列出一串指紋，問你要不要繼續連線。此時做的事本質上是信任決策：核對這串指紋與主機商提供的指紋是否一致。主機商若在後台或文件裡公布主機金鑰指紋，對得上就輸入 yes 繼續，客戶端會把金鑰存進 known_hosts，之後連線不再問。對不上就停下來，連絡主機商確認，因為那可能是連錯機器，更糟的情況是有人在中間假冒主機。

連線之前把三項資訊先備齊，可以少走很多冤枉路。第一項是帳號，主機商信裡給的那個名稱，共享主機常是一串帳號碼，VPS 則是主機商指定的系統帳號。第二項是主機位址，一個網域或一組 IP。第三項是連接埠，沒特別說明就是 22。這三項對了，連不上才有排查的意義，三項有一項錯，再多的除錯都是繞路。把它們抄在密碼管理器裡，順便記下主機商公布的主機指紋，第一次連線就能直接核對。

通過身分確認後進入驗證階段。OpenSSH 手冊列出的驗證方法有五種：GSSAPI、主機本身驗證、公鑰、鍵盤互動、密碼。一般主機登入實際會遇到的是其中兩種：密碼與公鑰（public key）。密碼驗證時輸入的密碼經過加密通道傳到主機核對，通道上的設備看不到內容，這正是 SSH 相對 Telnet 的根本差異。公鑰驗證則是下一節的主題，也是這份教學建議你走到的位置。

驗證通過後，畫面會跳出遠端主機的歡迎訊息與提示字元，你得到的東西在手冊裡的說法是：一台機器上的正常 shell，一個互動式的操作階段。從這一刻起，你輸入的每個指令都在遠端執行，檔案系統、工作目錄、環境變數全是主機上的。輸入 exit 或按 Ctrl 加 D 離開，回到自己電腦的終端機。也可以不進 shell，直接在連線指令後面接一道指令，例如 ssh -p 2222 [email protected] "wp plugin list"，主機執行完、把輸出傳回來，連線就結束，這種一次性形態在腳本與部署流程裡非常好用。

兩種形態怎麼選，看你要不要「看著它跑」。互動式 shell 適合探索與排查，你可以一邊看檔案、一邊試指令，錯了馬上改。一次性指令適合已經知道要做什麼的重複動作，備份、更新、查狀態，寫成一行放進排程或部署腳本，機器照著跑，不需要人盯。手冊對這兩種形態的區分也簡單：有給指令就在非互動階段執行，沒給就給你一個正常的互動 shell。同一條連線，兩種用法，入門先練互動式，熟了自然會走到一次性。

known_hosts 檔案值得多看一眼。它記錄客戶端已保存的主機金鑰。依預設設定，首次連線須經使用者確認才會加入，是否向主機商核對指紋仍取決於當時的操作。往後若某台主機的身分變了，客戶端會明確警告並停用密碼驗證，防止有人假冒主機騙走密碼。遇到這種警告先別急著照網路文章教學把整個檔案刪掉，後面的排錯段會給判斷流程。

金鑰登入的原理：一把可以大量複製的鎖

密碼登入的弱點很直觀：密碼是你要記住、主機也要核對的字串，攻擊面就是猜測與側錄。公鑰驗證換了一個思路，用的是非對稱加密：加密與解密用不同的鑰匙，而且無法從一把推出另一把。你產生一對金鑰，私鑰（private key）留在自己電腦，公鑰安裝到主機上。官方手冊的描述是：伺服器知道公鑰，只有使用者知道私鑰。登入時，客戶端用私鑰證明持有它，主機核對對應的公鑰是否在獲准清單裡，兩關都過，放行。

「公鑰像鎖、私鑰像鑰匙」是常見的類比，方向是對的，但要補上邊界才不會誤導。實體鎖通常只有一把鑰匙，公鑰可以複製安裝到多台主機，對應私鑰可用於已授權的帳號。私鑰檔案也能被複製。若未設定通關密語，外流後可能被拿來冒用帳號。驗證協定文件 RFC 4252 對這套機制的說法更精確：持有私鑰本身就是身分證明，方法是客戶端用私鑰產生簽章，主機端必須核對兩件事，這把金鑰獲准代表這個帳號，以及簽章有效。私鑰本身不離開你的電腦，離開的只有簽章。

金鑰驗證讓線上猜測失效的原因，藏在「秘密不出門」這件事裡。密碼驗證要把秘密本體送到主機旁邊比對，攻擊者就可以站在旁邊猜，猜中一次就贏。金鑰驗證傳出去的東西是當次的簽章，由客戶端在本地用私鑰產生，主機只驗簽章與授權。攻擊者攔到簽章也推不出私鑰，因為這類演算法的特性就是無法從一把鑰匙推出另一把。所以同樣對外開放登入，密碼可以被字典日夜敲門，金鑰的大門前根本沒有可以敲的鎖孔，攻擊面移轉到「保護那個檔案」上，而檔案在你手裡。

主機端存放獲准公鑰的檔案，是帳號家目錄下的 ~/.ssh/authorized_keys，手冊說明它列出可用於登入這個帳號的公鑰，一行一把金鑰，行可以很長。把公鑰加進這個檔案，之後就能不輸密碼直接登入。整個安裝動作，本質上就是把一行文字加到主機上的一個檔案裡，瞭解這一點，後面不管用哪種工具安裝，你都知道它在做什麼。

↔ 左右捲動檢視完整表格

面向	密碼登入	金鑰登入
驗證依據	你知道的字串	你持有的私鑰檔案
被猜測的風險	弱密碼可被暴力嘗試	驗證需持有私鑰並產生有效簽章
外流後的處置	改密碼即生效	換金鑰對並重裝公鑰
自動化適用性	腳本要處理密碼輸入	私鑰檔直接使用，適合腳本與部署
初始設定成本	無	產生金鑰並安裝公鑰

表的用意在幫你決定要走哪條路，而非宣稱哪條零風險。金鑰把攻擊面從「猜一個字串」變成「拿到一個檔案」，多數情境下這是升級，但私鑰沒有加上通關密語、又放在不安全的地方，等於把身分證放在門口。兩種方式可以並存，伺服器端的密碼驗證預設是開啟的，金鑰裝好、確認能登入之後，再考慮要不要關閉密碼登入，這個動作放在安全強化段談。

建立金鑰對：ssh-keygen 的實際操作

產生金鑰的工具是 ssh-keygen，它在 OpenSSH 套件裡，與 ssh 同進退。演算法的選擇先給結論：用 Ed25519。這是一種現代的橢圓曲線簽章演算法，OpenBSD 的 ssh-keygen(1) 手冊明寫：ssh-keygen 不帶任何參數執行時，產生的就是 Ed25519 金鑰。OpenSSH 客戶端支援的公鑰演算法有三類：ECDSA、Ed25519、RSA，一般使用者從 Ed25519 起步即可。

實際的指令，GitHub 的 SSH 金鑰文件給了標準形態：ssh-keygen -t ed25519 -C "[email protected]"。-t 指定演算法，-C 加上一段註解，方便日後辨認這把金鑰是誰的、做什麼用，金鑰預設的註解格式就是 user@host 這種形式。GitHub 文件同時交代了例外：遇上不支援 Ed25519 的舊系統，改用 ssh-keygen -t rsa -b 4096，也就是 4096 位元的 RSA。舊主機、舊設備還活著的環境會用到這條備援，一般情境用不上。

執行後的第一個提問是存放位置，直接按 Enter 採用預設路徑即可，Linux 與 macOS 上是 ~/.ssh/id_ed25519。公鑰會存成同名檔案加上 .pub 附檔，也就是 ~/.ssh/id_ed25519.pub。兩個檔案的敏感度差很多：私鑰檔含敏感資料，應只有使用者本人能讀。公鑰檔不敏感，誰能讀都無妨，這也是它可以到處安裝的原因。客戶端對此有強制檢查，私鑰權限若開放給其他人存取，ssh 會直接略過這把金鑰，不會拿它去驗證，這是新手常見的地雷，排錯段會再遇到。

接著會問通關密語（passphrase）。它是用來加密私鑰檔裡敏感內容的一道密語，官方手冊建議好的通關密語長度在 10 到 30 個字元之間，不是完整的句子、混合大小寫與符號。可以留空，之後每次用這把金鑰都不用再輸入，方便但少了防線：私鑰若被拷走，對方直接就能用。設了通關密語，私鑰裡的敏感內容被加密，拿到檔案的人還要多過一關。代價是要記住它，而且手冊講得很白：通關密語沒有找回這回事，忘記了只能重產金鑰對，再把新公鑰重裝到各台主機。取捨很個人，對管網站主機的金鑰，建議設。

產生完成後，用 ls ~/.ssh 檢查，應該看到 id_ed25519 與 id_ed25519.pub 兩個檔案（名稱隨演算法不同，RSA 的預設名是 id_rsa）。往後 ssh 連線時，客戶端會自動嘗試預設路徑下的金鑰，不需要額外參數。這也是為什麼按 Enter 採用預設路徑是個好預設：一切自動化。多把金鑰、多種用途的進階管理，交給設定檔處理，兩段之後會講。

什麼時候需要第二把金鑰？常見的分法是按用途：個人主機一把、公司專案一把、提供給第三方服務的部署金鑰再一把。金鑰彼此獨立，一把外流不波及其他，離職或結案時回收也乾淨。產生時在存放位置的提問輸入自訂檔名，例如 ~/.ssh/id_ed25519_work，公鑰一樣會有對應的 .pub 檔。註解欄位此時就是你的標籤，預設的 user@host 之外，加上用途說明，便於辨認金鑰。自訂名稱的金鑰不會被自動嘗試，要在設定檔裡用 IdentityFile 指名，這正好銜接後面的設定檔段落。

把公鑰裝到主機上：兩種方式

私鑰留在家裡，公鑰要出門。安裝的目標前面說過：主機帳號家目錄下的 ~/.ssh/authorized_keys，一行一把金鑰。電腦上若有 ssh-copy-id 工具，可用一行指令安裝公鑰：ssh-copy-id [email protected]，連接埠不同時帶 -p 2222。依上游的 ssh-copy-id(1) 手冊頁，它用本機既有的金鑰授權遠端機器上的登入，預設把公鑰附加進遠端使用者的 ~/.ssh/authorized_keys，必要時連檔案與資料夾都自動建立。跑完用相同連接埠再試一次，例如 ssh -p 2222 [email protected]。若不再要求主機帳號密碼且成功登入，表示公鑰已生效。

Windows 上沒有這支工具時，手動做同樣的事。概念是把公鑰檔的內容，附加到主機上那個檔案的尾端。手動操作時，先登入主機，在主機上執行 mkdir -p ~/.ssh，再將本機公鑰檔的完整內容附加到遠端的 authorized_keys。關鍵是遠端收到本機公鑰檔完整的一行內容。手動貼上也行：在本機用文字編輯器打開 id_ed25519.pub，全選複製，登入主機後貼到 authorized_keys 的新的一行。空行與 # 開頭的行會被視為註解忽略，所以貼錯位置通常不會弄壞整個檔案，但多餘的斷行會讓一把金鑰變成兩行無效內容，貼完要檢查。

安裝後的主機端有幾個權限慣例，出問題時優先檢查。手冊給 .ssh 資料夾與 authorized_keys 的建議權限都是只有使用者本人可讀寫、其他人不可存取，權限開得太大，金鑰驗證可能因此失敗。你本機的 ~/.ssh 資料夾同理，組態檔 ~/.ssh/config 甚至被手冊明文要求嚴格權限。Linux 上用 chmod 700 ~/.ssh 與 chmod 600 ~/.ssh/authorized_keys 對齊，這組數字是「使用者全權、其他人無」的標準形態。

安裝完成後給自己一個驗收動作，順序固定。先完整登出再重新連線，確認以公鑰驗證成功且不再要求主機帳號密碼。若私鑰設有通關密語，仍可能提示輸入。接著換個角度驗：把連線的 -v 打開，看除錯輸出裡客戶端送出的是哪把公鑰、主機回應了什麼，一次看清整條驗證鏈。日後任何時候懷疑「金鑰到底有沒有被用到」，這個畫面就是答案，比猜測或重裝快得多。驗收通過，這台主機之後的連線就交給金鑰，密碼留給主機商後台。

用設定檔簡化日常連線：~/.ssh/config

主機一多，每次連線都要背帳號、位址、連接埠，很快就煩。OpenSSH 的解法是使用者層的組態檔 ~/.ssh/config。它的基本結構是以 Host 開頭的區塊，ssh_config(5) 手冊對它的說明是：區塊內的宣告只套用到符合名稱模式的主機。常用的四個關鍵字是 HostName（實際位址）、User（帳號）、Port（連接埠）、IdentityFile（指定這台主機要用的私鑰檔）。寫好之後，連線指令從 ssh -p 2222 [email protected] 縮短成 ssh whoops，像幫每台主機取了短名。

一個能直接套用的範例，右欄換成你自己的資訊：

↔ 左右捲動檢視完整表格

設定項	作用	範例值
Host	這個區塊的短名，連線時當參數用	whoops
HostName	主機實際位址	ssh.whoops.example
User	登入帳號	whoops
Port	連接埠，預設 22 可省略	2222
IdentityFile	這台主機用的私鑰檔	~/.ssh/id_ed25519

設定檔有兩條規則值得記。第一，優先順序是命令列參數高於 ~/.ssh/config，再高於系統層的 /etc/ssh/ssh_config，而且每個設定項先拿到先贏。第二，因為先贏規則，愈專屬的區塊要放愈前面，通用的預設放最後。手冊還給了一個好用的技巧：用 Host * 當結尾區塊，放所有主機共用的預設值。多把金鑰配多台主機的管理，就是在這個檔案裡完成的。

設了通關密語之後，使用金鑰時可能需要輸入密語。驗證代理器可持有已載入的私鑰，讓 ssh 在登入時使用，減少重複輸入。能存取代理器連線的程式可能使用已載入的金鑰，使用前應確認工作環境的存取範圍。

連不上時怎麼辦：五個常見錯誤的判斷流程

SSH 連線失敗的訊息其實相當誠實，讀懂它省下的時間比想像多。下面五個是新手最常遇到的形態，每個都附判斷方向。排查的通用工具是 -v 參數（要看更多就 -vvv），它讓 ssh 印出連線與驗證過程的除錯訊息，手冊明說這對排查連線、驗證與組態問題有幫助，回報給主機商時附上這段輸出，來回會快很多。

排查時先確認網路與連接埠可達。連上伺服器後，傳輸層先驗證主機身分，再進入使用者驗證，檢查帳號與金鑰。表格依常見訊息列出處理方向。遇到主機金鑰變更警告，應先核對主機身分，再繼續處理登入。

↔ 左右捲動檢視完整表格

訊息形態	常見原因	處理方向
Connection refused	該連接埠上沒有服務在聽，或防火牆擋掉	確認連接埠號碼、主機是否開放 SSH、本機網路是否能出去
Connection timed out	封包到不了主機，IP 防火牆或安全群組未放行	檢查主機商後台的防火牆規則與允許的來源 IP
Permission denied (publickey)	伺服器只收金鑰，而你這邊金鑰不符或未被授權	確認公鑰已裝進 authorized_keys、私鑰權限不過寬、帳號名正確
Permission denied (publickey,password)	金鑰與密碼都被拒	先確認密碼正確，再檢查主機商是否要求先在後台啟用 SSH
REMOTE HOST IDENTIFICATION HAS CHANGED	主機金鑰與 known_hosts 記錄不符	主機重灌或換機是正常原因，先向主機商求證，確認後再更新記錄

前兩個是網路層的問題。Microsoft 的 OpenSSH 文件講得很直白：伺服器安裝時建立的防火牆規則允許連接埠 22 的傳入流量，這條規則沒開、連接埠沒開放，連線就會被拒絕或重置。共享主機的 SSH 功能沒有啟用、VPS 的防火牆沒放行你的連接埠，症狀都落在這一區，先到主機商後台檢查設定，再懷疑其他。

中間兩個是驗證層的問題，關鍵在括號裡的字：括號列的是伺服器願意接受的方法，你沒過其中任何一種。常見的三個真相是公鑰沒裝好（附加時斷行、貼到錯的檔案）、私鑰權限太寬被客戶端拒用、帳號名打錯（主機商給的帳號常不是你以為的那個）。用 -v 跑一次，看客戶端到底試了哪把金鑰、伺服器回了什麼，答案通常就在那幾行。

第五個最值得停下來想。主機金鑰變更的警告，是這套協定在提醒你「這台機器的身分和上次不一樣」。正常原因包括主機重灌、換機、主機商基礎設施調整。不正常的原因是中間人攻擊。官方手冊描述的行為是：主機身分變化時，ssh 會警告並停用密碼驗證，防止假冒主機騙走密碼。所以正確的順序是先向主機商確認真的有變更，拿到新的指紋核對後，再移除 known_hosts 裡那台主機的舊記錄重新連線。照著網路上的速成教學直接整檔刪光 known_hosts 也能解決症狀，但代價是把所有主機的信任基礎一起清掉，等於把門鎖全換掉只為了開一扇門。

基礎安全強化：從兩個設定開始

金鑰登入穩定之後，值得做兩件事把門再關緊一點。第一件是關閉密碼登入。sshd_config(5) 手冊記載伺服器端的 PasswordAuthentication 預設是 yes，也就是密碼登入預設開著。在仍允許密碼驗證、且連接埠可達的主機上，攻擊者可以嘗試猜測密碼。把 PasswordAuthentication 改成 no 並重載 sshd，可關閉這個選項控制的密碼驗證。前提是金鑰已確認可用，否則會把自己鎖在門外，做這個設定前留一條已開啟的連線在旁邊驗證。

第二件是認識 root 登入的預設。PermitRootLogin 的預設值是 prohibit-password，root 可以用金鑰登入，但不能用密碼。這個預設已經擋掉常見的攻擊面，常見的下一步建議是改成 no，理由是讓日常操作走一般帳號、需要時再提權，出錯時爆炸半徑小一些。要不要改取決於你的操作習慣，知道預設在做什麼，比背口訣重要。

動 sshd 設定檔的時候，流程比記憶重要。正確的節奏是：先開一條已連線的工作階段當保險，修改設定，重載服務，開新的連線測試，新的能進、舊的還在，這次修改才算數。若新連線失敗，先用保留的工作階段修正設定，避免失去遠端管理入口。一次只改一個設定項也是紀律，同時動密碼登入與 root 規則，出問題時你分不清是哪一條造成的。

金鑰本身的管理也有紀律。NIST 在 2015 年 12 月出版的IR 7966 裡點出一個產業現實：金鑰式存取的安全管理一直沒有得到應有的重視，這份指引聚焦的正是企業如何管理 SSH 使用者金鑰。個人使用者能做到的版本很簡單：一把金鑰用在一種用途，不再需要的服務就移除對應的公鑰，通關密語保護私鑰檔，私鑰不進雲端硬碟、不進訊息軟體、不借人。

軟體版本是另一個要顧的面向。2023 年研究人員發表了名為 Terrapin 的中間人攻擊手法，影響當時多數 SSH 實作，修補在 OpenSSH 9.6，且要客戶端與伺服器都升級才完整生效。這件事的啟示不在那個特定漏洞，而在「兩邊都要保持新版」的常態：客戶端跟著作業系統更新，伺服器端靠主機商或自己的套件更新，兩邊都不要常年不動。寫作當下 OpenSSH 已到 10.5，問主機商一句「SSH 服務多久更新一次」，答案會告訴你這家主機值不值得把網站託付給它。

連上主機之後：站長實際會用到的場景

通道建立起來，能做的事就多了，OpenSSH 套件本身把遠端操作的工具列為 ssh、scp、sftp 三件。對 WordPress 站長，第一個實用場景是檔案傳輸：SFTP 經 SSH 傳輸檔案，與 FTP 的差別、客戶端怎麼選，站上的FTP 檔案上傳教學有完整比較，能使用 SFTP 時可優先選用。

第二個場景是遠端執行指令，也就是前面示範過的一次性形態。把指令接在連線後面，主機執行完就斷線，特別適合放進腳本：檢查磁碟用量、重啟服務、跑資料庫備份、執行 WP-CLI 的更新與搜尋取代。部署腳本也可利用 ssh 在遠端主機執行指定指令，執行內容與觸發方式則由實際部署流程決定。習慣之後你會發現，很多原本開後台點半天的操作，變成一行可以重複執行的文字。

把例行維運攤開看，SSH 的角色會更具體。連上主機，先看磁碟用量，快滿了就清暫存。再看網站日誌的尾巴，有沒有奇怪的錯誤峰值。跑一次外掛更新清單，該更新的更新，更新完看網站還活著，收尾時拉一份資料庫備份到自己電腦。整段流程可以在 shell 裡逐步執行，指令輸出可存檔、比對與分享。

第三個場景是網站維運的疑難排除。流量異常時看即時日誌、佈景更新後白屏時看 PHP 錯誤訊息、搬家時直接在主機之間搬資料不繞道自己的電腦。網站搬家到新主機的教學可供後續參考，這裡先準備 SSH 連線與金鑰。通道還能轉發任意 TCP 連線（例如把遠端資料庫的連接埠接到本機來用），屬於進階用途，這裡點到為止，需要時再深入。

如果你是從共享主機起步，SSH 的開放程度取決於主機商方案，登入後台找 SSH 或 Terminal 相關設定，通常能找到主機商提供的專屬連線資訊與指引，A2 Hosting 的主機評價那篇提過它家在這方面的作法，可以當作範例。往 VPS 或雲端走，SSH 就是主要的操作介面，沒有包好的網站後台，這也是為什麼值得早點把這套基本功練起來。

把這套基本功練成自己的

回顧整條路徑：理解 SSH 是加密的遠端操作通道，確認客戶端，用 ssh 帳號@主機連上第一次，通過指紋確認，產生 Ed25519 金鑰對，把公鑰裝進 authorized_keys，用 ~/.ssh/config 給主機取短名，連不上時用 -v 讀懂錯誤。每一步都有官方文件背書，每一步的產出都可以驗證，這是它適合自學的原因。

建議的練法是拿一台便宜或免費的主機當沙盒，把這份教學的每道指令各跑一次，弄壞了重建就好。熟練之後，終端機、SSH、WP-CLI 會連成一條完整的網站維運工作線，從改檔案權限到搬整個網站都不假手圖形介面。工具會不停改版，加密通道、金鑰對、設定檔這三個概念不會，投資在這裡的時間會一直陪伴你。

常見問題