了解Linux PC上OpenSSH的来龙去脉

We’ve extolled the virtues of SSH numerous times, for both security and remote access. Let’s take a look at the server itself, some important “maintenance” aspects, and some quirks that can add turbulence to an otherwise smooth ride.

对于安全性和远程访问，我们已经多次赞扬SSH的优点。 让我们看一下服务器本身，一些重要的“维护”方面以及一些怪异现象，这些怪异现象会使原本顺畅的旅程更加混乱。

While we’ve written this guide with Linux in mind, this can also apply to OpenSSH in Mac OS X and Windows 7 via Cygwin.

尽管我们已经考虑到Linux编写了本指南，但它也可以通过Cygwin应用于Mac OS X和Windows 7中的 OpenSSH。

为什么安全 (Why It’s Secure)

We’ve mentioned many times how SSH is a great way to securely connect and tunnel data from one point to another. Let’s take a very brief look at how things work so you get a better idea of why things can go weird sometimes.

我们已经多次提到SSH是一种将数据安全地从一个点安全地连接到另一个点的绝佳方法。 让我们简要地看一下事情是如何工作的，以便您更好地了解为什么有时候事情会变得怪异。

When we decide to initiate a connection to another computer, we often use protocols that are easy to work with. Telnet and FTP both come to mind. We send out information to a remote server and then we get confirmation back about our connection. In order to establish some type of safety, these protocols often use username and password combinations. That means they’re totally secure, right? Wrong!

当我们决定启动与另一台计算机的连接时，我们经常使用易于使用的协议。 Telnet和FTP都可以想到。 我们将信息发送到远程服务器，然后获得有关连接的确认。 为了建立某种类型的安全性，这些协议经常使用用户名和密码组合。 那意味着它们是完全安全的，对吗？ 错误！

If we think of our connecting process as mail, then using FTP and Telnet and the like isn’t like using standard mailing envelopes. It’s more like using postcards. If someone happens to step in the middle, they can see all of the information, including the addresses of both correspondents and the username and password sent out. They can then change the message, keeping the information the same, and impersonate one correspondent or the other. This is known as a “man-in-the-middle” attack, and not only does it compromise your account, but it calls into question each and every message sent and file received. You can’t be sure if you’re talking to the sender or not, and even if you are, you can’t be sure no one’s looking at everything from in between.

如果我们将连接过程视为邮件，则使用FTP和Telnet等方法与使用标准邮件信封不同。 这更像是使用明信片。 如果有人碰巧走到中间，他们可以看到所有信息，包括两个通讯员的地址以及发送的用户名和密码。 然后，他们可以更改消息，使信息保持不变，并假冒一个通讯员或另一个通讯员。 这被称为“中间人”攻击，它不仅会危害您的帐户，而且还会对发送的每条消息和收到的文件产生疑问。 您无法确定是否在与发件人交谈，即使您在与发件人交谈，也不能确保没有人在中间查看所有内容。

Now, let’s look at SSL encryption, the kind that makes HTTP more secure. Here, we have a post office that handles the correspondence, who checks to see if your recipient is who he or she claims to be, and has laws protecting your mail from being looked at. It’s more secure overall, and the central authority – Verisign is one, for our HTTPS example – makes sure that the person who you’re sending mail to checks out. They do this by not allowing postcards (unencrypted credentials); instead they mandate real envelopes.

现在，让我们看一下SSL加密，它使HTTP更加安全。 在这里，我们有一个邮局负责处理该信件，该邮局负责检查您的收件人是否是他或她声称的身份，并且有法律保护您的邮件免遭查看。 总体而言，它更安全，并且中央机构(对于我们的HTTPS示例来说，Verisign是其中的一个)确保您发送邮件的人可以签出。 他们通过不允许使用明信片(未加密的凭据)来做到这一点； 相反，他们要求使用真实的信封。

Finally, let’s look at SSH. Here, the setup is a little different. We don’t have a central authenticator here, but things are still secure. That’s because you’re sending letters to someone whose address you already know – say, by chatting with them on the telephone – and you’re using some really fancy math to sign your envelope. You hand it over to your brother, girlfriend, dad, or daughter to take it to the address, and only if the recipient’s fancy math matches do you assume that the address is what it should be. Then, you get a letter back, also protected from prying eyes by this awesome math. Finally, you send your credentials in another secretive algorithmically-enchanted envelope to the destination. If the math doesn’t match, we can assume that the original recipient moved and we need to confirm their address again.

