Недавно мы применили патч от поставщика для OpenSSH. Этот патч отключил несколько протоколов обмена ключами в ответ на недавнюю атаку Logjam. После применения этого патча у нас есть несколько поставщиков, с которыми мы не можем обмениваться файлами через sftp, поскольку согласование соединения не удается (вероятно, из-за устаревших алгоритмов обмена ключами).
Я хотел бы просто проверить пару вещей, которые мы видим, прежде чем говорить с нашими поставщиками. Вот пример сеанса SSH с одним из проблемных поставщиков (номера строк добавлены):
# ssh -vv [email protected]
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: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],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,[email protected]
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,[email protected]
25 debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
26 debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
27 debug2: kex_parse_kexinit: none,[email protected],zlib
28 debug2: kex_parse_kexinit: none,[email protected],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,[email protected]
38 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-md5-96,hmac-sha1-96,hmac-sha256,[email protected]
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
Если вы хотите использовать более новую версию 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
Кажется, вы попали в эту точкуошибка.
Причина
В пакет openssh было внесено изменение, касающееся обмена группами Диффи-Хеллмана. Ранее можно было обмениваться ключами размером 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