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

Я работаю на встроенном устройстве, которое работает на FreeBSD и SSH.

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

Мои два варианта, как я их вижу:

• Отправляйте одинаковые ключи сервера sshd на все устройства
• Смонтируйте файловую систему памяти и генерируйте серверные ключи при каждой загрузке (медленно ...)

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

В большинстве случаев устройство не будет подключено к Интернету.

Вход с использованием SSH не является частью нормальной работы. Это в основном для удобства программистов и техников. Клиенты не будут входить в устройство с SSH.

Каковы последствия использования одних и тех же ключей сервера на нескольких аппаратных устройствах?

PS Может кто-нибудь создать тег интернета вещей?

РЕДАКТИРОВАТЬ : я говорю об установке одинаковых личных ключей хоста на всех серверах (устройствах). Что касается открытых / закрытых ключей пользователя, в настоящее время нет планов использовать регистрацию на основе ключей - это будет логин с паролем. Опять же, один и тот же пароль на всех серверах (устройствах).

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

Вместо хранения данных, специфичных для хоста, таких как ключи хоста 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 и USB-карту Ethernet. Теперь я могу вставить это между целевым устройством и тем, куда они направляются, и отслеживать 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

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