最后，让我们看一下SSH。 在这里，设置有些不同。 我们这里没有中央验证器，但是事情仍然很安全。 这是因为您正在向已知地址的人发送信件(例如，通过在电话上与他们聊天)，并且您正在使用一些非常喜欢的数学来对信封签名。 您将其交给您的兄弟，女朋友，父亲或女儿，然后将其带到该地址，只有在收件人的花式数学匹配时，您才认为该地址应该是该地址。 然后，您会收到一封回信，并且通过这种出色的数学也可以保护自己免遭窥视。 最后，您将凭据通过另一个由算法保护的秘密信封发送到目的地。 如果数学不匹配，我们可以假定原始收件人已移动，我们需要再次确认其地址。

With the explanation as long as it is, we think we’ll cut it there. If you have some more insight, feel free to chat in the comments, of course. For now, though, let’s look at the most relevant feature of SSH, host authentication.

只要有足够的解释，我们认为我们将在此处进行解释。 如果您有更多的见解，请随时在评论中聊天。 不过，现在让我们看一下SSH最相关的功能，即主机身份验证。

主机密钥 (Host Keys)

Host authentication is essentially the part where someone you trust takes the envelope (sealed with magic math) and confirms the address of your recipient. It’s a pretty detailed description of the address, and it’s based on some complicated math that we will just skip right over. There are a couple of important things to take away from this, though:

主机身份验证本质上是您信任的人拿信封(用魔术数学密封)并确认收件人地址的部分。 这是一个非常详细的地址描述，它基于一些复杂的数学运算，我们将直接跳过。 但是，有两点重要的事情可以解决：

1. Since there is no central authority, the real security lies in the host key, the public keys and the private keys. (These latter two keys are configured when you’re given access to the system.)
   由于没有中央权限，因此真正的安全性在于主机密钥，公共密钥和私有密钥。 (后两个键是在您有权访问系统时配置的。)
2. Usually, when you connect to another computer via SSH, the host key is stored. This makes future actions faster (or less verbose).
   通常，当您通过SSH连接到另一台计算机时，将存储主机密钥。 这样可以使以后的操作更快(或更少冗长)。
3. If the host key changes, you will most likely be alerted and you should be wary!
   如果主机密钥发生更改，您很可能会收到警报，因此请当心！

Since the host key is used before authentication to establish the identity of the SSH server, you should be sure to check the key before you connect. You will see a confirmation dialog like below.

由于在身份验证之前使用了主机密钥来建立SSH服务器的身份，因此在连接之前，请务必检查密钥。 您将看到如下所示的确认对话框。

You shouldn’t worry, though! Often when security is a concern, there will be a special place that the host key (ECDSA fingerprint above) can be confirmed. In entirely online ventures, often it will be on a secure log-in only site. You may have to (or choose to!) phone your IT department to confirm this key over the phone. I’ve even heard of some places where the key is on your work badge or on the special “Emergency Numbers” list. And, if you have physical access to the target machine, you can also check for yourself!

不过，您不必担心！ 通常，出于安全考虑，会在一个特殊的地方确认主机密钥(上面的ECDSA指纹)。 在完全在线的企业中，通常会在仅安全登录的站点上进行。 您可能必须(或选择！)致电您的IT部门以通过电话确认此密钥。 我什至听说过某些地方的钥匙在您的工作证上或特殊的“紧急电话”列表上。 而且，如果您可以物理访问目标计算机，则还可以自己检查一下！

检查系统的主机密钥 (Checking Your System’s Host Key)

There are 4 types kinds of encryption algorithms used to make keys, but the default for OpenSSH as of earlier this year is ECDSA (with some good reasons). We’ll focus on that one today. Here’s the command you can run on the SSH server you have access to:

有四种类型的加密算法可用于制作密钥，但截至今年早些时候，OpenSSH的默认算法是ECDSA( 有充分的理由 )。 今天我们将重点讨论这一点。 这是您可以在有权访问的SSH服务器上运行的命令：

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

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

Your output should return something like this:

您的输出应返回如下内容：

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

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

