Чи є якісь переваги для безпеки для розгортання користувальницьких груп SSH DH до систем, призначених лише для клієнтів?

16

Один із запропонованих стратегій пом'якшення проти атаки, пов'язаних з Logjam на SSH, - це генерувати власні SSH Diffie-Hellman групи, використовуючи щось на кшталт (нижче - для 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, але також будуть вдячні більш загальні відповіді.

ssh ssh-keys logjam

— CVn
джерело

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сторінці чоловіка також є цей цікавий шматочок :

Важливо, щоб цей файл містив модулі діапазону бітових довжин і що обидва кінці з'єднання мають загальні модулі.

Що, здається, заперечує проти заміни існуючих модулів, хоча насправді це не дає фактичної причини для цього.

— Майкл Хемптон
джерело

Пов'язане: Діффі-Хеллман, використовуючи різний модуль з обох сторін на криптографії . На моє обмежене розуміння, видається, що якщо немає спільних модулів потрібної довжини, Діффі-Хеллман із групою такої довжини в загальному випадку неможливий, і це може бути неможливо в будь-якому конкретному випадку. Отже, розподіл модулів між двома кінцевими точками є математичною вимогою протоколу обміну ключами Diffie-Hellman, і спроба здійснити обмін ключами Diffie-Hellman між двома кінцевими точками, які не мають спільних модулів, не вдасться.

— CVn

2

RFC 4419 [ tools.ietf.org/html/rfc4419] - це саме те, що дозволяє серверу надавати власні параметри DH. Сервер надсилає клієнту свої параметри-кандидати, і якщо клієнт погоджується, обидві сторони використовують надані сервером параметри для створення загальної таємниці, яка використовується як ключ сеансу. Отже, це прекрасно, якщо сервер і клієнт не мають однакових записів у своєму файлі модулів.

— Брайан Мінтон

2

Відповідь: Ні. Пільг немає. :)

/etc/ssh/moduli файл використовується тільки на стороні сервера.

Вам не потрібно турбуватися про цей файл для клієнта на SSH:

Ви можете простежити виконання клієнта SSH та перевірити, чи не відкриває він цей файл.

$ strace -e openat ssh user@localhost

— Аді Ройбан
джерело