Як ігнорувати перевірку справжності SSH?


164

Чи є спосіб ігнорувати перевірку справжності SSH, зроблену Ansible? Наприклад, коли я тільки що налаштував новий сервер, я повинен відповісти "так" на це питання:

GATHERING FACTS ***************************************************************
The authenticity of host 'xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx)' can't be established.
RSA key fingerprint is xx:yy:zz:....
Are you sure you want to continue connecting (yes/no)?

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

Відповіді:


247

Два варіанти - перший, як ви сказали у власній відповіді, - встановлення змінної середовища ANSIBLE_HOST_KEY_CHECKINGна False.

Другий спосіб встановити це - помістити його у файл ansible.cfg, і це дійсно корисний варіант, оскільки ви можете встановити це у всьому світі (на системному або користувацькому рівні, в /etc/ansible/ansible.cfgабо ~/.ansible.cfg), або в конфігураційний файл у тому ж каталозі як ігрова книга, яку ви ведете.

Для цього створіть ansible.cfgфайл в одному з цих місць і додайте це:

[defaults]
host_key_checking = False

Ви також можете встановити багато інших зручних за замовчуванням там, наприклад, збирати чи не збирати факти на початку вистави, чи об’єднувати хеші, оголошені в декількох місцях, або замінити одне інше тощо. Там цілий великий список варіантів тут в анзібле документи.


Редагувати: примітка про безпеку.

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

Для триваліших екземплярів EC2 було б доцільно прийняти ключ хосту із завданням, що виконується лише один раз при первинному створенні екземпляра:

  - name: Write the new ec2 instance host key to known hosts
    connection: local
    shell: "ssh-keyscan -H {{ inventory_hostname }} >> ~/.ssh/known_hosts"

Немає значення безпеки для перевірки ключів хоста на випадки, коли ви встаєте динамічно та видаляєте відразу після виконання playbook, але є безпека для перевірки ключів хоста на стійкі машини. Тож вам слід керувати перевіркою ключів хоста по-різному в логічному середовищі.

  • Залишити перевірку включеною за замовчуванням (у ~/.ansible.cfg)
  • Вимкніть перевірку ключів хоста у робочому каталозі ./ansible.cfgігрових книг, які ви ведете проти ефемерних екземплярів ( поряд із програмою для тестування одиничних тестів проти бродячих VM, автоматизації для короткочасних екземплярів ec2)

5
Хтось знає, яка тут найкраща практика? Наприклад, ви можете періодично запускати сценарій для скидання відомих хостів, що було б більш захищеним (якщо тільки не піддалася атаці MITM, що перебуває під цим вікном). Ігнорування автентичності за замовчуванням усуває один із механізмів первинної безпеки SSH
TonyH

3
Мені подобається схема, яку використовує моя команда: ми поміщаємо файли ansible.cfg, які відключають перевірку ключів хостів, у робочих каталогах для ігрових книг, які ми запускаємо проти ефемерних екземплярів (одиничні тести, які виконуються на бродячих VM, екземплярах AWS ec2 тощо) і залишаємо перевірку увімкнено у системний рівень.
nikobelia

1
Таким чином, ви можете керувати перевіркою ключів хоста за логічним середовищем . Немає значення безпеки для перевірки ключів хоста на випадки, коли ви встаєте динамічно та видаляєте відразу після виконання playbook, але є безпека для перевірки ключів хоста на стійкі машини. Таким чином, ви повинні мати різні за замовчуванням для цих різних випадків використання.
nikobelia

2
Якщо якийсь механізм використовується для забезпечення нових машин, постійних чи тимчасових, цей механізм повинен надавати вам відкритий ключ SSH цієї машини. Потім ви можете зберігати його у різних локальних known_hostsфайлах для SSH та Ansible для розпізнавання машини. Якщо цього не зробити, особливо відключивши перевірку ключів хоста, погіршує безпеку SSH майже до нуля і дозволяє атаки MITM. Дуже багато машин, які перебувають у "внутрішній мережі", насправді підключені до Інтернету, де одна швидша відповідь DNS дозволяє вам спілкуватися з нападником замість вашої цілі.
aef

2
@TonyH під час налаштування багатьох хостів за допомогою AWS Cloudformation та Ansible, я побіг ssh-keyscan <ip list>на надійній машині (для мене це бастіон / хост-хост) всередині тієї ж мережі, і поставив результати known_hosts для налаштування цього надійного хоста, AWS виставляє ключ хоста в журналах запуску екземпляра, тому пошук цього ключа був одним ручним кроком, який я ніколи не вирізав, якщо я займався повною рекреацією свого оточення. Але цього хоста зазвичай не потрібно було видаляти. Це може допомогти.
dcc310

