SSH_MSG_KEX_GEX_GROUP

Скорее всего в клиенте не поддерживаются методы шифрования/обмена ключами, разрешенные на сервере - https://superuser.com/questions/1386741/openssh-7-9-key-exchange-failed-expec...

Судя по версии клиента, единственный возможный вариант - разрешить устаревшие методы на сервере

Копать в сторону опции KexAlgorithms в sshd_config на сервере

Pinkbyte, спасибо за отклик.

Удалось выяснить что sftp клиент пытается создать подключение посредством java

Caused by: com.maverick.ssh.SshException: Key exchange failed: Expected SSH_MSG_KEX_GEX_GROUP [id=3] [Unknown cause]
        at com.maverick.ssh.components.jce.DiffieHellmanGroupExchangeSha1.performClientExchange(Unknown Source)
        at com.maverick.ssh2.TransportProtocol.e(Unknown Source)
        at com.maverick.ssh2.TransportProtocol.processMessage(Unknown Source)
        at com.maverick.ssh2.TransportProtocol.startTransportProtocol(Unknown Source)
        at com.maverick.ssh2.Ssh2Client.connect(Unknown Source)
        at com.maverick.ssh.SshConnector.connect(Unknown Source)
        at com.maverick.ssh.SshConnector.connect(Unknown Source)

такую ошибку генерит класс DiffieHellmanGroupExchangeSha1.java из состава j2ssh-maverick:

final static int SSH_MSG_KEXDH_GEX_GROUP = 31;

byte[] tmp = transport.nextMessage();

			if (tmp[0] != SSH_MSG_KEXDH_GEX_GROUP) {
				transport.disconnect(TransportProtocol.KEY_EXCHANGE_FAILED,
						"Expected SSH_MSG_KEX_GEX_GROUP");
				throw new SshException(
						"Key exchange failed: Expected SSH_MSG_KEX_GEX_GROUP [id="
								+ tmp[0] + "]", SshException.INTERNAL_ERROR);

			}

Собственно из за этого кода и получается описание ошибки «Key exchange failed: Expected SSH_MSG_KEX_GEX_GROUP [id=3]»

Получается что при запросе SSH2_MSG_KEX_DH_GEX_REQUEST, ожидается получить код «31», чтобы подключение производилось далее по сценарию.

Если с клиента c OpenSSH_7.2p2 подключаться по «ssh -vvv» к удаленной станции с OpenSSH_5.3p1, то возвращается следующий стек:

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<3072<8192) sent
debug3: receive packet: type 31
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug2: bits set: 1511/3072
debug3: send packet: type 32
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug3: receive packet: type 33
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY

а если же c клиента (с OpenSSH_5.3p1) к стации с (OpenSSH_5.3p1 или с OpenSSH_7.2p2), то будет будет получен стек такого плана:

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug3: Wrote 24 bytes for a total of 909
debug2: dh_gen_key: priv key bits set: 162/320
debug2: bits set: 1044/2048
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

Как видно, в первом случае возвращается «type 31», а во втором - вообще не понятно откуда получается значение «3» ([id=3]). Почему стек такой разный и как во втором случае увидеть откуда получается код «3»? Быть может из за версии OpenSSH на клиенте изменяется стек?

Слово «стек» тут не в тему. Это лог произошедших событий, в том числе местами принятых и отправленных пакетов. Он, конечно, немного зависит и от версии openssh (как на клиенте, так и на сервере) так и от настроек.

Можешь попытаться выяснить, что за пакет с id 3 и что-нить станет яснее. Ещё можно поиграться с настройками сервера (что-нить включить, что-нить отключить, особенно если у тебя есть сервер с которым всё работает - сравнить конфиги). Но я бы начал с обновления клиентского софта (той java библиотеки для ssh, вданном случае), возможно в новых версиях всё уже нормально.

Гугл по запросу «SSH_MSG_KEXDH_GEX_GROUP = 31» выдает возможное решение проблемы - https://pitstop.manageengine.com/portal/en/kb/articles/ssh-public-key-aunthen...

Как я и подозревал ранее - нужно правит KexAlgorithms на сервере

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