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


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

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

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

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

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

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

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

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

PS Кто-то может создать интернет-теги?

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

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


21
2017-12-04 17:44


Источник


Если вы имеете в виду ключи хоста, пользователи с более чем одним из устройств могут получать предупреждения в зависимости от конфигурации клиента ssh. более серьезные проблемы будут связаны с действительными ключами аутентификации ssh. Надеюсь, вы не устанавливаете какие-либо секретные ключи, и, надеюсь, ваши открытые ключи ограничены конкретными исходными сетями, и, надеюсь, ваши личные ключи, принадлежащие вашим технологиям, имеют сильную кодовую фразу на них, и, надеюсь, эти ключи никогда не будут проверяться в репо по ошибке. Из-за этих вещей IoT получают очень плохое имя. Не говоря, что бы вы сказали, что это большая проблема. - Aaron
Я говорю об установке того же самого частного ключа на всех серверах, если это то, что вы имеете в виду. - NXT
Использование одинакового имени пользователя и пароля на всех устройствах - очень плохая идея. Это проще для грубой силы, чем закрытый ключ, используемый для аутентификации с открытым ключом. Даже если эти отклонения не должны быть напрямую связаны с Интернетом, кто-то все равно сделает это. И если «не напрямую подключен» означает NAT, они достаточно связаны ... - Tero Kilkanen
Совместное использование ключа SSH означает, что тот, кто может получить доступ к закрытому ключу на одном устройстве, может выдавать себя за все эти устройства. - immibis
Хотя это интересный вопрос, я ничего не вижу об этом, относящемся к системному администрированию, и, таким образом, отключен от темы для Server Fault. Вы спрашиваете о разработке интерфейса отладки / диагностики для встроенного устройства, которое вы отправляете, а не интерфейса, который будет иметь отношение к системным администраторам. Этот вопрос можно было бы перенести на Информационная безопасность, - 200_success


Ответы:


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


27
2017-12-04 19:50





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

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

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

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


12
2017-12-04 18:25



Я не понимаю, почему они не могут просто генерировать один раз (на каждом устройстве, при первой загрузке), а затем никогда не генерируются снова (если они не удаляются)? - djsmiley2k
Прекрасно выполнимо. Но OP утверждает, что он хочет: «Смонтировать файловую систему памяти и сгенерировать ключи сервера при каждой загрузке». Поэтому мой ответ предполагает это. - dawud
ах, я пропустил это, когда прочитал его в первый раз. - djsmiley2k


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

Это позволит атаковать «человек-в-середине», например:

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

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

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


5
2017-12-05 13:00



Смешно, как наши предубеждения могут ослепить нас (меня). SD-карта находится внутри устройства за панелью и под печатной платой, поэтому мне никогда не приходило в голову, что кто-то вытащит ее. Однако вы правы, он абсолютно доступен любому, у кого есть отвертка. Спасибо за напоминание, чтобы рассмотреть физическую безопасность системы. - NXT
WRT # 2, пароль root не должен быть отправлен по SSH-соединению. Он должен вводиться в терминал-клиент и использоваться для локальной половины протокола аутентификации, который доказывает владение секретом, не передавая секрет («доказательство знания»). Даже десятилетние системы знали, что нужно посылать хэш пароля, а не пароль. Включите nonce в протокол challenge / response, и злоумышленник не знает оригинального пароля и не может использовать токен, который можно использовать на своем месте. - Ben Voigt
@BenVoigt Я думаю, что большинство систем unix передают пароль на сервер. Теневой файл хранит только хеш, но вы не хотите доверять хешу, сгенерированному клиентом, потому что иначе кто-то сможет войти в систему с украденным хешем, не обращая его. Таким образом, сервер должен знать фактический пароль для запуска bcrypt или подобного на нем. - jpa


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

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


2
2017-12-06 03:56



Не могли бы вы рассказать о том, как злоумышленник будет использовать закрытый секретный ключ для защиты других устройств? - jpa
@jpa: для ключей хоста, путем перехвата и кражи паролей и т. д. Кроме того, эта установка, похоже, предлагает делать то же самое с пользовательскими ключами. - joshudson


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

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

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


2
2017-12-06 11:44



Мне нравится эта идея. - NXT


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

Если ваши устройства, скажем, малиновый Pi, например. Если я поднимусь и выдержу SD-карту от одной, я могу закрепить SD-карту на своем собственном компьютере, найти ключ sshd и скопировать его везде, где захочу. Может быть, я возьму свой собственный малиновый пи и карту 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

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


2
2017-12-06 12:39



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