SSH: група DH_GEX поза діапазоном


18

Нещодавно ми застосували постачальницький патч для OpenSSH. Цей патч відключив декілька ключових протоколів обміну у відповідь на недавню атаку на Logjam. Після застосування цього виправлення у нас є кілька постачальників, з якими нам не вдалося обмінятися файлами через sftp, оскільки узгодження з’єднання провалюється (можливо, через застарілі алгоритми обміну ключами).

Я просто хотів би перевірити пару речей, які ми бачимо, перш ніж поговорити з нашими постачальниками. Ось зразок сеансу SSH з одним із постачальників проблем (додано номери рядків):

# ssh -vv user@host.domain.com
01 OpenSSH_6.2p2, OpenSSL 0.9.8j-fips 07 Jan 2009
02 debug1: Reading configuration data /etc/ssh/ssh_config
03 debug1: /etc/ssh/ssh_config line 20: Applying options for *
04 debug2: ssh_connect: needpriv 0
05 debug1: Connecting to host.domain.com [1.2.3.4] port 22.
06 debug1: Connection established.
07 debug1: permanently_set_uid: 0/0
08 debug1: identity file /root/.ssh/id_rsa type -1
09 debug1: identity file /root/.ssh/id_rsa-cert type -1
10 debug1: identity file /root/.ssh/id_dsa type -1
11 debug1: identity file /root/.ssh/id_dsa-cert type -1
12 debug1: identity file /root/.ssh/id_ecdsa type -1
13 debug1: identity file /root/.ssh/id_ecdsa-cert type -1
14 debug1: Enabling compatibility mode for protocol 2.0
15 debug1: Local version string SSH-2.0-OpenSSH_6.2
16 debug1: Remote protocol version 2.0, remote software version GXSSSHD_Comments
17 debug1: no match: GXSSSHD_Comments
18 debug2: fd 3 setting O_NONBLOCK
19 debug1: SSH2_MSG_KEXINIT sent
20 debug1: SSH2_MSG_KEXINIT received
21 debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
22 debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
23 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
24 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
25 debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
26 debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
27 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
28 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
29 debug2: kex_parse_kexinit:
30 debug2: kex_parse_kexinit:
31 debug2: kex_parse_kexinit: first_kex_follows 0
32 debug2: kex_parse_kexinit: reserved 0
33 debug2: kex_parse_kexinit: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256
34 debug2: kex_parse_kexinit: ssh-dss,ssh-rsa
35 debug2: kex_parse_kexinit: aes128-cbc,3des-ctr,aes128-ctr,3des-cbc,blowfish-cbc,arcfour,arcfour128
36 debug2: kex_parse_kexinit: aes128-cbc,3des-ctr,aes128-ctr,3des-cbc,blowfish-cbc,arcfour,arcfour128
37 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-md5-96,hmac-sha1-96,hmac-sha256,hmac-sha256@ssh.com
38 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-md5-96,hmac-sha1-96,hmac-sha256,hmac-sha256@ssh.com
39 debug2: kex_parse_kexinit: none,zlib
40 debug2: kex_parse_kexinit: none,zlib
41 debug2: kex_parse_kexinit:
42 debug2: kex_parse_kexinit:
43 debug2: kex_parse_kexinit: first_kex_follows 0
44 debug2: kex_parse_kexinit: reserved 0
45 debug2: mac_setup: found hmac-md5
46 debug1: kex: server->client aes128-ctr hmac-md5 none
47 debug2: mac_setup: found hmac-md5
48 debug1: kex: client->server aes128-ctr hmac-md5 none
49 debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1536<3072<8192) sent
50 debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
51 DH_GEX group out of range: 1536 !< 1024 !< 8192`

Тож під час узгодження ключового обміну клієнт і сервер обмінюються списками підтримуваних алгоритмів (рядки 21 і 33). Вони погоджуються використовувати перший матч, знайдений у двох списках, в цьому випадку diffie-hellman-group-exchange-sha1. Як я розумію, цей алгоритм підтримує діапазон бітових довжин, які клієнт і сервер потім повинні узгодити. За звичайних обставин, клієнт і сервер домовляються про бітну довжину та ключі обміну, використовуючи DH- moduliфайл простих даних з файлу, наприклад /etc/ssh/moduli(я знаю, що це останнє твердження дуже "говорять миряни", але це приблизно довге і коротке це).

У цьому випадку я думаю, що я бачу - це те, що переговори за тривалістю біт провалюються. У рядку 49 клієнт (мені) каже: "Я підтримую довжину бітів між 1536 і 8192 і хочу використовувати 3072 біт". Однак сервер відповідає у відповідь і каже: "Я підтримую лише 1024 біти". Після цього клієнт здається і каже: "Я не можу з тобою поговорити". Це розумний опис того, що тут відбувається?

Як я розумію, ця проблема повністю стоїть на серверній точці (якщо припустити, що ми не узгоджуємо слабший алгоритм, як diffie-hellman-group1-sha1). Сервер повинен бути змінений для підтримки більшої довжини бітів під час процесу обміну ключами.

Я хотів би переконатися, що я правильно це розумію, перш ніж продовжувати. Введення оцінено.


1
Ви правильно читаєте. Що на землі на іншому кінці? Це не схоже на жоден звичайний ssh-сервер.
Майкл Хемптон

Не маю уявлення, що таке сервер. Ми відчуваємо те саме питання з двома різними постачальниками, обидва - банки. Жоден сервер не ідентифікує себе в сеансі (що не дивно).
заросли

Ви б могли подумати, що банки будуть трохи більше, ніж захист, але на жаль ...
Майкл Хемптон

2
Пошук "GXSSSHD_Comments" виявляє коментарі на різних клієнтських форумах SFTP, що, в свою чергу, начебто говорить про те, що ваш сервер є програмою GXS MFT - дуже підприємливий.
Касталья

Відповіді:


21

Якщо ви хочете використовувати новіший OpenSSH для підключення до застарілих серверів:

ssh -o KexAlgorithms=diffie-hellman-group14-sha1 -o HostKeyAlgorithms=+ssh-dss my.host.com

Додайте -v, якщо ви хочете побачити, що відбувається, і -o HostKeyAlgorithms = ssh-dss, якщо він все ще не працює:

ssh -v -o HostKeyAlgorithms=ssh-dss -o KexAlgorithms=diffie-hellman-group14-sha1 my.host.com

Ви можете, звичайно, редагувати / etc / ssh / ssh_config або ~ / .ssh / ssh_config, і додати:

Host my.host.com *.myinsecure.net 192.168.1.* 192.168.2.*
    HostKeyAlgorithms ssh-dss
    KexAlgorithms diffie-hellman-group1-sha1    

https://forum.ctwug.za.net/t/fyi-openssh-to-access-rbs-openssh-7/6069 згадує таке виправлення на маршрутизаціях Mikrotik:

/ip ssh set strong-crypto=yes

(Відзначаючи це тут, оскільки ця відповідь також з’являється під час пошуку в Інтернеті, шукаючи подібне повідомлення про помилку.)

Якщо ви хочете використовувати його через Git, не редагуючи ssh_config або оновлюючи SSH-сервер:

GIT_SSH="ssh -oHostKeyAlgorithms=+ssh-dss -oKexAlgorithms=diffie-hellman-group14-sha1" git clone ssh://user@host/path-to-repository

2
це також працює для sftp
bao7uo

11

Здається, ви потрапили в цю помилку .

Причина

Була внесена зміна до пакету opensh, який стосувався біржі Diffie-Hellman Group. Раніше ключі розміром 1024 - 8192 можна було обміняти. Мінімальна сума була підвищена до 1536 для додаткової безпеки та уникнення вразливості "logjam". Однак, якщо використовується з деякими сторонніми реалізаціями ssh, які підтримують лише 1024, відбудеться збій. В ідеалі конфігурацію або код сторонніх ssh слід оновити для використання великих розмірів ключів.

...

Ви можете знайти 3 різних резолюції за посиланням. У ситуаціях, коли у вас немає повноважень адміністратора або є занадто багато бюрократії для глибших змін, позбавлення від проблемного алгоритму під час очікування наявності SHA-2 на сервері здалося мені найкращим варіантом. Ви можете навіть виконувати його на основі користувача у вашому файлі $ HOME / .ssh / config.

KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.