對於安全性和遠端訪問，我們已經多次讚揚SSH的優點。讓我們來看看伺服器本身，一些重要的“維護”方面，以及一些可能會給原本平穩的執行帶來混亂的怪癖。

雖然我們在編寫本指南時考慮到了Linux，但這也可以透過Cygwin應用於macosx和windows7中的OpenSSH。

為什麼安全

我們已經多次提到SSH是一種很好的安全連線和隧道資料的方法。讓我們簡單地看看事情是如何運作的，這樣你就能更好地理解為什麼事情有時會變得怪異。

當我們決定啟動與另一臺計算機的連線時，我們通常使用易於使用的協議。Telnet和FTP都出現在我的腦海中。我們將資訊傳送到遠端伺服器，然後得到連線的確認。為了建立某種型別的安全，這些協議通常使用使用者名稱和密碼的組合。那意味著他們完全安全了，對吧？錯了！

如果我們認為我們的連線過程是郵件，那麼使用FTP和Telnet之類的東西就不同於使用標準的郵寄信封。更像是用明信片。如果有人碰巧站在中間，他們可以看到所有的資訊，包括通訊員的地址和傳送的使用者名稱和密碼。然後，他們可以改變資訊，保持資訊不變，並模仿一個或另一個通訊員。這就是所謂的“中間人”攻擊，它不僅會損害您的帳戶，而且會使傳送的每一條訊息和接收的檔案都受到質疑。你不能確定你是否在和發信人交談，即使你是，你也不能確定沒有人從這兩者之間看任何東西。

現在，讓我們看一下SSL加密，它使HTTP更加安全。在這裡，我們有一個處理信件的郵局，負責檢查你的收件人是否是他或她自稱的人，並且有法律保護你的郵件不被人看到。總的來說，它更安全，而且中央機構（Verisign就是其中之一，例如HTTPS）確保您要向其傳送郵件的人簽出郵件。他們不允許使用明信片（未加密的憑證），而是要求使用真正的信封。

最後，讓我們看看SSH。這裡的設定有點不同。我們這裡沒有中央驗證器，但事情還是安全的。那是因為你在給一個你已經知道地址的人寫信——比如說，透過電話聊天——而你在用一些非常花哨的數學在信封上簽名。你把它交給你的兄弟、女朋友、爸爸或女兒，讓他們把它送到地址，只有當收件人的數學匹配時，你才會認為地址是它應該是的。然後，你得到一封信回來，也保護從窺探的眼睛這個可怕的數學。最後，你把你的證書放在另一個祕密的演算法魔法信封裡送到目的地。如果數學不匹配，我們可以假設原始收件人已移動，我們需要再次確認他們的地址。

只要有解釋，我們想我們就到此為止。如果你有更深入的見解，當然可以在評論中隨意聊天。現在，讓我們看看SSH最相關的特性，主機身份驗證。

主機金鑰

主機身份驗證本質上是你信任的人拿走信封（用魔法數學密封）並確認收件人地址的部分。這是一個相當詳細的地址描述，它是基於一些複雜的數學，我們將跳過的權利。不過，要從中吸取一些重要的東西：

1. 由於沒有中央許可權，真正的安全性在於主機金鑰、公鑰和私鑰。（後兩個鍵是在您有權訪問系統時配置的。）
2. 通常，當您透過SSH連線到另一臺計算機時，會儲存主機金鑰。這使得將來的操作更快（或者更不冗長）。
3. 如果主機金鑰發生更改，您很可能會收到警報，您應該提高警惕！

由於主機金鑰是在身份驗證之前用來建立SSH伺服器的標識的，因此在連線之前應該確保檢查金鑰。您將看到如下確認對話方塊。

不過，你不必擔心！通常，當考慮到安全性時，會有一個特殊的地方可以確認主機金鑰（上面的ECDSA指紋）。在完全線上的風險投資中，它通常是在一個只允許安全登入的網站上。你可能不得不（或選擇！）請致電您的IT部門以透過電話確認此金鑰。我甚至聽說過一些地方，鑰匙在你的工作徽章上，或者在特殊的“緊急電話”清單上。而且，如果你有物理訪問目標機器，你也可以自己檢查！

檢查系統的主機金鑰

有4種類型的加密演算法用於生成金鑰，但是今年早些時候OpenSSH的預設值是ECDSA（有一些很好的理由）。今天我們將集中討論這個問題。以下是您可以在有權訪問的SSH伺服器上執行的命令：

ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l

您的輸出應該返回如下內容：

256 ca:62:ea:7c:e4:9e:2e:a6:94:20:11:db:9c:78:c3:4c /etc/ssh/ssh_host_ecdsa_key.pub

