Чи можу я автоматично додати новий хост до відомих_хостів?


249

Ось моя ситуація: я встановлюю тестовий джгут, який від центрального клієнта запустить декілька екземплярів віртуальної машини, а потім виконувати команди на них через ssh. Віртуальні машини матимуть раніше невикористані імена хостів та IP-адреси, тому їх не буде у ~/.ssh/known_hostsфайлі на центральному клієнті.

Проблема, яка у мене виникає, полягає в тому, що перша sshкоманда, запущена проти нового віртуального екземпляра, завжди придумує інтерактивний запит:

The authenticity of host '[hostname] ([IP address])' can't be established.
RSA key fingerprint is [key fingerprint].
Are you sure you want to continue connecting (yes/no)?

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


5
Для тестового середовища, яке є автономним та фізично захищеним, автоматичне прийняття ключа може спрацювати чудово. Але автоматичне прийняття відкритих ключів у виробничому середовищі або в ненадійній мережі (наприклад, в Інтернеті) повністю обходить будь-який захист від атак зловмисників, які SSH може дозволити собі. Тільки дійсний спосіб , щоб переконатися , що ви захищені від MITM атак для перевірки відкритого ключа хоста через деякий поза зоною довіреної каналу. Немає безпечного способу автоматизувати його без створення помірно складної інфраструктури підписання ключів.
Eil

Відповіді:


141

Установіть StrictHostKeyCheckingпараметр noу конфігураційному файлі або через -o:

ssh -o StrictHostKeyChecking=no username@hostname.com


62
Це залишає вас відкритими для людини при посередніх атаках, ймовірно, не дуже гарна ідея.
JasperWallace

9
@JasperWallace, хоча це, як правило, хороша порада, конкретний випадок використання (розгортання тестових віртуальних машин та відправлення їм команд) повинен бути достатньо безпечним.
Массімо

8
Це дає a Warning: Permanently added 'hostname,1.2.3.4' (RSA) to the list of known hosts.Щоб уникнути попередження та уникнути додавання запису до якогось відомого файла_hosts, я роблю:ssh -o StrictHostKeyChecking=no -o LogLevel=ERROR -o UserKnownHostsFile=/dev/null username@hostname.com
Peter V. Mørch

11
Тому що це не дає відповіді на питання і відкривається до серйозних вразливих місць безпеки.
marcv81

12
@Mnebuerquo: Якщо б ви хвилювались за безпеку, то з цим питанням у вас би нічого не було. Перед вами буде правильний ключ хоста, зібраний з консолі системи, до якої ви хотіли підключитися, і ви вручну перевірили б це при першому підключенні. Ви, звичайно, нічого не зробите "автоматично".
Ігнасіо Васкес-Абрамс

230

ІМО, найкращий спосіб зробити це:

