Як виправити попередження про хост-ключ ECDSA

Я намагаюся налаштувати 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

У моєму випадку ssh-keygen -R ...не зафіксували попередження. У мене була додаткова інформація на зразок цієї:

Offending key for IP in /home/myuser/.ssh/known_hosts:8
Matching host key in /home/myuser/.ssh/known_hosts:24

Я просто вручну редагував ~/.ssh/known_hostsі видаляв рядок 8 ("ключ образи"). Я спробував знову підключитися, хост був постійно доданий, і все було добре після цього!

Я роблю багато між собою моїх комп'ютерів локальної мережі та двох моїх облікових записів веб-хостингу, тому я розібрав усі види шансів і закінчується SSH, включаючи проблеми аутентифікації, ssh -vщоб побачити, де і що пішло не так.

Щойно вирішивши це питання і не тішившись відповідями, я хотів по-справжньому знати "чому" сам ...

Тригером для мого випадку є: встановлена ​​нова ОС сервера на роботі та після встановлення пакета openssh-сервера на сервері роботи був створений новий набір ключів хоста. Раніше всі мої ОС на сервері були 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)

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

ssh-keygen -f "/root/.ssh/known_hosts" -R 192.168.1.123

Це повинно замінити існуючі ключі під відомим_hosts.old та створити новий. Це рішення працювало для мене за тим же сценарієм

Я додав наступні рядки до мого ~ / .ssh / config, тим самим відключаючи сувору перевірку хоста на всі .local адреси. (при розподілі адреси DHCP, ip-адреси моїх локальних машин завжди змінюються)

host *.local
    StrictHostKeyChecking no

Ти все-таки отримуєш попередження, що, на мене, добре.

Ви використовуєте того ж користувача для підключення?

Якщо ви ввійшли в локальний ПК на зразок користувача Джон і підключились до сервера B, як користувач Adolf @ B, і все в порядку, це не означає, що все в порядку, якщо ви ввійшли до локального ПК, як користувач Джейн і підключились до сервера 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

Нитка тут може допомогти.

По суті, ви хочете видалити і ключі RSA, і ECDSA для цього хоста, а потім скористатися, ssh-keyscanщоб повернути їх у свій known_hostsфайл таким чином, що це не призведе до цього конфлікту. Це працювало для мене, коли у мене був той самий випуск.

Питання: Що викликає це, ...?

Так змінився хост-ключ сервера ssh. Що спричинило зміни? Важко сказати. Ось кілька здогадок:

• Чи почав sshd на сервері myserver використовувати ключі ECDSA, тож це новий тип ключів?
• Чи був нещодавно встановлений myserver?
• Нещодавно перезаписано sshd на myserver, щоб сформувався новий ключ хосту ssh?
• Хтось повторно генерував або замінив хост-ключ sshd?
• Чи змінилася IP-адреса мого сервера, щоб інший хост відповідав на цю IP-адресу?

Питання: ... і як це виправити?

Як уже відповіли інші, видаліть кешований хост-ключ ECDSA для мого сервера, який кеширував ваш обліковий запис.

Ця помилка довго дратувала мене. Чомусь це змінило, чи буду я робити

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 там для автоматизації процесу.

Я вирішив це на Chromebook, видаливши та перевстановивши безпечну оболонку ... Це спрацювало як шарм.

Ось як видалити відомий відбиток (із known_hostsфайлу) хоста на ОС Chrome:

Знайдіть індекс кривдного запису хоста у висновку ssh, коли з'єднання не вдалося. Наприклад, у рядку нижче показника порушень є 7 :

Offending ECDSA key in /.ssh/known_hosts:7

Відкрийте консоль JavaScript ( CTRL+ Shift+ J) вікна захищеної оболонки та введіть наступне, замінивши INDEXвідповідним значенням (наприклад, 7 ):

term_.command.removeKnownHostByIndex(INDEX);

Це рішення було запозичене з блогу Лео Гаггла .