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

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

ssh-keygen -R las-db1

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

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

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

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

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,
  }

}

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

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

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

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

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

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

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

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

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

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