The first number is the bit-length of the key, then is the key itself, and finally you have the file it’s stored in. Compare that middle portion to what you see when you’re prompted to log in remotely. It should match, and you’re all set. If it doesn’t, then something else could be happening.

第一个数字是密钥的位长，然后是密钥本身，最后是文件的存储位置。将中间部分与系统提示您远程登录时看到的部分进行比较。 它应该匹配，您已经准备就绪。 如果没有，那么可能正在发生其他事情。

You can view all of the hosts you have connected to via SSH by looking at your known_hosts file. It is usually located at:

您可以通过查看known_hosts文件来查看通过SSH连接到的所有主机。 它通常位于：

~/.ssh/known_hosts

〜/ .ssh / known_hosts

You can open that in any text editor. If you look, try to pay attention to how keys are stored. They’re stored with the host computer’s name (or web address) and its IP address.

您可以在任何文本编辑器中打开它。 如果您看，请尝试注意密钥的存储方式。 它们与主机的名称(或网址)及其IP地址一起存储。

更改主机密钥和问题 (Changing Host Keys and Problems)

There are a few reasons why host keys change or they don’t match what is logged in your known_hosts file.

主机密钥更改的原因有几个，或者它们与您的known_hosts文件中记录的内容不匹配。

• The system was re-installed/re-configured.
  系统已重新安装/重新配置。
• The host keys were manually changed due to security protocols.
  主机密钥由于安全协议而被手动更改。
• The OpenSSH server updated and is using different standards due to security issues.
  由于安全问题，OpenSSH服务器已更新，并使用不同的标准。
• The IP or DNS lease changed. This often means you’re trying to access a different computer.
  IP或DNS租约已更改。 这通常意味着您正在尝试访问其他计算机。
• The system was compromised in some way such that the host key changed.
  系统以某种方式被破坏，因此主机密钥已更改。

Most likely, the issue is one of the first three, and you can ignore the change. If the IP/DNS lease changed, then there may be an issue with the server and you may be routed to a different machine. If you’re not sure what the reason for the change is then you should probably assume it’s the last one on the list.

该问题很可能是前三个问题之一，您可以忽略此更改。 如果IP / DNS租约已更改，则服务器可能有问题，您可能会被路由到其他计算机。 如果您不确定更改的原因是什么，那么您可能应该假设它是列表中的最后一个。

OpenSSH如何处理未知主机 (How OpenSSH Handles Unknown Hosts)

OpenSSH has a setting for how it handles unknown hosts, reflected in the variable “StrictHostKeyChecking” (without quotes).

OpenSSH有一个如何处理未知主机的设置，反映在变量“ StrictHostKeyChecking”(不带引号)中。

Depending on your configuration, SSH connections with unknown hosts (whose keys aren’t already in your known_hosts file) can go three ways.

根据您的配置，与未知主机(其密钥尚未在known_hosts文件中)的SSH连接可以通过三种方式进行。

• StrictHostKeyChecking is set to no ; OpenSSH will automatically connect to any SSH server regardless of host key status. This is insecure and not recommended, except if you’re adding a bunch of hosts after a reinstall of your OS, after which you will change it back.
  StrictHostKeyChecking设置为no； 无论主机密钥状态如何，OpenSSH都会自动连接到任何SSH服务器。 这是不安全的，因此不建议这样做，除非重新安装操作系统后要添加一堆主机，然后再将其改回。
• StrictHostKeyChecking is set to ask ; OpenSSH will show you new host keys and ask for confirmation before adding them. It will prevent connections from going to changed host keys. This is the default.
  StrictHostKeyChecking设置为ask; OpenSSH将向您显示新的主机密钥，并在添加密钥之前进行确认。 这将防止连接进入更改的主机密钥。 这是默认值。
• StrictHostKeyChecking is set to yes ; The opposite of “no,” this will prevent you from connecting to any host that is not already present in your known_hosts file.
  StrictHostKeyChecking设置为yes； 与“ no”相反，这将阻止您连接到known_hosts文件中尚未存在的任何主机。

You can change this variable easily on the command-line by using the following paradigm:

您可以使用以下范例在命令行上轻松更改此变量：

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

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

Replace [option] with “no,” “ask,” or “yes.” Be aware that there are single straight quotes surrounding this variable and its setting. Also replace user@host with the username and host name of the server you’re connecting to. For example:

将[选项]替换为“否”，“询问”或“是”。 请注意，此变量及其设置周围有单引号。 另外，将user @ host替换为您要连接的服务器的用户名和主机名。 例如：

ssh -o 'StrictHostKeyChecking ask' yatri@192.168.1.50

ssh -o 'StrictHostKeyChecking ask' yatri@192.168.1.50

密钥更改导致主机被阻止 (Blocked Hosts Due To Changed Keys)

If you have a server you’re trying to access that had its key already changed, the default OpenSSH configuration will prevent you from accessing it. You could change the StrictHostKeyChecking value for that host, but that wouldn’t be entirely, thoroughly, paranoidly secure, would it? Instead, we can simply remove the offending value from our known_hosts file.

如果您要访问的服务器的密钥已更改，则默认的OpenSSH配置将阻止您访问它。 您可以更改该主机的StrictHostKeyChecking值，但这不是完全，彻底，偏执的安全吗？ 相反，我们可以简单地从我们的known_hosts文件中删除有问题的值。

That’s definitely an ugly thing to have on your screen. Luckily, our reason for this was a reinstalled OS. So, let’s zoom in on the line we need.

在屏幕上绝对是一件丑陋的事情。 幸运的是，我们这样做的原因是重新安装了操作系统。 因此，让我们放大所需的行。

There we go. See how it cites the file we need to edit? It even gives us the line number! So, let’s open up that file in Nano:

好了 看看它如何引用我们需要编辑的文件？ 它甚至给我们行号！ 因此，让我们在Nano中打开该文件：

Here’s our offending key, in line 1. All we need to do is hit Ctrl + K to cut out the whole line.

这是我们第1行中令人讨厌的键。我们所要做的就是按Ctrl + K剪切出整行。

That’s much better! So, now we hit Ctrl + O to write out (save) the file, then Ctrl + X to exit.

那好多了！ 因此，现在我们按Ctrl + O可以写出(保存)文件，然后按Ctrl + X可以退出。

Now we get a nice prompt instead, to which we can simply respond with “yes.”

现在，我们得到一个不错的提示，我们可以简单地回答“是”。

创建新的主机密钥 (Creating New Host Keys)

For the record, there’s really not too much of a reason for you to change your host key at all, but if you ever find the need, you can do easily.

根据记录，您根本没有太多理由更改主机密钥，但是如果您发现需要，可以轻松进行。

First, change to the appropriate system directory:

首先，转到相应的系统目录：

cd /etc/ssh/

cd / etc / ssh /

This is usually where the global host keys are, though some distros have them placed elsewhere. When in doubt check your documentation!

通常，这是全局主机密钥所在的位置，尽管某些发行版将其放置在其他位置。 如有疑问，请检查您的文档！

Next, we’ll delete all of the old keys.

接下来，我们将删除所有旧密钥。

sudo rm /etc/ssh/ssh_host_*

须藤rm / etc / ssh / ssh_host_ *

Alternatively, you may want to move them to a safe backup directory. Just a thought!

或者，您可能希望将它们移至安全备份目录。 只是一个想法！

Then, we can tell OpenSSH server to reconfigure itself:

然后，我们可以告诉OpenSSH服务器重新配置自身：

sudo dpkg-reconfigure openssh-server

须藤dpkg重新配置openssh服务器

You’ll see a prompt while your computer creates its new keys. Ta-da!

在计算机创建新密钥时，您会看到提示。 -

---

---

Now that you know how SSH works a little bit better, you should be able to get yourself out of tough spots. The “Remote Host Identification Has Changed” warning/error is something that throws a lot of users off, even those who are familiar with the command-line.

既然您知道SSH的工作原理要好一点，那么您应该可以摆脱困境。 “远程主机标识已更改”警告/错误是使许多用户(甚至是那些熟悉命令行的用户)离开的原因。

For bonus points, you can check out How To Remotely Copy Files Over SSH Without Entering Your Password. There, you’ll learn a little more about the other kinds of encryption algorithms and how to use key files for added security.

对于奖励积分，您可以查看如何通过SSH远程复制文件而无需输入密码 。 在这里，您将学到更多有关其他类型的加密算法以及如何使用密钥文件来增强安全性的知识。

翻译自: https://www.howtogeek.com/74827/learn-the-ins-and-out-of-openssh-on-your-linux-pc/