ssh-keygen -R [hostname]
ssh-keygen -R [ip_address]
ssh-keygen -R [hostname],[ip_address]
ssh-keyscan -H [hostname],[ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [hostname] >> ~/.ssh/known_hosts

Це дозволить переконатися, що немає дублікатів, що ви будете охоплені як ім'ям хосту, так і IP-адресою, а також отримаєте хеш-вихід, додатковий захід безпеки.


4
Навіщо потрібні всі 3 ssh-клавіші? Ви не можете обійтись лише першим, оскільки він працює як для імені хоста, так і для ip?
Роберт

6
Чи можете ви бути впевнені, що машина, яка відповідає на запит ssh-keyscan - це справді та, з якою ви хочете поговорити? Якщо ні, ти відкрив себе чоловікові в атаці середнього рівня.
JasperWallace

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

1
Дзвони ssh-keyscanмені не вдалися, оскільки мій цільовий хост не підтримує тип ключа за замовчуванням версії 1. Додавання -t rsa,dsaдо команди виправлено це.
фаза двадцять

5
Це, мабуть, погана ідея. Ви відкриваєтеся до атаки "людина-посередині", оновивши ці клавіші. Щоб уникнути повторюваних записів, перевірте стан повернення ssh-keygen -F [address]замість цього. medium.com/@wblankenship/…
retrohacker

93

Для ледачих:

ssh-keyscan -H <host> >> ~/.ssh/known_hosts

-H хеширує ім'я хоста / IP-адресу


2
"ssh-keyscan -H <host> >> ~ / .ssh / known_hosts" створює запис, схожий на те, що ssh робить при взаємодії з користувачем. (-H хеширує ім’я віддаленого хоста.)
Сара Мессер

3
Вразлива для MITM атак. Ви не перевіряєте відбиток ключа.
Mnebuerquo

8
@Mnebuerquo Ви кажете, що робити, але не як, що було б корисно.
Рей

4
@jameshfisher Так, він вразливий до атак MITM, але ви коли-небудь порівнювали відбиток RSA, який був показаний вам із фактичним сервером, коли ви робили це вручну? Немає? Тож ця відповідь - це спосіб зробити це за вас. Якщо так, ви не повинні використовувати цю відповідь, а робити це вручну або застосовувати інші заходи безпеки ...
п'ять

2
@Mnebuerquo Я був би дуже радий, якщо ви також дасте нам кращий спосіб вирішити це, коли нам потрібно клонувати репо, використовуючи пакетні сценарії, які не відвідували, і ми хочемо обійти цю підказку. Будь ласка, пролийте трохи світла на реальне рішення, якщо ви вважаєте, що це не правильне!
Waqas Shah

42

Як уже згадувалося, використання сканування клавіш було б правильним і ненав’язливим способом зробити це.

ssh-keyscan -t rsa,dsa HOST 2>&1 | sort -u - ~/.ssh/known_hosts > ~/.ssh/tmp_hosts
mv ~/.ssh/tmp_hosts ~/.ssh/known_hosts

Вищезгадане дозволить додати хост, ТІЛЬКИ, якщо він ще не був доданий. Це також не безпечно для одночасності; Ви не повинні виконувати фрагмент на одній і тій же машині походження більше одного разу одночасно, оскільки файл tmp_hosts може зависати, що в кінцевому рахунку призводить до того, що файл знаних_хостів стане роздутим ...


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

1
Оригінальна версія цього файлу плаката мала cat ~/.ssh/tmp_hosts > ~/.ssh/known_hosts, але наступна редакція змінила його на >>. Використання >>- це помилка. Це перемагає призначення унікальності в першому рядку, і змушує його скидати нові записи known_hostsкожен раз, коли він запускається. (Щойно опублікував правку, щоб змінити її назад.)
paulmelnikow

1
Це є тими ж атаками MITM, що й інші.
Mnebuerquo

@utapyngo ssh-keygen -F дасть вам поточний відбиток пальця. Якщо він повернеться порожнім із кодом повернення 1, у вас його немає. Якщо він щось надрукує, а код повернення дорівнює 0, то він уже присутній.
Rich L

1
Якщо ви так сильно піклуєтесь про MITM, розгортайте записи DNSSEC і SSHFP або використовуйте якісь інші безпечні способи розповсюдження ключів, і це рішення відключення буде нерелевантним.
Зарт

19

Ви можете скористатися ssh-keyscanкомандою, щоб схопити відкритий ключ і додати його до свого known_hostsфайлу.


3
Обов’язково перевірте відбиток пальця, щоб переконатися, що це правильний ключ. Інакше ви відкриваєтесь перед атаками MITM.
Mnebuerquo

3
@Mnebuerquo Справедливий момент у загальному контексті, але чому б хтось намагався програмно зібрати ключі, якщо вони вже знали, що є правильним ключем?
Брайан Клайн

Це не спосіб зробити це. MITM.
jameshfisher

8

Ось як можна включити ssh-keyscan у свою гру:

---
# ansible playbook that adds ssh fingerprints to known_hosts
- hosts: all
  connection: local
  gather_facts: no
  tasks:
  - command: /usr/bin/ssh-keyscan -T 10 {{ ansible_host }}
    register: keyscan
  - lineinfile: name=~/.ssh/known_hosts create=yes line={{ item }}
    with_items: '{{ keyscan.stdout_lines }}'

1
Ви завантажуєте відомий дійсний файл known_hosts, або ви робите ssh-keyscan і скидаєте висновок у unknown_hosts без перевірки відбитків пальців?
Mnebuerquo

1
Це просто скидання виводу клавіш, так. Тож по суті це те саме, що StrictHostKeyChecking = ні, лише з тихим оновленням знаних_хостів, без перебору параметрів ssh. Це рішення також не працює добре, оскільки ssh-keysможе повернути кілька рядків, через що це завдання завжди
позначається

Це не спосіб зробити це. MITM.
jameshfisher

3
@jameshfisher Я був би дуже радий, якщо ви також дасте нам кращий спосіб вирішити це, коли нам потрібно клонувати репо, використовуючи пакетні сценарії, які не відвідували, і ми хочемо обійти цю підказку. Будь ласка, пролийте трохи світла на реальне рішення, якщо ви вважаєте, що це не правильне! Будь ласка, дайте нам знати, як це зробити, якщо ви вважаєте, що це не правильний спосіб зробити це!
Вакас Шах

Це ідеально правильний метод додавання значень до знаних_хостів, але так, він сприйнятливий до MITM. Однак для внутрішнього використання це чудово.
Камерон Лоуелл Палмер

7

це було б повним рішенням, приймаючи ключ хоста лише вперше

#!/usr/bin/env ansible-playbook
---
- name: accept ssh fingerprint automatically for the first time
  hosts: all
  connection: local
  gather_facts: False

  tasks:
    - name: "check if known_hosts contains server's fingerprint"
      command: ssh-keygen -F {{ inventory_hostname }}
      register: keygen
      failed_when: keygen.stderr != ''
      changed_when: False

    - name: fetch remote ssh key
      command: ssh-keyscan -T5 {{ inventory_hostname }}
      register: keyscan
      failed_when: keyscan.rc != 0 or keyscan.stdout == ''
      changed_when: False
      when: keygen.rc == 1

    - name: add ssh-key to local known_hosts
      lineinfile:
        name: ~/.ssh/known_hosts
        create: yes
        line: "{{ item }}"
      when: keygen.rc == 1
      with_items: '{{ keyscan.stdout_lines|default([]) }}'

1
Це не спосіб зробити це. MITM.
jameshfisher

6

У мене була аналогічна проблема, і я виявив, що деякі з наданих відповідей лише перейшли до автоматизованого рішення. Далі - це те, що я закінчив, сподіваюся, що це допоможе:

ssh -o "StrictHostKeyChecking no" -o PasswordAuthentication=no 10.x.x.x

Він додає ключ known_hostsі не вимагає ввести пароль.


2
Вразлива для MITM атак. Ви не перевіряєте відбиток пальця.
Mnebuerquo

6
Ніхто не перевіряє відбиток пальців.
Брендан Берд

Це не спосіб зробити це. MITM.
jameshfisher

5

Отже, я шукав мирський спосіб обійти невідомі взаємодії вручну з клонуванням git repo, як показано нижче:

brad@computer:~$ git clone git@bitbucket.org:viperks/viperks-api.git
Cloning into 'viperks-api'...
The authenticity of host 'bitbucket.org (104.192.143.3)' can't be established.
RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)?

