Найпростіший робочий процес для обробки помилок перевірки хоста 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 повинні бути вказані у відомому файлі_hosts, використовуючи маркер @ cert-авторитету, як описано в sshd (8).

Попередження : Я ніколи досі не чув, щоб хтось використовував цю функцію у виробництві. Використовуйте на свій страх і ризик (але я вважаю, що розробники opensh є параноїчними, щоб не випустити таку вбивчу функцію без багато тестування та аудиту коду).

SSHFP DNS ResourceRecord може допомогти залежно від того, наскільки ваш ssh-клієнт цим скористається. Зберігайте там усі свої відбитки відкритого ключа ssh разом із ім'ям хоста.

Заздалегідь застосуйте DNSSEC або DNS через SSL.
http://www.ietf.org/rfc/rfc4255.txt

FreeIPA.org обробляє управління хостом та користувачами, а також сертифікати PKI. Він також автоматично завантажує записи DNS SSHFP, коли створюються нові ключі.

Служба безпеки системи Daemon (SSSD) може бути налаштована для кешування та отримання ключових SSH ключів, щоб додатки та служби шукали лише в одному місці для хост-ключів. Оскільки SSSD може використовувати FreeIPA як один із своїх постачальників інформації про особу, FreeIPA забезпечує універсальне та централізоване сховище ключів. Адміністраторам не потрібно турбуватися про розповсюдження, оновлення чи перевірку ключів SSH хоста.

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