53

Ansible Playbook を実行していますが、1 台のマシンで正常に動作します。

新しいマシンで初めて試すと、次のエラーが表示されます。

17:04:34 PLAY [appservers] ************************************************************* 
17:04:34 
17:04:34 GATHERING FACTS *************************************************************** 
17:04:34 fatal: [server02.cit.product-ref.dev] => {'msg': "FAILED: (22, 'Invalid argument')", 'failed': True}
17:04:34 fatal: [server01.cit.product-ref.dev] => {'msg': "FAILED: (22, 'Invalid argument')", 'failed': True}
17:04:34 
17:04:34 TASK: [common | remove old ansible-tmp-*] ************************************* 
17:04:34 FATAL: no hosts matched or all hosts have already failed -- aborting
17:04:34 
17:04:34 
17:04:34 PLAY RECAP ******************************************************************** 
17:04:34            to retry, use: --limit @/var/lib/jenkins/site.retry
17:04:34 
17:04:34 server01.cit.product-ref.dev      : ok=0    changed=0    unreachable=1    failed=0   
17:04:34 server02.cit.product-ref.dev      : ok=0    changed=0    unreachable=1    failed=0   
17:04:34 
17:04:34 Build step 'Execute shell' marked build as failure
17:04:34 Finished: FAILURE

このエラーは、最初に (ansible Playbook を実行している) ソース マシンに移動し、(指定されたユーザーとして) ターゲット マシンに手動で ssh し、known_hosts ファイル エントリに「yes」と入力すると解決できます。

これで、同じ ansible Playbook を 2 回目に実行すると、エラーなしで動作します。

したがって、特定のユーザー (~/.ssh フォルダー、ファイル known_hosts) に対して初めて ssh known_hosts エントリを作成するときに、SSH が提供するプロンプトを抑制するにはどうすればよいですか?

~/.ssh/configファイルで次の構成エントリを使用すると、これを実行できることがわかりました。

~/.ssh/config

# For vapp virtual machines
Host *
  StrictHostKeyChecking no
  UserKnownHostsFile=/dev/null
  User kobaloki
  LogLevel ERROR

つまり、上記のコードをユーザーのリモート マシンの ~/.ssh/config ファイルに配置し、Ansible Playbook を初めて試すと、「はい」と入力するように求められず、Playbook は正常に実行されます (ユーザーは、ソース マシンからターゲット/リモート マシンへの known_hosts ファイル エントリを手動で作成できます)。

私の質問: 1. ~/.ssh/config の方法で注意する必要があるセキュリティの問題は何ですか?新しいマシンで初めて実行されます (プロンプトを表示せずに/ターゲット マシンのソース マシンの known_hosts ファイル エントリに依存しますか?

4

7 に答える 7

43

ローカルknown_hostsファイルを更新するために、次のように (ホスト名を IP アドレスに解決する) と ansible モジュールの組み合わせを使用することにssh-keyscanなりdigましたknown_hosts: (filename ssh-known_hosts.yml)

- name: Store known hosts of 'all' the hosts in the inventory file
  hosts: localhost
  connection: local

  vars:
    ssh_known_hosts_command: "ssh-keyscan -T 10"
    ssh_known_hosts_file: "{{ lookup('env','HOME') + '/.ssh/known_hosts' }}"
    ssh_known_hosts: "{{ groups['all'] }}"

  tasks:

  - name: For each host, scan for its ssh public key
    shell: "ssh-keyscan {{ item }},`dig +short {{ item }}`"
    with_items: "{{ ssh_known_hosts }}"
    register: ssh_known_host_results
    ignore_errors: yes

  - name: Add/update the public key in the '{{ ssh_known_hosts_file }}'
    known_hosts:
      name: "{{ item.item }}"
      key: "{{ item.stdout }}"
      path: "{{ ssh_known_hosts_file }}"
    with_items: "{{ ssh_known_host_results.results }}"

そのような yml を実行するには、次のようにします。

ANSIBLE_HOST_KEY_CHECKING=false ansible-playbook path/to/the/yml/above/ssh-known_hosts.yml

その結果、インベントリ内のホストごとに、サポートされているすべてのアルゴリズムがknown_hostsファイルのホスト名と IP アドレスのペア レコードの下に追加/更新されます。そのような

atlanta1.my.com,10.0.5.2 ecdsa-sha2-nistp256 AAAAEjZHN ... NobYTIGgtbdv3K+w=
atlanta1.my.com,10.0.5.2 ssh-rsa AAAAB3NaC1y ... JTyWisGpFeRB+VTKQ7
atlanta1.my.com,10.0.5.2 ssh-ed25519 AAAAC3NaCZD ... UteryYr
denver8.my.com,10.2.13.3 ssh-rsa AAAAB3NFC2 ... 3tGDQDSfJD
...

(インベントリファイルが次のようになっているとします。

[master]
atlanta1.my.com
atlanta2.my.com

[slave]
denver1.my.com
denver8.my.com

)

Xiongの答えとは対照的に、これはknown_hostsファイルの内容を適切に処理します。

このプレイは、ターゲット ホストが再イメージ化される仮想化環境を使用している場合に特に役立ちます (したがって、ssh pub キーが変更されます)。

于 2016-08-22T15:45:33.970 に答える
20

ホスト キー チェックを完全に無効にすることは、中間者攻撃にさらされるため、セキュリティの観点からは悪い考えです。

現在のネットワークが侵害されていないと仮定できる場合 (つまり、初めてマシンに ssh し、キーが提示されたときに、そのキーは実際にはマシンのものであり、攻撃者のものではありません)、次を使用できますssh-keyscan。新しいサーバーのキーを既知のホストファイルに追加するためのシェルモジュール(編集: Stepan の回答はこれをより良い方法で行います):

- name: accept new ssh fingerprints
  shell: ssh-keyscan -H {{ item.public_ip }} >> ~/.ssh/known_hosts
  with_items: ec2.instances

( ec2 プロビジョニングの後に表示されるように、ここでデモを行います。)

于 2016-02-04T23:43:22.803 に答える
0

警告: ホスト (および Ansible) は、上記の設定の ssh 接続に対して SSH ホスト キーの検証を実行しなくなります。これはリスクになる可能性があり、本番環境では強くお勧めしません

これは、サーバーの OS レベルから設定することもできます。ssh チェックでプロンプトが表示されないようにするには、ssh 構成ファイルを構成する必要があります。

ファイル パスを編集します。

/etc/ssh/ssh_config

次の行のコメントを外します。

StrictHostKeyChecking no

変更を保存して、それだけです

警告: ホスト (および Ansible) は、上記の設定の ssh 接続に対して SSH ホスト キーの検証を実行しなくなります。これはリスクになる可能性があり、本番環境では強くお勧めしません

于 2017-01-05T15:13:09.990 に答える