Не добавляйте hostkey в known

110

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

Как я могу это сделать?

ssh hosts

97

-o "UserKnownHostsFile /dev/null"

должно сработать.

— Альберт
источник

3

Работает так, как задумано, но всегда будет сообщать: «Предупреждение. Постоянно добавлено имя хоста, ip (RSA) в список известных хостов». Я сделал, что уйти с: 2> & 1 | grep -v "^Warning: Permanently added"

— Гийом Будро

3

добавьте -o "ОШИБКА LogLevel", и он больше не будет жаловаться на предупреждения

— Джон

1

Примечание: запрос на подавление этого сообщения «Предупреждение. Постоянно добавлено имя хоста, ip (RSA) в список известных хостов». было сообщено сопровождающим bugzilla.mindrot.org/show_bug.cgi?id=2413

— Бен

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 - это то, что я искал. Он имеет дополнительное преимущество: он не отображает настроенное уведомление компании при запуске сценариев! (Я бегу сейчас с ошибкой лог-уровня)

— Anshu Prateek

В каком файле я могу добавить это?

— Вим Deblauwe

Это ваш файл конфигурации SSH. В Linux или macOS файл обычно находится в каталоге с именем .ssh в вашем домашнем каталоге и называется config - ~ / .ssh / config

— cclark

8

Я чувствую, что мне нужно добавить ключ хоста в ваших known_hosts (по моему опыту, люди, работающие с этими сервисами, по крайней мере достаточно умны, чтобы их хост-ключи оставались согласованными между компьютерами, обслуживающими одно и то же имя хоста), а затем включили StrictHostKeyChecking, отключили CheckHostIP и регистрация с LogLevel ERROR даст вам лучший опыт без ущерба для безопасности. (Хорошо, без CheckHostIP вам действительно нужно доверять DNS, который является огромной зияющей дырой без широко распространенного DNSSEC или чего-то подобного; но мы просто покажем это под ковром.)

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

Что я использую:

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

так что вы все еще получаете «Не удалось разрешить имя хоста» и другие подобные ошибки

— kiloforce
источник

ты должен быть в состоянии доверять своим 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
источник

Не добавляйте hostkey в known_hosts для SSH