Зверніть увагу на відбиток ключа RSA ...

Отже, це SSH річ, це буде працювати для git над SSH та просто пов'язаними з SSH речами загалом ...

brad@computer:~$ nmap bitbucket.org --script ssh-hostkey

Starting Nmap 7.01 ( https://nmap.org ) at 2016-10-05 10:21 EDT
Nmap scan report for bitbucket.org (104.192.143.3)
Host is up (0.032s latency).
Other addresses for bitbucket.org (not scanned): 104.192.143.2 104.192.143.1 2401:1d80:1010::150
Not shown: 997 filtered ports
PORT    STATE SERVICE
22/tcp  open  ssh
| ssh-hostkey:
|   1024 35:ee:d7:b8:ef:d7:79:e2:c6:43:9e:ab:40:6f:50:74 (DSA)
|_  2048 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40 (RSA)
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 42.42 seconds

Спочатку встановіть nmap на щоденний драйвер. nmap дуже корисний для певних речей, як-от виявлення відкритих портів, і це - вручну перевірка відбитків SSH. Але повернемося до того, що ми робимо.

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

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

Незалежно від того, повернемося до початкового рядка, який ми можемо побачити в контексті нижче.

brad@computer:~$ ssh-keyscan bitbucket.org
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-128
no hostkey alg
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-129
bitbucket.org ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-123
no hostkey alg

Отже, випереджаючи, у нас є спосіб запитати форму ідентифікації у вихідного хоста.

На даний момент ми вручну настільки ж вразливі, як автоматично - рядки збігаються, у нас є базові дані, які створюють відбиток пальців, і ми можемо запитати ці базові дані (запобігаючи зіткненням) у майбутньому.

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

Файл known_hosts в цьому випадку не використовує записи в простому тексті. Коли ви побачите їх, ви знаєте хешовані записи, вони виглядають як хеші зі випадковими символами замість xyz.com або 123.45.67.89.

brad@computer:~$ ssh-keyscan -t rsa -H bitbucket.org
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-128
|1|yr6p7i8doyLhDtrrnWDk7m9QVXk=|LuKNg9gypeDhfRo/AvLTAlxnyQw= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==

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

Оскільки я зробив все можливе, щоб отримати незабезпечені дані, які будуть використані для ідентифікації "хоста" та довіри, я додам цю ідентифікацію до файлу знаних_хостів у моєму каталозі ~ / .ssh. Оскільки він тепер буде визначений як відомий господар, я не отримаю вищезазначеного підказки, коли ви були юнаком.

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

#!/bin/bash
cp ~/.ssh/known_hosts ~/.ssh/known_hosts.old && echo "|1|yr6p7i8doyLhDtrrnWDk7m9QVXk=|LuKNg9gypeDhfRo/AvLTAlxnyQw= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==" >> ~/.ssh/known_hosts

Отже, так ви залишаєтесь дівою на сьогодні. Можна зробити те ж саме з github, дотримуючись подібних інструкцій у свій час.

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

НЕПРАВИЛЬНО ssh -oStrictHostKeyChecking = немає імені хоста [команда]

НЕПРАВИЛЬНО ssh-keyscan -t rsa -H ім'я хоста >> ~ / .ssh / known_hosts

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


Я думаю, що це найкраще рішення цієї проблеми. Однак будьте дуже обережні, використовуючи Nmap на чомусь на зразок Amazon EC2, я отримав попередження про сканування портів, що робить Nmap! Заповніть їх форму, перш ніж робити портне сканування!
Waqas Shah

...Ну так. Я не знаю, чому ви зробили б сканування портів із EC2. Якщо ви ввійшли у свій обліковий запис, ви можете просто отримати ключі від фактичних машин. Це більше для машин, над якими ви не маєте контролю. Я б припустив, що у вас буде локальна машина, яка не поширюється на обмеження сканування портів AWS. Але, якщо ви перебуваєте в тій крайовій ситуації, коли вам потрібно запустити nmap з AWS, я вважаю, що це попередження буде корисним.
BradChesney79

Використання nmap для зчитування хоста SSH з вашої робочої станції, а потім довіряти цьому значенню не відрізняється від підключення через SSH із вимкнутим StructHostKeyChecking. Її так само вразливі для атаки людиною в середині.
Micah R Ledbetter

... @ MicahRLedbetter, тому я запропонував, що "більше порівнянь із різних комп’ютерів та мереж зазвичай збільшить вашу здатність довіряти з'єднанню". Але це моя думка. Якщо ви коли-небудь перевіряєте свого цільового хоста з одного набору умов середовища, то як ви коли-небудь дізнаєтесь про будь-які розбіжності? Чи були у вас якісь кращі пропозиції?
BradChesney79

1
Це театр безпеки. Робити щось складне, щоб створити вигляд більшої безпеки. Не має значення, скільки різних методів ви використовуєте, щоб попросити хоста про його ключ. Як і запитати одну і ту ж людину кілька разів, чи можете ви їй довіряти (можливо, ви дзвоните, електронною поштою, текстом та поштою від равлика). Вони завжди скажуть "так", але якщо ви запитаєте неправильну людину, це не має значення.
надзвичайно суперіормен

5

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

(host=github.com; ssh-keyscan -H $host; for ip in $(dig @8.8.8.8 github.com +short); do ssh-keyscan -H $host,$ip; ssh-keyscan -H $ip; done) 2> /dev/null >> .ssh/known_hosts

5

Уникайте повторюваних записів у ~ / .ssh / known_hosts:

if ! grep "$(ssh-keyscan github.com 2>/dev/null)" ~/.ssh/known_hosts > /dev/null; then
    ssh-keyscan github.com >> ~/.ssh/known_hosts
fi

1
Це не спосіб зробити це. MITM.
jameshfisher

Мені найбільше подобається ця відповідь. Для сценарію початкового налаштування випадкових VPS, які не важливі ні для кого, крім мене, ризик MITM суттєво малий. Нескінченно малий кайф ... перший рядок повинен бутиmkdir -p ~/.ssh/known_hosts;
Мартін Брамвелл

5

Як ви будуєте ці машини? чи можна запустити сценарій оновлення dns? чи можете ви приєднатися до домену IPA?

FreeIPA робить це автоматично, але, по суті, все, що вам потрібно, це записи SSHFP dns і DNSSEC у вашій зоні (freeipa надає параметри, що настроюються (dnssec відключений за замовчуванням)).

Ви можете отримати існуючі записи SSHFP від ​​вашого хоста, запустивши.

ssh-keygen -r jersey.jacobdevans.com

jersey.jacobdevans.com В SSHFP-1 4d8589de6b1a48e148d8fc9fbb967f1b29f53ebc jersey.jacobdevans.com В SSHFP-2 6503272a11ba6d7fec2518c02dfed88f3d455ac7786ee5dbd72df63307209d55 jersey.jacobdevans.com В SSHFP-1 5a7a1e8ab8f25b86b63c377b303659289b895736> jersey.jacobdevans.com В SSHFP-2 1f50f790117dfedd329dbcf622a7d47551e12ff5913902c66a7da28e47de4f4b

після опублікування ви додасте VerifyHostKeyDNS yesдо свого ssh_config або ~ / .ssh / config

Якщо / коли Google вирішить перейти на DNSSEC, ви можете ввімкнути скрипт без запиту хост-ключа.

ssh jersey.jacobdevans.com

АЛЕ мій домен ще не підписаний, тому зараз ви бачите ....

debug1: Хост-ключ сервера: ecdsa-sha2-nistp256 SHA256: H1D3kBF9 / t0ynbz2IqfUdVHhL / WROQLGan2ijkfeT0s

debug1: знайдено 4 незахищених відбитка пальців у DNS

debug1: відповідність відбитків ключа хоста

знайдено в DNS. Неможливо встановити справжність хоста "jersey.jacobdevans.com (2605: 6400: 10: 434 :: 10)". Відбиток ключа ECDSA - SHA256: H1D3kBF9 / t0ynbz2IqfUdVHhL / WROQLGan2ijkfeT0. Відбиток пальця ключа хоста, знайдений у DNS. Ви впевнені, що хочете продовжувати з'єднання (так / ні)? немає


4

Щоб правильно це зробити, те, що ви дійсно хочете зробити, - це зібрати відкриті відкриті ключі віртуальних машин під час їх створення та скинути їх у файл у known_hostsформаті. Потім ви можете використовувати -o GlobalKnownHostsFile=..., вказуючи на цей файл, щоб переконатися, що ви підключаєтесь до хоста, до якого ви вважаєте, що вам слід підключитися. Як це зробити, залежить від того, як ви налаштовуєте віртуальні машини, але, якщо можливо, читання його з віртуальної файлової системи або навіть отримання хоста для друку вмісту /etc/ssh/ssh_host_rsa_key.pubпід час конфігурації може зробити трюк.

Однак, можливо, це не варто, залежно від того, в якому середовищі ви працюєте, і хто ваші очікувані супротивники. Зробити просте "зберігання при першому підключенні" (за допомогою сканування або просто під час першого "реального" з'єднання), як описано в кількох інших відповідях вище, може бути значно простіше і все-таки забезпечити деякий простір безпеки. Однак якщо ви це зробите, я настійно пропоную вам змінити відомий користувачеві файл хостів ( -o UserKnownHostsFile=...) на файл, специфічний для цієї конкретної тестової установки; це дозволить уникнути забруднення вашого особистого відомого файлу хостів тестовою інформацією та полегшить очищення непридатних відкритих ключів під час видалення віртуальних машин.


4

Це ціле

  • ssh-key-scan
  • ssh-copy-id
  • Ключове попередження ECSDA

бізнес продовжував мене дратувати, тому я вибрав свій вибір

Один сценарій, щоб керувати ними всіма

Це варіант сценарію за адресою https://askubuntu.com/a/949731/129227 з відповіддю Amadu Bah https://serverfault.com/a/858957/162693 у циклі.

Приклад дзвінка

./sshcheck somedomain site1 site2 site3

Сценарій буде циклічно розміщувати сайти імен та змінювати .ssh / config та .ssh / known_hosts файл та робити ssh-copy-id на запит - для останньої функції просто нехай виклики тесту ssh не вдаються, наприклад, натиснувши клавішу 3 рази на запит на пароль.

скрипт sshcheck

#!/bin/bash
# WF 2017-08-25
# check ssh access to bitplan servers

#ansi colors
#http://www.csc.uvic.ca/~sae/seng265/fall04/tips/s265s047-tips/bash-using-colors.html
blue='\033[0;34m'  
red='\033[0;31m'  
green='\033[0;32m' # '\e[1;32m' is too bright for white bg.
endColor='\033[0m'

#
# a colored message 
#   params:
#     1: l_color - the color of the message
#     2: l_msg - the message to display
#
color_msg() {
  local l_color="$1"
  local l_msg="$2"
  echo -e "${l_color}$l_msg${endColor}"
}

#
# error
#
#   show an error message and exit
#
#   params:
#     1: l_msg - the message to display
error() {
  local l_msg="$1"
  # use ansi red for error
  color_msg $red "Error: $l_msg" 1>&2
  exit 1
}

#
# show the usage
#
usage() {
  echo "usage: $0 domain sites"
  exit 1 
}

#
# check known_hosts entry for server
#
checkknown() {
  local l_server="$1"
  #echo $l_server
  local l_sid="$(ssh-keyscan $l_server 2>/dev/null)" 
  #echo $l_sid
  if (! grep "$l_sid" $sknown) > /dev/null 
  then
    color_msg $blue "adding $l_server to $sknown"
    ssh-keyscan $l_server >> $sknown 2>&1
  fi
}

#
# check the given server
#
checkserver() {
  local l_server="$1"
  grep $l_server $sconfig > /dev/null
  if [ $? -eq 1 ]
  then
    color_msg $blue "adding $l_server to $sconfig"
    today=$(date "+%Y-%m-%d")
    echo "# added $today by $0"  >> $sconfig
    echo "Host $l_server" >> $sconfig
    echo "   StrictHostKeyChecking no" >> $sconfig
    echo "   userKnownHostsFile=/dev/null" >> $sconfig
    echo "" >> $sconfig
    checkknown $l_server
  else
    color_msg $green "$l_server found in $sconfig"
  fi
  ssh -q $l_server id > /dev/null
  if [ $? -eq 0 ]
  then
    color_msg $green "$l_server accessible via ssh"
  else
    color_msg $red "ssh to $l_server failed" 
    color_msg $blue "shall I ssh-copy-id credentials to $l_server?"
    read answer
    case $answer in
      y|yes) ssh-copy-id $l_server
    esac
  fi
}

#
# check all servers
#
checkservers() {
me=$(hostname -f)
for server in $(echo $* | sort)
do
  os=`uname`
  case $os in
   # Mac OS X
   Darwin*)
     pingoption=" -t1";;
    *) ;;
  esac

  pingresult=$(ping $pingoption -i0.2 -c1 $server)
  echo $pingresult | grep 100 > /dev/null
  if [ $? -eq 1 ]
  then 
    checkserver $server
    checkserver $server.$domain
  else
    color_msg $red "ping to $server failed"
  fi
