Как игнорировать проверку подлинности SSH?


165

Есть ли способ игнорировать проверку подлинности 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)?

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

Ответы:


248

Два варианта - первый, как вы сказали в своем ответе, это установка переменной среды 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наряду с книгой воспроизведения для модульных тестов против бродячих виртуальных машин, автоматизации для кратковременных экземпляров ec2)

5
Кто-нибудь знает, какова лучшая практика здесь? Например, вы можете периодически запускать скрипт для сброса ваших известных хостов, который будет более безопасным (если только он не подвергается атаке MITM во время этого окна). Игнорирование аутентичности по умолчанию устраняет один из основных механизмов безопасности SSH
TonyH

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

1
Таким образом, вы можете управлять проверкой ключей хоста для каждой логической среды . Не существует значения безопасности для проверки ключей хоста в тех случаях, когда вы динамически встаете и удаляете сразу после выполнения playbook, но есть значение безопасности при проверке ключей хоста для постоянных компьютеров. Таким образом, у вас должны быть разные значения по умолчанию для этих разных вариантов использования.
Никобелия

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. Теперь они сломаны, потому что ключ хоста все еще отсутствует в known_hosts. Вы только задержали свою проблему. Короче говоря, то, что вы здесь написали, не похоже на хороший ответ на заданный вами вопрос.
Тодд Уолтон

Это используется в скрипте bash при создании новых серверов, это не используется ни для чего другого.
Йохан

8

вперед к никобелия

Для тех, кто использует jenkins для запуска игровой книги, я просто добавил в свою работу jenkins перед запуском ansible-playbook переменную среды he 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

Вы можете передать его в качестве аргумента командной строки при запуске playbook:

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


2

Если вы не хотите изменять ansible.cfgили playbook.ymlтогда, вы можете просто установить переменную окружения:

export ANSIBLE_HOST_KEY_CHECKING=False

1

Игнорирование проверки - плохая идея, так как она делает вас уязвимыми к атакам «Человек посередине».

Я воспользовался возможностью улучшить ответ nikobelia, просто добавив ключ каждой машины один раз и фактически установив статус ok / измененный в Ansible:

- name: Accept EC2 SSH host keys
  connection: local
  become: false
  shell: |
    ssh-keygen -F {{ inventory_hostname }} || 
      ssh-keyscan -H {{ inventory_hostname }} >> ~/.ssh/known_hosts
  register: known_hosts_script
  changed_when: "'found' not in known_hosts_script.stdout"

Однако Ansible начинает собирать факты до запуска сценария, который требует SSH-соединения, поэтому нам нужно либо отключить эту задачу, либо вручную перенести ее на более позднюю версию:

- name: Example play
  hosts: all
  gather_facts: no  # gather facts AFTER the host key has been accepted instead

  tasks:

  # /programming/32297456/
  - name: Accept EC2 SSH host keys
    connection: local
    become: false
    shell: |
      ssh-keygen -F {{ inventory_hostname }} ||
        ssh-keyscan -H {{ inventory_hostname }} >> ~/.ssh/known_hosts
    register: known_hosts_script
    changed_when: "'found' not in known_hosts_script.stdout"
  
  - name: Gathering Facts
    setup:

Один излом, который я не смог понять, это то, что он помечает все как измененные, даже если он добавляет только один ключ. Если бы кто-нибудь мог внести исправление, это было бы здорово!


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) в playbook. Я не хочу постоянно отключать проверку хоста по отпечаткам пальцев, поэтому такие решения, как отключение его в глобальном конфигурационном файле, мне не подходят. Экспорт var какANSIBLE_HOST_KEY_CHECKING перед запуском playbook - это еще одна вещь, которую нужно сделать перед запуском, которую нужно запомнить.

Лучше добавить локальный конфигурационный файл в тот же каталог, где находится playbook. Создать файл с именемansible.cfg и вставьте следующий текст:

[defaults]
host_key_checking = False

Не нужно помнить, чтобы добавить что-то в env vars или добавить в ansible-playbookопции. Этот файл легко поместить в ANSI GIT РЕПО.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.