Как добавить известный хост SSH в скрипт bash?


13

Я создаю сценарий bash для предоставления нового сервера, на котором я могу развернуть веб-приложение. Одна вещь, которую я всегда должен делать, это использовать GitHub как известный хост ssh git@github.com. Как я могу автоматизировать этот процесс в bash-скрипте и сделать это идемпотентным способом?

Ответы:


17

Самый простой способ - сделать что-то вроде этого.

ssh-keyscan remote_server >>~/.ssh/known_hosts

Если это поле совершенно новое, вам также может понадобиться создать ~/.sshкаталог перед запуском ssh-keyscan .

Имейте в виду, что ssh-keyscan может принимать произвольное количество имен хостов. Он получит все возможные ключи.


1
PS - Для обеспечения вы должны использовать что-то вроде puppet вместо bash-скрипта. Для кукол это можно легко сделать с помощью ресурса sshkey . Также см. Этот вопрос, чтобы узнать о методе массового управления известного_хоста serverfault.com/a/416782/984
— Zoredache

2
Это, конечно, звучало хорошо для меня, но потратив несколько часов на кукол и конкурентов, я побежал обратно к сценариям bash и здравомыслию. Если эти инструменты интуитивно понятны, у меня явно нет интуиции. YMMV.
— Рон Берк

Используйте Bash. Я постоянно сталкиваюсь с проблемами в разных версиях таких вещей, как марионетка или ансибл. Мы всегда возвращаемся к bash ... 3 компании, работающие сейчас, вот так, и bash всегда для нас надежен.
— Ligemer

4

Вы пытаетесь автоматизировать принятие нового ключа? Если это так, вы можете использовать -oStrictHostKeyChecking = no.
Это очень плохая идея, поскольку теперь вы полностью открыты для атак «человек посередине».

Лучшим вариантом было бы просто управлять файлом known_hosts и повторно использовать этот файл при подготовке новых серверов. Прикрепите его к github и напишите простой скрипт для загрузки этого файла, прежде чем загружать его в github.

Строгая проверка ключа хоста - это хорошо.


Можете ли вы уточнить, что такое «управлять файлом known_hosts»? Я думаю, что это то, что я хочу сделать, но когда я просмотрел файл, его содержимое выглядело как своего рода хэш / ключ и не выглядело как нечто, предназначенное для управления вручную.
— Андрей

2
Подготовьте новый сервер, вручную вставив ssh в github. Примите ключ хоста, когда будет предложено. Выйти. Скопируйте ~ / .ssh / known_hosts с этого недавно подготовленного сервера в другое место (github, веб-сервер, не имеет значения, пока вы можете его получить). В следующий раз, когда вы подготовите сервер, скопируйте этот файл обратно перед загрузкой в ​​github. Вам не нужно редактировать файл.
— yoonix

Это лучше, чем мой ответ (безопаснее). Тем не менее, дальнейшее улучшение ответа yoonix состоит в том, чтобы разобрать 'ssh-keyscan github.com' и сохранить возвращенный ключ в ~ / .ssh / known_hosts, чтобы он не был статичным в каком-либо файле, который вам нужно было обновить.
— Sirex

Это тоже сработало бы, но я бы не стал считать это лучше. Вы потенциально настраиваетесь на атаку «человек посередине», если каждый раз получаете новый ключ хоста.
— yoonix

1
Чтобы прояснить мой последний комментарий (слишком поздно для редактирования): захват нового ключа хоста каждый раз, когда вы предоставляете хост, функционально не отличается от установки StrictHostKeyChecking = no. С любым из них вы слепо доверяете тому, что ключ отправляется каждый раз, когда вы предоставляете. Если вы думаете, что атака MITM маловероятна, прочитайте эти две статьи. Github будет ОГРОМНОЙ целью.
— yoonix

1

Я не уверен, что понимаю вопрос, но я думаю, что вы хотите игнорировать приглашение known_host или избегать его полностью, в этом случае:

ssh -o StrictHostKeyChecking = нет

или другие предложения по адресу: http://www.joedog.org/2012/07/ssh-disable-known_hosts-prompt/


Мне нужен неинтерактивный способ получения ключа хоста GitHub (так как это будет происходить в скрипте bash).
— Андрей

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