Я пытаюсь настроить SSH без пароля на сервере Ubuntu ssh-copy-id myuser@myserver, но получаю сообщение об ошибке:
Предупреждение: ключ хоста ECDSA для «myserver» отличается от ключа для IP-адреса «192.168.1.123»
Что вызывает это, и как я могу это исправить? Я попытался удалить .sshкаталог на удаленном компьютере и запустить его ssh-keygen -R "myserver"локально, но это не устраняет ошибку.
Удалите кэшированный ключ для 192.168.1.123на локальном компьютере:
ssh-keygen -R 192.168.1.123 У меня не работало на недавно установленном сервере Debian на работе, когда SSHing входил из дома. Кроме того, ответ довольно лаконичен.
/home/wf/.ssh/known_hosts обновлен. Исходное содержимое сохраняется как /home/wf/.ssh/known_hosts.old «Предупреждение. Постоянно добавлен ключ узла ECDSA для IP-адреса« xxxx »в список известных узлов». отображается. а то похоже на работу
Вы можете обновить ключ вместо того, чтобы удалить его. Используйте ssh-keyscan -t ecdsa my.server.domain >> ~ / .ssh / known_hosts, после чего вам не нужно проверять новый ключ при первом подключении к хосту.
Для тех, кому не удается заставить его работать: я зарегистрировал несколько вхождений одного и того же IP: 1 / указанный IP-адрес (xx.xx.xx.xx), домен (tomsihap.fr), указанный vps-сервер провайдера адрес (vpsxxx.ovh.net). ssh-keygen -R для каждого из них сделал свою работу.
Сработало для меня, но путаница может быть с какого хоста должна запускаться эта команда? Ответ от того, который показал ошибку. Второй вопрос и ответ более очевидны, но на всякий случай: какой адрес передать ssh-keygen -R? Адрес, указанный в сообщении об ошибке.
Если это не обрезается, и ssh 192.168.1.123 отображает предупреждение, но не показывает номер строки, вызывающей ошибку в known_hosts, вы можете выполнить ssh -v 192.168.1.123 2> & 1 | grep known, то вы можете, например, sed -i.orig 42d ~ / .ssh / known_hosts удалить строку 42 (или что бы то ни было)
Спасибо, у меня сработало! В моем случае я сделал перестройку в моей капле в DigitalOcean.
In my case ssh-keygen -R ... didn't fix the warning. I had extra information like this:
Offending key for IP in /home/myuser/.ssh/known_hosts:8 Matching host key in /home/myuser/.ssh/known_hosts:24 I simply manually edited ~/.ssh/known_hosts and deleted line 8 (the "offending key"). I tried reconnecting, the host was permanently added, and everything was fine after that!
Работает как шарм. Можно исправить это в одной строке с помощью sed -e '8d' / home / myuser / .ssh / known_hosts, заменив номер строки 8 и имя файла теми, которые отображаются в вашей системе.
Я много общаюсь между моими компьютерами в локальной сети и двумя учетными записями веб-хостинга, поэтому я разобрался со всеми видами шансов и заканчивается с помощью SSH, включая проблемы с аутентификацией, ssh -vчтобы узнать, где и что пошло не так.
Только что решив эту проблему и не обрадовавшись ответам, я хотел по-настоящему понять «почему» сам ...
Триггер для моего случая: установленная новая серверная ОС на работе и после установки пакета openssh-server на рабочем сервере был создан новый набор ключей хоста. Ранее все мои серверные ОС были Ubuntu, и на этот раз они поменялись на Debian (и я подозреваю, что в разрешениях есть нюансы).
Когда все операционные системы были Ubuntu, и я переустанавливаю серверную операционную систему, при первом подключении к ней SSH я получаю предупреждение такого рода, которое я предпочитаю над тихим предупреждением выше!
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 06:ea:f1:f8:db:75:5c:0c:af:15:d7:99:2d:ef:08:2a. Please contact your system administrator. Add correct host key in /home/user/.ssh/known_hosts to get rid of this message. Offending key in /home/user/.ssh/known_hosts:4 RSA host key for domain.com has changed and you have requested strict checking. Host key verification failed. Затем я открываю ~/.ssh/known_hostsна компьютере запуск ssh, удаляю эту строку, переподключаюсь, и это происходит:
chris@home ~ $ ssh work The authenticity of host '[work]:11122 ([99.85.243.208]:11122)' can't be established. ECDSA key fingerprint is 56:6d:13:be:fe:a0:29:ca:53:da:23:d6:1d:36:dd:c5. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '[work]:11122 ([99.85.243.208]:11122)' (ECDSA) to the list of known hosts. Linux rock 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 Этот бит о: 11122 - номер порта, с которого я маршрутизирую SSH на брандмауэре
Я проверил резервные копии с бывшего сервера Ubuntu и сравнил их с моей новой установкой Debian:
Ubuntu: Debian: # Package generated configuration file # Package generated configuration file # See the sshd(8) manpage for details # See the sshd_config(5) manpage for details # What ports, IPs and protocols we listen for # What ports, IPs and protocols we listen for Port 22 Port 22 # Use these options to restrict which interface # Use these options to restrict which interfaces #ListenAddress :: #ListenAddress :: #ListenAddress 0.0.0.0 #ListenAddress 0.0.0.0 Protocol 2 Protocol 2 # HostKeys for protocol version 2 # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_dsa_key ------------------------------------------------ HostKey /etc/ssh/ssh_host_ecdsa_key #Privilege Separation is turned on for security #Privilege Separation is turned on for security UsePrivilegeSeparation yes UsePrivilegeSeparation yes Так что да, вероятно, хост недавно начал использовать ключи ecdsa, которые, основываясь на изменениях в Ubuntu, я бы обвинил в обновлении. Отказ Ubuntu от надежной Linux-ОС, на которую я рассчитывал, объясняет, почему на этот раз я установил Debian.
Я прочитал security.SE q / a на ecdsa и уже удалил эту строку с sshd_configмоего нового сервера Debian. (и побежал service ssh restart)
+1 за хороший блок сравнения. Не могли бы вы добавить URL-адрес, означающий «Отказ Ubuntu от отличной ОС Linux»?
@bgoodr, на мой взгляд, основано исключительно на том, что я несколько раз настраивал свой собственный файловый сервер RAID за последние несколько лет. : / Дерьмо за ответ, но начните гуглить Ubuntu Debian Server, и вы поймете, что я имею в виду.
@ChrisK Вы, сэр, босс. Спасибо за подробный, но краткий ответ.
ssh-keygen -f "/root/.ssh/known_hosts" -R 192.168.1.123
This should replace the existing keys under known_hosts.old and create a new one. This solution worked for me in the same scenario
Запрос появляется каждый раз, потому что IP-адреса все время меняются при использовании динамической адресации. Попробуйте использовать статический IP-адрес, чтобы добавить ключ только один раз.
Хороший вопрос, я пропустил, где кто-то упоминал динамические IPS?
Вы используете тот же пользователь для подключения?
Если вы вошли в систему на локальном ПК, таком как пользователь John, и подключились к серверу B, например, на пользователя Adolf @ B, и все в порядке, это не значит, что все в порядке, если вы вошли на локальный ПК, например, пользователь Jane, и подключились к серверу. B, как пользователь Adolf @ B .
Если вы хотите войти на сервер B как пользователь Beda с ПК A без пароля, попробуйте эту команду, все с ПК A :
ssh-keygen -t rsa Эта команда генерирует ключ и сохраняет ключ в файле. Пожалуйста, оставьте парольную фразу пустой.
ssh Beda@B mkdir -p .ssh Эта команда создает каталог, если он еще не существует. В противном случае не печатайте сообщение об ошибке.
cd ~/.ssh Эта команда изменяет каталог на домашний каталог вашего пользователя ./ssh.
cat id_rsa.pub | ssh Beda@B 'cat >> .ssh/authorized_keys' Эта команда печатает файл id_rsa.pub (ваш открытый ключ) в авторизованные ключи на сервере.
ВАЖНО: Beda - это ваше имя пользователя на сервере, к которому вы подключаетесь, B - это IP-адрес вашего сервера.
Теперь вы можете подключиться к серверу B без пароля или пароля:
ssh Beda@B Или просто используйте ssh-copy-id, чтобы заполнить файл author_keys ключом id_rsa.pub без лишних хлопот.
Вопрос: что является причиной этого, ...?
Таким образом, ключ хоста сервера ssh изменился. Что вызвало изменение? Трудно сказать. Вот некоторые догадки:
Вопрос: ... и как мне это исправить?
Как уже отвечали другие, удалите кэшированный ключ хоста ECDSA для myserver, который кэшировал ваш аккаунт.
Хороший совет, но на самом деле не отвечает на вопрос. Даже не пытался ответить на вопрос.
Нить здесь может помочь.
По сути, вы хотите удалить оба ключа RSA и ECDSA для этого хоста, а затем использовать их, ssh-keyscanчтобы поместить их обратно в known_hostsфайл таким образом, чтобы не вызвать этот конфликт. Это сработало для меня, когда у меня была такая же проблема.
Эта ошибка долго меня раздражала. По какой-то причине это имело значение, буду ли я делать
ssh host или же
ssh host.domain https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh
затем указал мне на возможность изменения файла конфигурации. Смотрите мой скрипт https://askubuntu.com/a/949731/129227 там для автоматизации процесса.
Использование значений конфигурации CanonicalizeHostname и CanonicalDomains позволит избежать удаления строгой проверки и заставит ssh считать host и host.domain одинаковыми.
Я исправил это на Chromebook, удалив и переустановив Secure Shell ... Это работало как прелесть.
Это излишне. Смотрите более простое решение в моем ответе здесь.
Ctrl+K или / — быстрый поиск Начните вводить запрос для поиска по сайту
в моем случае я изменяю привязку сервера (ip) к домену, затем «ключ хоста ECDSA для сервера изменился». Мой путь - удалить связанную строку кэша о домене в
~ / .ssh / known_hosts. Тогда SSH работает.