第一個數字是金鑰的位長，然後是金鑰本身，最後是儲存在其中的檔案。將中間部分與提示您遠端登入時看到的內容進行比較。應該匹配，你們都準備好了。如果沒有，那麼其他事情可能會發生。

透過檢視已知的\u hosts檔案，可以檢視透過SSH連線到的所有主機。通常位於：

~/.ssh/known_hosts

您可以在任何文字編輯器中開啟該選項。如果你看，試著注意如何儲存金鑰。它們儲存在主機名（或web地址）及其IP地址中。

更改主機金鑰和問題

主機金鑰更改或與已知的\u hosts檔案中記錄的內容不匹配的原因有很多。

• 系統已重新安裝/重新配置。
• 由於安全協議，主機金鑰被手動更改。
• 由於安全問題，OpenSSH伺服器已更新並使用不同的標準。
• IP或DNS租約已更改。這通常意味著您正在嘗試訪問另一臺計算機。
• 系統以某種方式遭到破壞，導致主機金鑰發生更改。

很可能，問題是前三個問題之一，您可以忽略更改。如果IP/DNS租約更改，則伺服器可能有問題，您可能被路由到其他計算機。如果您不確定更改的原因是什麼，那麼您可能應該假設它是列表中的最後一個。

openssh如何處理未知主機

OpenSSH有一個如何處理未知主機的設定，反映在變數“StrictHostKeyChecking”（不帶引號）中。

根據您的配置，與未知主機（其金鑰不在已知的\u hosts檔案中）的SSH連線可以有三種方式。

• StrictHostKeyChecking設定為no；OpenSSH將自動連線到任何SSH伺服器，而不管主機金鑰狀態如何。這是不安全的，不建議這樣做，除非在重新安裝作業系統後新增一堆主機，然後將其更改回來。
• StrictHostKeyChecking設定為ask；OpenSSH將顯示新的主機金鑰，並在新增它們之前請求確認。它將阻止連線到已更改的主機金鑰。這是預設值。
• StrictHostKeyChecking設定為yes；與“no”相反，這將阻止您連線到已知的\u hosts檔案中尚未存在的任何主機。

您可以使用以下範例在命令列上輕鬆更改此變數：

ssh -o 'StrictHostKeyChecking [option]' user@host

將[option]替換為“no”、“ask”或“yes”。請注意，此變數及其設定周圍有單引號。同時更換使用者@主機使用您要連線的伺服器的使用者名稱和主機名。例如：

ssh -o 'StrictHostKeyChecking ask' [email protected]

由於金鑰更改而阻止主機

如果您試圖訪問的伺服器的金鑰已經更改，則預設的OpenSSH配置將阻止您訪問它。您可以更改該主機的StrictHostKeyChecking值，但這並不是完全、徹底、偏執地安全的，不是嗎？相反，我們可以簡單地從已知的\u hosts檔案中刪除有問題的值。

這絕對是一個醜陋的東西在你的螢幕上。幸運的是，我們這樣做的原因是重新安裝了作業系統。所以，讓我們放大我們需要的線。

就這樣。看看它是如何引用我們需要編輯的檔案的？它甚至給了我們行號！那麼，讓我們用Nano開啟這個檔案：

這是我們的關鍵，在第一行。我們需要做的就是按Ctrl+K來剪下整條線。

好多了！所以，現在我們按Ctrl+O寫出（儲存）檔案，然後按Ctrl+X退出。

現在我們得到一個很好的提示，我們可以簡單地回答“是”

建立新主機金鑰

記錄下來，你根本沒有太多理由改變主機金鑰，但是如果你發現需要，你可以輕鬆地做。

首先，更改到相應的系統目錄：

cd /etc/ssh/

這通常是全域性主機金鑰所在的位置，儘管有些發行版將它們放在了其他地方。如有疑問，請檢視您的文件！

接下來，我們將刪除所有舊金鑰。

sudo rm /etc/ssh/ssh_host_*

或者，您可能希望將它們移動到一個安全的備份目錄。只是一個想法！

然後，我們可以告訴OpenSSH伺服器重新配置自己：

sudo dpkg-reconfigure openssh-server

當您的計算機建立新的鍵時，您將看到一個提示。嗒嗒！

既然您對SSH的工作原理有了更好的瞭解，那麼您應該能夠擺脫困境。“遠端主機標識已更改”警告/錯誤會讓很多使用者感到厭煩，甚至是那些熟悉命令列的使用者。

另外，您還可以檢視如何透過SSH遠端複製檔案，而無需輸入密碼。在那裡，您將瞭解更多關於其他型別的加密演算法以及如何使用金鑰檔案來提高安全性。