It is also possible that a host key has just been changed

Ошибки SSH в Ubuntu

ssh: connect to host x.x.x.x port 22: Connection refused

ssh: connect to host x.x.x.x port 22: Connection refused

No identities found

/usr/bin/ssh-copy-id: ERROR: No identities found

Permissions 0644 are too open.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0644 for ‘/home/user/.ssh/id_rsa.pub’ are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored. Load key «/home/user/.ssh/id_rsa.pub»: bad permissions

Скорее всего вы делаете проверку неправильного ключа.

/.ssh/ id_rsa user@192.168.0.2

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

При попытке подключения к, казалось бы, известному хосту можно получить ошибку

ERROR: Offending ECDSA key in /home/user/.ssh/known_hosts:3

Можно понять, что проблема вызвана третьей строкой файла /home/user/.ssh/known_hosts

Если вы уверены в надёжности хоста к которому подключаетесь, то можете просто удалить эту строку и подключиться снова

В случае более сложных подключений, предупреждение может быть по поводу определённого порта

В этом случае подсказка по-прежнему содержится в предупреждении (выделил её зелёным).

# Host [192.168.56.103]:1234 found: line 14 /home/username/.ssh/known_hosts updated. Original contents retained as /home/username/.ssh/known_hosts.old

The authenticity of host X can’t be established.

Если вы видите в логах подключения следующую ошибку

The authenticity of host ‘192.168.56.103 (192.168.56.103)’ can’t be established.

Первым делом перейдите в

/.ssh и проверьте наличие и содержание файла known_hosts а также права на него.

Подпишитесь на Telegram канал @aofeed чтобы следить за выходом новых статей и обновлением старых

Как исправить «ECDSA host key» Предупреждающая ошибка в Arch Linux

Я использовал множество виртуальных машин, используюя Oracle VirtualBox для тестирования и обучения.

На днях я попытался подключиться к одному из моих удаленных серверов, который работает с Arch Linux через SSH.

Вот как я использую SSH для моего удаленного сервера Arch от моей локальной системы.

Здесь sk – это мое имя пользователя удаленного сервера Arch Linux, а 192.168.1.102 – это IP-адрес Arch Linux.

После выполнения вышеуказанной команды я получил следующее предупреждающее сообщение.

Я не могу использовать SSH на удаленном сервере VM.

Я попытался войти с альтернативным именем пользователя, но получил тот же результат, что и выше.

После небольшого поиска в Google я понял, что эта ошибка произойдет, если ваша система использует динамическую IP-адресацию.

Таким образом, указанное предупреждающее сообщение будет появляться каждый раз, когда изменяется IP-адрес удаленного сервера.

Чтобы навсегда исправить эту ошибку, вы должны использовать статический IP-адрес и добавить ключ хоста только один раз.

Дело в том, что у всех нас нет статических IP-адресов, не так ли? Покупка статического IP-адреса не требуется для всех нас, и это тоже дорого.

Таким образом, вы можете решить эту ошибку, как описано ниже. Чтобы обойти эту проблему, сначала нам нужно обновить кеш-ключ ECDSA-хоста вашей удаленной системы в файле known_hosts вашей локальной системы.

Как вы, возможно, знаете, ключи хоста будут храниться в файле /home/yourusername/.ssh/known_hosts.

Чтобы удалить кешированный ключ, используйте следующую команду:

В нашем случае IP-адрес удаленной системы – 192.168.1.102, поэтому давайте использовать следующую команду для удаления ключа хоста из файла «known_hosts».

Теперь попробуйте снова зайти через ssh в удаленную систему с командой:

Введите «yes» и нажмите «enter», чтобы обновить ключ хоста вашей удаленной системы в файле known_hosts вашей локальной системы.

Теперь вы можете без проблем справиться с ssh в своей удаленной системе Arch Linux.

Этот метод будет работать не только на Arch Linux, но и на других дистрибутивах Linux.

Как исправить «ECDSA host key» Предупреждающая ошибка в Arch Linux : 4 комментария

Спасибо, понимал что трабла с ключами, но не мог понять что делать. Эта статья в две секунды всё исправила.

This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.

I’m unable to ssh and rysnc to a remote system. It keeps giving this error message:

5 Answers 5

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

The message says » /root/.ssh/known_hosts » not authorized_keys. Remove that file (or at least the corresponding key) from it and you can go again! But be aware that: There must be a reason why the key changed. Was the system reinstalled? Make sure you check that or the whole idea of ssh is void.

