Самый плавный рабочий процесс для обработки ошибок проверки хоста SSH?

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

Когда серверы меняются, перераспределяются или перераспределяются IP-адреса, мы получаем сообщение проверки хоста SSH ниже. Я заинтересован в оптимизации рабочего процесса для устранения этих ошибок идентификации SSH.

Учитывая следующее сообщение, я обычно vi /root/.ssh/known_hosts +434и удаляю ( dd) оскорбительную строку.

Я видел, как разработчики / пользователи в других организациях удаляли весь свой known_hostsфайл из-за разочарования, увидев это сообщение. Хотя я не захожу так далеко, я знаю, что есть более элегантный способ справиться с этим.

Подсказки?

[root@xt ~]# ssh las-db1

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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
ed:86:a2:c4:cd:9b:c5:7a:b1:2b:cc:42:15:76:8c:56.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:434
RSA host key for las-db1 has changed and you have requested strict checking.
Host key verification failed.

Вы можете использовать ssh-keygenкоманду для удаления определенных записей по хосту:

ssh-keygen -R las-db1

Если у вас нет этой команды, вы всегда можете использовать sed:

sed -i '/las-db1/d' /root/.ssh/known_hosts

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

Таким образом, мне не нужно беспокоиться об их удалении. Девяносто девять процентов времени кукла запускает и обновляет ключи для меня, так как мои агенты работают каждые тридцать минут. Исключения для меня очень редки, и поэтому я не возражаю против быстрого редактирования общеизвестных систем_хостов, если не хочу ждать.

class ssh::hostkeys {

  @@sshkey { "${::clientcert}_rsa":
    type => rsa,
    key => $sshrsakey,
    tag => 'rsa_key',
  }

  if 'true' == $common::params::sshclient {
    Sshkey <<| tag == 'rsa_key' |>> {
      ensure => present
    }
  }

  file {'/etc/ssh/ssh_known_hosts':
    ensure => present,
    owner => 'root',
    group => 'root',
    mode => 0644,
  }

}

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

У меня есть лабораторная среда с машинами, которые часто переустанавливаются. Каждый раз, когда это происходит, генерируются новые ключи хоста (возможно, я мог бы сохранить ключ хоста где-нибудь и установить его в сценарии после установки).

Поскольку в этой лабораторной среде для меня не проблема безопасности, а ключи меняются так часто, в моем файле .ssh / config есть следующее:

Host lab-*
  User kenny
  IdentityFile ~/.ssh/lab_id_rsa
  StrictHostKeyChecking no
  UserKnownHostsFile=/dev/null

Это гарантирует, что подключение к моим лабораторным машинам никогда не вызовет этой ошибки, и мой ssh-клиент просто подключится без проверки ключа хоста.

Это то, что вы должны делать только в том случае, если безопасность вас вообще не касается, потому что это ставит вас в уязвимое положение для атаки «человек посередине».

Согласно примечанию к выпуску openssh 5.6 , вам больше не нужно использовать ключи хостов:

При аутентификации на основе хоста теперь могут использоваться ключи хоста сертификата. Ключи CA должны быть указаны в файле known_hosts с помощью маркера @ cert-Authority, как описано в sshd (8).

Предупреждение : я никогда не слышал, чтобы кто-нибудь использовал эту функцию в производстве. Используйте на свой страх и риск (но я считаю, что разработчики openssh настолько параноидальны, что не выпускают такую ​​убойную функцию без большого количества тестирования и аудита кода).

SSHFP DNS ResourceRecord может помочь в зависимости от того, насколько ваш ssh-клиент этим пользуется. Сохраните все ваши отпечатки пальцев открытого ключа SSH там с именем хоста.

Внедрите DNSSEC или DNS поверх SSL заранее.
http://www.ietf.org/rfc/rfc4255.txt

FreeIPA.org обрабатывает управление ключами хоста и пользователя, а также сертификаты PKI. Он также автоматически загружает записи DNS SSHFP при создании новых ключей.

Демон системных служб безопасности (SSSD) можно настроить для кэширования и получения ключей SSH узла, чтобы приложениям и службам приходилось искать ключи узла только в одном месте. Поскольку SSSD может использовать FreeIPA в качестве одного из своих поставщиков идентификационной информации, FreeIPA предоставляет универсальный и централизованный репозиторий ключей. Администраторам не нужно беспокоиться о распространении, обновлении или проверке ключей SSH хоста.

http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/host-keys.html