linux - ssh 登录服务器的指纹如何获取、验证，以及除了中间人攻击外什么操作会改变服务器指纹？

Question

事情由来：

登录自己的vps时提示REMOTE HOST IDENTIFICATION HAS CHANGED!。
显示如下

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:sYNNR1L6T5cSEG4BndqtCDhJEI0eB9LamBTkuIue3+0.
Please contact your system administrator.
Add correct host key in /Users/xx/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /Users/xx/.ssh/known_hosts:40
ECDSA host key for [xx.com] has changed and you have requested strict checking.
Host key verification failed.

提示有被中间人攻击的风险，那么除了被中间人攻击的情况下，还有那些变动会造成这样的变动？(ssh连接的加密方式变化了，比如我发现 known_hosts 文件中有的主机信息是 ssh-rsa 有的是 ecdsa-sha2-nistp256，那么软件升级会改变连接加密方式吗？我自己没有动过)

还有其中提到了指纹信息

The fingerprint for the ECDSA key sent by the remote host is
SHA256:sYNNR1L6T5cSEG4BndqtCDhJEI0eB9LamBTkuIue3+0.

这种指纹信息在第一次ssh登录服务器的时候也会提示

The authenticity of host [xx.com] can't be established.
ECDSA key fingerprint is SHA256:sYNNR1L6T5cSEG4BndqtCDhJEI0eB9LamBTkuIue3+0.
Are you sure you want to continue connecting (yes/no)?

那么这个指纹信息是要验证的，怎么验证？
（我猜有很大比例的人应该都会像安装软件下一步一样，并不清楚怎么对比，就直接信任了）

append:查找了一些资料，How to get ssh server fingerprint information，都提到了类似的内容，但是和上面显示的 fingerprint 不一样呀。

> ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub
256 0d:df:2b:e4:ee:79:f2:98:ab:38:93:f3:44:1d:c5:4d  root@doceanm-xxx.localdomain (ECDSA)

那么他们之间的关系是什么？

还有生成私匙公钥的过程中也会提到一个指纹

> ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/xavier/.ssh/id_rsa): testxxx
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in testxxx.
Your public key has been saved in testxxx.pub.
The key fingerprint is:
SHA256:Bw1NuIXaa7h6tzCWDDOq0/esnqQiNJruFeNThfYffHY xavier@local
The key's randomart image is:
+---[RSA 2048]----+
|        .=.      |
|      . ooo      |
|     o +.o.      |
|    . + +.       |
|   o+. oS+.o E   |
| o..+=..+.+ .    |
|ooo+. *o .       |
|*.ooo+oo.        |
|==.o==o...       |
+----[SHA256]-----+

Answer 1

The server administrator will inform the user

Answer 2

Yes, there is no guarantee.
If the ssh protocol is to be secure, you need to ensure that the fingerprint you get for the first time is authentic.

You need to use another safe method to obtain it. For example, if you purchase a vps, the merchant should not only provide the SSH connection method but also the SSH fingerprint of the server on its https web page. This will prevent network pollution.

This is the basis of cryptography. You cannot guarantee that the communication will not be tampered with before negotiating the secret key.

Answer 3

How to enter the server through other methods to verify fingerprints, or obtain fingerprint information in advance for comparison?

I just thought you asked two questions.

How to obtain fingerprint information in advance for comparison?
Answer: The SSH client has already done it for you, which is the service you posted. If the comparison is unsuccessful, you will be refused to continue logging in by default to prevent your password (if you use a password) from being forged. End stealing.

How to get the real fingerprint of the server?
Answer: The fingerprint of the server is stored in /etc/ssh/ by default.
Judging from the information you gave, your SSH client uses an ECDSA key, which is the content of /etc/ssh/ssh_host_ecdsa_key.pub.
But your comparison is of no use.

The reason is very simple. The middleman can get the public key of the server.
Then he can also store the fingerprint in the default location. As for the private key, generally you will not verify his private key. The key and the public key can be matched, so he can just forge one.

But the middleman cannot get the private key, and he cannot decrypt the data transmitted between you and the server.

This involves asymmetric encryption measures such as conventional encryption private key decryption public key decryption private key encryption, and I will not go into details.

In other words, he got the public key of the server, (even if he can pass the public key) and forged a server, (although he cannot start a server without the private key, special circumstances will be discussed separately), #🎜🎜 #But the data you send to the server needs to be decrypted by the server's private key. In other words, it cannot decrypt it and is useless.

In other words:

As long as you log in successfully for the first time and confirm that the machine you are logging in to is your own machine, then there will be absolutely no security issues if you follow the default security policy of the ssh client.

As long as you log in successfully for the first time and confirm that the machine you are logging in to is your own machine, then there will be absolutely no security issues if you follow the default security policy of the ssh client.
As long as you log in successfully for the first time and confirm that the machine you are logging in to is your own machine, then there will be absolutely no security issues if you follow the default security policy of the ssh client.

Confirming that it is your own machine is very simple, just check to see if your files are there.

Someone in the comment area questioned that the entire machine has been used as a proxy, so I can also provide a solution:

Theoretically, the first time is absolutely unsafe, but there is no absolute.

It’s not good to always mention cryptography when you see private and public keys, and then mention key encryption.

Key encryption itself is not safe, but the key itself is also a compromise. The key itself is encrypted with a long enough key, making it a very time-consuming thing for you to crack (consuming several years time recorded).

Then it’s easy to compromise,

It’s very simple. Even if it can hijack the contents of your cat ssh public key and open it with vim, it is difficult to hijack you to edit the file. For example, add a carriage return at the beginning of the file, or add a carriage return in the middle of the public key. car.

You can’t even be hijacked to write your own script

wget http://www.abidu.com/cat_key.sh
bash cat_key.sh

The content of cat_key.sh is cat ssh_key.pub, or cat_key.sh is simply a binary file.

The comment area also proposed that the public key and private key be directly replaced by proxy.

It is also very easy to crack. Installing the machine must go through the installation script. How to operate the installation script is a problem.

1. bash will not record operations in real time, but each operation can be recorded in real time through logger.

2. Customize the system log and audit it after logging in.

There are not many hackers who can hack into routers. Those who have the ability to directly replace them are the top black hat/white hat industry. The only ones who can secretly erase operation records are state machines, professional hacker teams and NSA. That leaves the NSA.

Having said all that, it is still quite troublesome. If you have to be nervous and suspicious,
then only the machine provider can provide the public key or fingerprint.

Under normal circumstances,
Weak passwords on the server side and password blasting are the way to go.
Those hackers like to use various tools to scan for weak passwords.
Install a denyhosts and start it,
will block most malicious ssh requests by default.