BTW.: Is there a reason you ssh as root?

The message does explain itself:

If you trust the remote host, you can delete line 8 from your /root/.ssh/known_hosts and ssh will ask you if it can add the new key next time you try to connect

If you don’t trust the remote host, you have to contact the host administrators to find out if and why they changed ssh keys. If they haven’t it means your traffic is being intercepted

On the other hand, if you really really trust the remote host (eg it is on an intranet), you can run ssh with

How to remove strict RSA key checking in SSH and what’s the problem here?

I have a Linux server that whenever I connect it shows me the message that changed the SSH host key:

$ ssh root@host1 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 93:a2:1b:1c:5f:3e:68:47:bf:79:56:52:f0:ec:03:6b. Please contact your system administrator. Add correct host key in /home/emerson/.ssh/known_hosts to get rid of this message. Offending key in /home/emerson/.ssh/known_hosts:377

RSA host key for host1 has changed and you have requested strict checking. Host key verification failed.

It keeps me for a very few seconds logged in and then it closes the connection.

/.ssh # Read from remote host host1: Connection reset by peer Connection to host1 closed.

Does anyone know what’s happening and what I could do to solve this problem?

6 Answers 6

Please don’t delete the entire known_hosts file as recommended by some people, this totally voids the point of the warning. It’s a security feature to warn you that a man in the middle attack may have happened.

I suggest you identify why it thinks something has changed, most likely an SSH upgrade altered the encryption keys due to a possible security hole. You can then purge that specific line from your known_hosts file:

This deletes line 377 as shown after the colon in the warning:

Alternatively you can remove the relevant key by doing the following

Please DO NOT purge the entire file and ensure this is actually the machine you want to be connecting to prior to purging the specific key.

/.ssh/known_hosts ; note the lack of a «.» in the filename.

I think though some of the answers here address the recommended course of action in the OP’s question, it does not fully answer the question.

The question states «How to remove strict RSA key checking in SSH and what’s the problem here?»

However I didnt see any answers address the specific part of the question «How to remove strict RSA key checking in SSH«.

You can remove StrictHostKey checking in your ssh configuration file, typically stored at

An example Host block is provided below:

The specifically added line is the last one StrictHostKeyChecking no which does just what that. Depending on your specific scenario, this may be useful to you, such as running multiple virtualized containers on a dedicated server, on just a few ips, stopping and starting another instance on the same ip.

How to fix: «WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED» on Mac and Linux

SSH, or Secure Shell, is a very common way to securely access remote machines, typically via the command line. It aims at ensuring that your connection, and therefore all data passed, is free from eavesdropping. Because of this, there are quite a few checks built-in to the popular SSH clients, like OpenSSH, that ensure your connection can’t be compromised.

An example of one of these checks is the following, which identifies when the fingerprint of a server has changed:

When you connect to a server via SSH, it gets a fingerprint for the ECDSA key, which it then saves to your home directory under

If you enter ‘yes’, then the fingerprint is saved to the known_hosts file, which SSH then consults every time you connect to that server.

But what happens if a server’s ECDSA key has changed since you last connected to it? This is alarming because it could actually mean that you’re connecting to a different server without knowing it. If this new server is malicious then it would be able to view all data sent to and from your connection, which could be used by whoever set up the server. This is called a man-in-the-middle attack. This scenario is exactly what the «WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!» message is trying to warn you about.

Free eBook: Git Essentials

Check out our hands-on, practical guide to learning Git, with best-practices, industry-accepted standards, and included cheat sheet. Stop Googling Git commands and actually learn it!

Of course, this isn’t always the case, and there are many reasons for the ECDSA key fingerprint to change for a server. In my case, I had an elastic IP address on AWS and assigned it to a different server after redeploying our application. The IP address and hostname I was connecting to were the same, but the underlying server was different, which is what tripped the SSH client to issue this warning.

Fixing the Issue

If you are 100% sure that this was expected behavior and that there is no potential security issue, you’ll need to fix the issue before continuing.

The easiest ways I’ve found to fix this problem is the following two solutions.

Manually Resolve via known_hosts

By deleting this line, your SSH client won’t have an ECDSA key fingerprint to compare to, and thus will ask you again to verify the authenticity of the server the next time you connect. Once done, you’ll have a new fingerprint in our known_hosts file for this server, and the warning will be gone.

Resolve Using ssh-keygen

Another solution would be to use the ssh-keygen utility to delete the offending key from your known_hosts file, which can be done with the following command: