对于安全性和远程访问，我们已经多次赞扬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远程复制文件，而无需输入密码。在那里，您将了解更多关于其他类型的加密算法以及如何使用密钥文件来提高安全性。