在昨天的文章中，我們用 UFW 防火牆關上了主機所有不必要的通訊埠，只保留了 22 號 Port（SSH）作為遠端連線的管理通道。
回顧在Day 16時，我們在本機生成了 SSH 金鑰並部署到主機上，實現了「免輸入密碼直接登入」。然而，當時的設定本質上是為了開發便利，伺服器處於「金鑰與密碼雙軌並行」的狀態—也就是說，就算沒有金鑰，任何人只要連上 22 號 Port，依然能透過輸入使用者密碼嘗試登入。
只要密碼通道還開著，暴露在外的伺服器就永遠面臨自動化機器人的暴力破解與字典檔猜測風險。今天這篇的目標，就是進行伺服器系統層級的安全收斂：驗證既有金鑰健全度，並在伺服器端徹底停用密碼登入機制。

1.Day 16 與 Day 26 的差異

2.檢驗既有金鑰連線與權限
(1)在本機終端機測試連線
在 Windows PowerShell或命令提示字元（CMD）中執行：

ssh -p 2222 ithome@127.0.0.1

• 正常情況：無需輸入 Linux 密碼，直接進入終端機提示字元。

(2)確認伺服器端授權檔權限規範
OpenSSH 具備嚴格的權限安全機制，請登入虛擬機檢查權限是否合規：

# 確保目錄權限為 700（僅擁有者可讀寫執行）
chmod 700 ~/.ssh
# 確保授權金鑰檔案權限為 600（僅擁有者可讀寫）
chmod 600 ~/.ssh/authorized_keys

3.伺服器端強制停用密碼驗證
確認金鑰登入正常後，我們進入系統層級，徹底關閉密碼認證通道。

修改 SSH 設定時，請保持目前已經連線成功的終端機視窗開啟，切勿關閉！這樣萬一組態設定有誤，還能在既有連線中即時修正。

(1)編輯 SSH 伺服器設定檔
在 Ubuntu 連線視窗中執行：

sudo nano /etc/ssh/sshd_config

(2)調整認證策略參數
檢索並修改以下設定項（若前面有 # 註解符號請移除）：

# 啟用公鑰認證機制
PubkeyAuthentication yes
# 徹底停用使用者密碼認證
PasswordAuthentication no
# 停用空密碼登入
PermitEmptyPasswords no
# 停用基於 PAM 的鍵盤互動式挑戰認證
KbdInteractiveAuthentication no

修改完成後，按下 Ctrl + O ➔ Enter 存檔，再按 Ctrl + X 離開編輯器。
(3)重新載入 SSH 服務
執行以下指令套用新設定：

sudo systemctl restart ssh

4.雙重驗證安全性
(1)確認既有金鑰仍能正常通行
不要關閉剛才的視窗，在 Windows 電腦上另開一個全新的 PowerShell 或 CMD 視窗執行：

ssh -p 2222 ithome@127.0.0.1

• 預期結果：依然能免密碼馬上登入，代表金鑰通行無阻。

(2)模擬無金鑰攻擊，驗證密碼通道是否徹底封閉
在新的視窗中加上 -o PubkeyAuthentication=no 參數，強制忽略本機金鑰，模擬未授權設備試圖用密碼連入：

ssh -p 2222 -o PubkeyAuthentication=no ithome@127.0.0.1

• 預期結果：
  
  伺服器直接拒絕連線，完全不給任何輸入密碼的機會，這證明密碼認證通道已成功封閉。

如果不小心手滑把密碼關了，金鑰又失效連不進去怎麼辦？

• 救援方式：因為是在 VirtualBox 本機虛擬化環境，只要點開 VirtualBox 虛擬機的原生桌面視窗，開啟原生終端機輸入：

sudo nano /etc/ssh/sshd_config

(將 PasswordAuthentication 暫時改回 yes，再執行 sudo systemctl restart ssh，即可救回連線。)

|明日目標：將進入「系統日常監控與排錯篇」，學習如何使用 htop、df 與 free 掌握伺服器的 CPU、記憶體與磁碟空間，隨時監控背景服務的運行健康度！|