Есть ли какие-либо преимущества безопасности при развертывании пользовательских групп SSH DH на клиентских системах?


16

Одна из предлагаемых мер по смягчению последствий атак на SSH, связанных с Logjam, заключается в создании пользовательских групп Диффи-Хеллмана SSH с использованием чего-то подобного (ниже для OpenSSH)

ssh-keygen -G moduli-2048.candidates -b 2048
ssh-keygen -T moduli-2048 -f moduli-2048.candidates

с последующей заменой общесистемного файла модулей выходным файлом moduli-2048. ( ssh-keygen -Gиспользуется для генерирования кандидатов на простые числа DH-GEX и ssh-keygen -Tдля проверки сгенерированных кандидатов на безопасность.)

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

Меня в первую очередь интересуют ответы, касающиеся OpenSSH в Linux, но более общие ответы также приветствуются.

Ответы:


18

Вы можете, если действительно хотите, но я бы не стал восстанавливать 2048-битные параметры DH для OpenSSH. Есть намного более важные вещи, которые вы должны сделать для защиты SSH, например, отключение слабого шифрования .

Что я хотел бы сделать, это удалить существующие, которые меньше, чем 2048 бит.

awk '$5 >= 2000' /etc/ssh/moduli > /etc/ssh/moduli.strong && \
mv /etc/ssh/moduli.strong /etc/ssh/moduli

Если вы не заметили, OpenSSH поставляется с большим количеством предварительно сгенерированных модулей, вплоть до 8192 бит. В то время как мы, безусловно, обеспокоены 1024-битными простыми числами сегодня, 2048-битные считаются безопасными в обозримом будущем. И хотя в конечном итоге это изменится, это может произойти на следующей неделе, но, скорее всего, это произойдет еще долго после того, как мы станем пенсионерами ...

На ssh-keygenстранице справочника также есть интересный момент :

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

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


Связанный: Диффи-Хеллман, использующий разные модули с обеих сторон в криптографии . Насколько я понимаю, кажется, что, если нет общих модулей желаемой длины, Диффи-Хеллман с группой такой длины невозможен в общем случае и может быть невозможен в любом конкретном случае. Следовательно, наличие модулей, совместно используемых двумя конечными точками, является математическим требованием протокола обмена ключами Диффи-Хеллмана, и попытка выполнить обмен ключами Диффи-Хеллмана между двумя конечными точками, которые не имеют общих модулей, потерпит неудачу.
CVn

2
RFC 4419 [ tools.ietf.org/html/rfc4419] предназначен для того, чтобы сервер мог предоставлять собственные параметры DH. Сервер отправляет свои параметры-кандидаты клиенту, и, если клиент соглашается, обе стороны используют предоставленные сервером параметры для генерации общего секрета, который используется в качестве ключа сеанса. Таким образом, это прекрасно, если сервер и клиент не имеют одинаковых записей в своем файле модулей.
Брайан Минтон

2

Ответ: Нет. Нет никаких преимуществ. :)

/etc/ssh/moduli Файл используется только для серверной части.

Вам не нужно беспокоиться об этом файле для клиентской части SSH:

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

$ strace -e openat ssh user@localhost
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.