Насколько плохо иметь несколько устройств с одинаковыми ключами сервера SSH?

Вместо того, чтобы хранить специфичные для хоста данные, такие как ключи хоста ssh, на SD-карте или другом носителе, доступном только для чтения, вы можете хранить их в NVRAM, для чего они нужны во встроенной системе. Вам нужно будет создать несколько пользовательских сценариев для хранения и извлечения ключей во время загрузки, но сценарии будут одинаковыми для всех устройств.

Влияние доставки одной и той же пары ключей со всеми вашими устройствами напрямую связано с безопасностью клиентов, подключающихся к ним, поскольку это означает, что нет возможности (от клиента SSH) однозначно идентифицировать устройство, к которому он может подключаться. В случае утечки пары ключей ее можно использовать для атак MITM.

С другой стороны, повторное создание ключей при каждой загрузке также вызовет предупреждение на клиентах.

Для справки из man ssh(1):

ssh автоматически поддерживает и проверяет базу данных, содержащую идентификационные данные для всех хостов, с которыми он когда-либо использовался. Ключи хоста хранятся в ~/.ssh/known_hosts в домашнем каталоге пользователя. Кроме того, файл /etc/ssh/ssh_known_hosts автоматически проверяется на наличие известных хостов. Любые новые хосты автоматически добавляются в файл пользователя. Если идентификация хоста когда-либо изменится, ssh предупреждает об этом и отключает аутентификацию пароля, чтобы предотвратить подмену сервера или атаки типа «злоумышленник в середине», которые в противном случае можно было бы использовать для обхода шифрования. В StrictHostKeyChecking Параметр может использоваться для управления входами в систему на машинах, ключ хоста которых неизвестен или был изменен.

Похоже, что в первом варианте ключи SSH будут доступны на SD-карте. Так что любой пользователь мог взять карту и прочитать их. Таким образом, ваши личные ключи стали (в основном) общедоступными.

Это позволит провести атаки типа "злоумышленник посередине", например:

1. Пользователь настраивает SSH-сервер с закрытыми ключами, полученными с вашего устройства, и передает этот IP-адрес вашему техническому специалисту.
2. Ваш технический специалист вводит пароль root через соединение SSH.
3. Теперь пользователь знает пароль root, действительный для всех ваших устройств.

Однако вам не следует использовать пароли root, вместо этого используйте ssh-ключи для аутентификации. Тогда влияние общих серверных ключей довольно невелико. если вы входите в систему только из локальной сети.

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

Я с ужасом прочел это! Я, который работал на нескольких машинах в одном кластере с одним и тем же ключом хоста ssh, никогда не осмелился бы сделать это. Ни при каких обстоятельствах не позволяйте машинам с разными наборами администраторов совместно использовать ключи хоста ssh. В этом и заключается безумие и вопиющий ужас, когда вас отправляют на почту из-за отсутствия безопасности.

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

Поскольку вы упомянули, что доступ SSH не используется конечным пользователем / клиентом, вы можете отключить доступ SSH по умолчанию и включить его только временно, когда устройство переведено в режим «отладки».

Затем вы можете отправить все устройства с одним и тем же ключом, предполагая, что вы защитили режим «отладки», чтобы он не мог быть запущен удаленно кем-то, кто пытается взломать устройство.

Или у вас есть новый ключ, сгенерированный, когда устройство переходит в режим «отладки» - так что вам не нужно тратить время загрузки на создание ключей каждый раз, когда устройство включается.

Вот пример сценария атаки, основанный на имеющихся у вас ограничениях:

Если ваши устройства такие, скажите, например, Raspberry Pi. Если я подойду и выдерну SD-карту из одного, я могу вставить SD-карту в свой компьютер, найти ключ sshd и скопировать его куда захочу. Может быть, я возьму свой собственный Raspberry Pi и карту Ethernet USB. Теперь я могу вставить это между целевым устройством и куда бы они ни направлялись, и отслеживать ssh-соединения. Когда я вижу, что целевое устройство пытается установить ssh-соединение, я делаю следующее:

(target) <---> (my evil sshd <--> decrypted traffic <--> ssh) <---> (real server)
                                       |
                                       V
                                    log file

Ой, что это? Ваш пароль: «Я люблю кошек»? Мальчик, это интересное письмо, которое ты отправил своей жене. Бьюсь об заклад, было бы еще интереснее, если бы она прочитала это письмо, которое вы отправили жене вашего соседа.

Возможности бесконечный. И цель никогда не узнает, потому что ключ sshd идентичен ключу, найденному на реальном сервере. В зависимости от физической безопасности объектов, которые принимают ваше устройство, это может быть невероятно банально. Не делай этого.

Вместо этого делайте то, что вы уже предлагаете, но почини это. Прежде чем писать образ, запустите что-то вроде этого:

ssh-keygen -f some-new-server
cp some-new-server /path/to/the/mounted/image/sshd/key
cp some-new-server.pub /path/to/the/mounted/image/sshd/key.pub

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