34

Я знайшов відповідь, вам потрібно встановити змінну середовища ANSIBLE_HOST_KEY_CHECKINGна False. Наприклад:

ANSIBLE_HOST_KEY_CHECKING=False ansible-playbook ...

2
Так, але ви сказали, що використовуєте це для нового сервера, який ви тільки що налаштували. Це дозволяє уникнути стикання з ключем хосту цього разу, але як бути з подальшими з'єднаннями SSH? Ваш сценарій налаштування працює, налаштовує сервер, і це зроблено. Тепер у вас є інші ігрові книги, які ви запускаєте, скажімо, або у вас є сценарії, які використовують SSH. Тепер вони зламані, оскільки ключ хоста все ще не знаходиться у відомих_хостях. Ви лише затримали свою проблему. Коротше кажучи, те, що ви написали тут, не здається гарною відповіддю на поставлене вами питання.
Тодд Уолтон

Це використовується в скрипті bash при створенні нових серверів, він не використовується ні для чого іншого.
Йоган

8

вперед до нікобелії

Для тих, хто використовує jenkins для запуску ігрової книги, я тільки що додав до своєї роботи jenkins перед тим, як запустити ansible-playbook змінну середовища hes ANSIBLE_HOST_KEY_CHECKING = False Наприклад, це:

export ANSIBLE_HOST_KEY_CHECKING=False
ansible-playbook 'playbook.yml' \
--extra-vars="some vars..." \
--tags="tags_name..." -vv

6

Зміна host_key_checkingдо falseдля всіх хостів це дуже погана ідея.

Єдиний раз, коли ви хочете проігнорувати це, - це "перший контакт", який ці два завдання виконають:

    - name: Check SSH known_hosts for {{ inventory_hostname }}
      local_action: shell ssh-keygen -F {{ inventory_hostname }}
      register: checkForKnownHostsEntry
      failed_when: false
      changed_when: false
      ignore_errors: yes
    - name: Add {{ inventory_hostname }} to SSH known hosts automatically
      when: checkForKnownHostsEntry.rc == 1
      changed_when: checkForKnownHostsEntry.rc == 1
      set_fact:
        ansible_ssh_common_args: '-o StrictHostKeyChecking=no'

Тож ми лише вимикаємо перевірку ключів хоста, якщо у нас у known_hostsфайлі немає ключа хоста .


3

Ви можете передати його як аргумент командного рядка під час запуску книги.

ansible-playbook play.yml --ssh-common-args='-o StrictHostKeyChecking=no'


2

Якщо ви не хочете змінювати ansible.cfgабо playbook.ymlтоді ви можете просто встановити змінну середовища:

export ANSIBLE_HOST_KEY_CHECKING=False

0

Використовуйте параметр, назване як validate_certs, щоб ігнорувати перевірку ssh

- ec2_ami:
    instance_id: i-0661fa8b45a7531a7
    wait: yes
    name: ansible
    validate_certs: false
    tags:
      Name: ansible
      Service: TestService

Тим самим він ігнорує процес перевірки ssh


validate_certsПараметр просто говорить Бото не підтверджує AWS API HTTPS серт. Це не впливає на підтвердження ключа SSH.
Меттью Даттон

0

Я знаю, що на це питання відповіли, і він також правильний, але просто хотів зв’язати довідковий документ, де це чітко пояснено, коли і чому слід додати відповідну перевірку: перевірка ключем хоста


0

Найбільше проблем виникає, коли ви хочете додати нового хоста до динамічного інвентаря (через модуль add_host) у програмі. Я не хочу постійно відключати перевірку хоста відбитків пальців, тому такі рішення, як відключення його у глобальному конфігураційному файлі, для мене не в порядку. Експорт var, наприклад, ANSIBLE_HOST_KEY_CHECKINGперед запуском ігрової книги - ще одна річ, яку потрібно зробити перед запуском, про яку потрібно пам’ятати.

Краще додати локальний файл конфігурації в той самий рейтинг, де є ігрова книга. Створіть файл з назвою ansible.cfgта вставте наступний текст:

[defaults]
host_key_checking = False

Не потрібно пам'ятати, щоб додати щось у env vars або додати до ansible-playbookопцій. Помістити цей файл легко в ansible git repo.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.