done
}

#
# check configuration
#
checkconfig() {
#https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh
  if [ -f $sconfig ]
  then
    color_msg $green "$sconfig exists"
    ls -l $sconfig
  fi
}

sconfig=~/.ssh/config
sknown=~/.ssh/known_hosts

case  $# in
  0) usage ;;
  1) usage ;;
  *) 
    domain=$1 
    shift 
    color_msg $blue "checking ssh configuration for domain $domain sites $*"
    checkconfig
    checkservers $* 
    #for server in $(echo $* | sort)
    ##do
    #  checkknown $server 
    #done
    ;;
esac

2

Ось як зробити колекцію хостів

визначте колекцію хостів

ssh_hosts:
  - server1.domain.com
  - server2.domain.com
  - server3.domain.com
  - server4.domain.com
  - server5.domain.com
  - server6.domain.com
  - server7.domain.com
  - server8.domain.com
  - server9.domain.com

Потім визначте два завдання, щоб додати ключі до відомих хостів:

- command: "ssh-keyscan {{item}}"
   register: known_host_keys
   with_items: "{{ssh_hosts}}"
   tags:
     - "ssh"

 - name: Add ssh keys to know hosts
   known_hosts:
     name: "{{item.item}}"
     key: "{{item.stdout}}"
     path: ~/.ssh/known_hosts
   with_items: "{{known_host_keys.results}}"

0

Найкраще, щоб ви перевірили відбитки пальців кожного нового сервера / хоста. Це єдиний спосіб аутентифікації сервера. Без цього ваш SSH-з'єднання може бути піддано атаці "людина-в-середині" .

Якщо ви дійсно впевнені, що хочете ігнорувати перевірку відбитків пальців, то другий найкращий, менш безпечний варіант - це використання StrictHostKeyChecking=accept-new, яке було введено у OpenSSH версії 7.6 (2017-10-03) :

Перший "прийняти-новий" автоматично прийме небачені досі ключі, але відмовиться від з'єднань для змінених або недійсних ключів.

Не використовуйте старе значення, StrictHostKeyChecking=noяке взагалі ніколи не перевіряє справжність сервера. (Хоча сенс цього =noналаштування буде викладений деякими версіями пізніше .)

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