Не додайте хост-ключ у відомі

111

Я хочу підключитися до хоста через SSH, але я не хочу, щоб ім'я хоста було додано до мого ~/.ssh/known_hosts.

Як я можу це зробити?

ssh hosts

99

-o "UserKnownHostsFile /dev/null"

повинні працювати.

— Альберт
джерело

3

Працює за призначенням, але він завжди буде повідомляти: "Попередження: Постійно додано" ім'я хоста, ip "(RSA) до списку відомих хостів." Я змусив це піти: 2> & 1 | grep -v "^Warning: Permanently added"

— Гійом Будро

3

додай -o "помилка LogLevel", і більше не буде скаржитися на попередження

— Джон,

1

Примітка: запит на придушення цього повідомлення "Увага! Постійно додано" ім'я хоста, ip "(RSA) до списку відомих хостів." повідомлялося технічним

— Ben Creasy

2

Трубопровід grepоб'єднає stdout і stderr; також статус виходу може змінитися. При використанні bash, буде краще використовувати заміну процесу , щоб позбутися від повідомлення: ssh 2> >( egrep >&2 -v '^Warning: Permanently added') -o "UserKnownHostsFile /dev/null" [...]. Це дозволить уникнути труби і, відповідно, зміни в обробці статусу виходу.

— Алекс О

1

@John Краще використовувати один із інших методів у цих коментарях, інакше ви вводите недолік безпеки через потенціал приховати інші непов'язані попередження

— Джон Бентлі

97

Якщо ви хочете такої поведінки, оскільки ви працюєте з хмарними серверами (AWS EC2, Rackspace CloudServers тощо) або постійно надаєте нові зображення у Vagrant, можливо, ви захочете оновити конфігурацію SSH замість того, щоб додавати псевдоніми bash або більше опцій на командний рядок.

Спробуйте додати щось на кшталт:

Host *.mydomain.com 
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null
  User foo
  LogLevel QUIET

Використовуйте якомога суворіше регулярне вираження для хоста, щоб бути безпечним.
Якщо встановити LogLevel на QUIET, це дозволить утримати попередження, про яке згадував Гійом

— cclark
джерело

Ви дійсно повинні намагатися не повністю відключити StrictHostKeyChecking, тому відповідь cclark - це великий компроміс для роботи з хмарними серверами.

— Алекс Рекарей

Це виявилося дуже корисним для мене, коли я використовував Shipit (інструмент розгортання JavaScript) проти Vagrant. Я не міг легко дістатись до параметрів, які Шипіт переходив до SSH, тому це дозволило мені перейти до інструменту і сказати йому, що я зробив, і не хотів, щоб він запам'ятовував.

— Джон Мюнш

1

LogLevel - це те, що я шукав. Він має додаткову перевагу в тому, що не показує налаштовану компанією сповіщення під час запуску сценаріїв! (Я бігаю зараз w / loglevel ПОМИЛКА)

— Anshu Prateek,

У який файл я додаю це?

— Вім Деблауве

Це ваш файл конфігурації SSH. В Linux або macOS цей файл, як правило, знаходитиметься в каталозі, який називається .ssh у вашому домашньому каталозі та названий config - ~ / .ssh / config

— cclark

8

Мені здається, що ви хочете додати ключ хоста до своїх знаних_хостів (люди, які працюють із цими службами, на мій досвід, принаймні досить розумні, щоб їхні ключі хостів узгоджувались між машинами, що обслуговують одне ім’я хоста), а потім увімкнули StrictHostKeyChecking, відключивши CheckHostIP та ведення журналу за допомогою ПОМИЛИ LogLevel дасть вам найкращий досвід без шкоди для безпеки. (Гаразд, без CheckHostIP вам потрібно довіряти DNS, який є величезною роззявленою діркою без широкого розповсюдження DNSSEC або чогось подібного; але ми зараз просто змітаємо це під килим.)

Я використовую відомий лише файл для читання, тому мені потрібно щось зробити або я отримую нескінченні попередження про неможливість додавати записи до відомих_хостів.

Що я використовую:

Host github.com *.github.com
StrictHostKeyChecking yes
CheckHostIP no
LogLevel ERROR

Я хотів би, щоб ці служби публікували свої хост-ключі SSH на своїх веб-сайтах через HTTPS, тому я можу скопіювати їх явно без необхідності підключення спочатку і потенційно піддавати себе атаці MITM.

— Кайл Роуз
джерело

7

Для одного сеансу ssh використовуйте це

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@host

— Quanlong
джерело

4

Це не додає нічого нового до прийнятої відповіді на запитання, якому вже 5 років.

— JakeGould

5

я пропоную

LogLevel ERROR

над

LogLevel QUIET

тому ви все одно отримуєте "Не вдалося вирішити ім'я хоста" та інші подібні помилки

— кілофор
джерело

ви повинні мати можливість довіряти своїм SSH-з'єднанням, imho. Не просто замовкніть про свої ризики.

— sylvainulg

3

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

— Алекс Беррі

2

Ви намагалися відключити StrictHostKeyChecking? Це можна зробити за допомогою -oпараметра або у файлі конфігурації ~/.ssh/config.

— jneves
джерело

Я вже використовую це. Але це має інший ефект: він любить строгість перевірки ключа хоста. Тобто, коли хост невідомий, він все ще з'єднується, коли ви вимикаєте цю опцію. Таким чином, це все-таки зберігає господаря. Але я думаю, що знайшов правильне рішення (див. Мою відповідь).

— Альберт

0

Я знайшов такі .ssh / config записи корисними (LAN з DHCP та DNS):

 CheckHostIP no

 Host *.*
 CheckHostIP yes

Результат - назви локальних машин "zora" або "goron" не перевірятимуть динамічно призначені IP-адреси, але www.mycompany.com або node42.planetlab.com все одно підтверджуватимуть статичні IP-адреси.

— sylvainulg
джерело

Не додайте хост-ключ у відомі_хости для SSH