Файл, отправленный из системы с использованием OpenSSH 7.4p1, не принимается системой, использующей OpenSSH 8.7p1 – Как это разрешить?

У меня есть старая система Linux, и я использую проприетарное программное обеспечение, которое пытается копировать файлы (с помощью sftp или curl) на более новую систему Linux, но это не удается. Системы следующие:

Сниффинг обмена показал:

• Пакет ответа на обмен группой Диффи-Хеллмана на сервере подтверждает следующие согласованные параметры:
  • Алгоритм обмена ключами (KEX): diffie-hellman-group-exchange-sha256 (соответствует поддержке клиента ✅)
  • Алгоритм шифрования: aes128-ctr (соответствует поддержке клиента ✅)
  • Алгоритм MAC: hmac-sha2-256 (соответствует поддержке клиента ✅)
  • Сжатие: none (соответствует поддержке клиента ✅)
  • Тип ключа хоста: ssh-rsa (соответствует поддержке клиента ✅, но см. ниже)
  • Тип подписи хоста: rsa-sha2-256 (потенциальная проблема ⚠️)

Тип ключа хоста в ответе KEX сервера – ssh-rsa, который поддерживается клиентом. Однако тип подписи, используемый сервером, – rsa-sha2-256, который клиент не заявлял о поддержке в своем сообщении SSH_MSG_KEXINIT.

Я выяснял, какие изменения можно сделать в файлах /etc/ssh/ssh_config и /etc/ssh/sshd_config на системе Rocky Linux 9.5 для поддержки этого обмена, но не нашел. Я также пробовал добавить следующее в /etc/ssh/sshd_config (как предложено в этом другом случае), но это также не получилось:

  # Разрешить немного устаревший выбор шифра
  Ciphers +aes128-cbc

  # Разрешить переговоры с использованием слабого DH
  # (добавлять group1 только при крайней необходимости)
  KexAlgorithms +diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

  # Предлагать SHA1 подписи для pubkey хоста
  HostKeyAlgorithms +ssh-rsa

  # Принимать SHA1 подписи для pubkey клиента
  PubkeyAcceptedAlgorithms +ssh-rsa

Настоящим решением будет обновление старой системы CentOS 7 derivative, но перед этим мне нужно, чтобы копирование файлов работало для завершения нескольких тестов.

Поэтому я ищу временное решение, где я мог бы изменить конфигурацию системы Rocky Linux 9.5 для разрешения передачи файлов. Кто-нибудь знает, какое изменение/дополнение нужно сделать в конфигурации?

Корень проблемы в общеизвестном факте, что RHEL 9 по умолчанию использует более строгие криптографические настройки, которые нарушают совместимость со старыми системами.

Вторая часть проблемы заключается в том, что RHEL 9 и такие производные, как Rocky Linux, влияют на криптографические настройки SSHD так, что они обходят любые криптографические настройки в /etc/ssh/sshd_config, используя “криптографические политики”. См. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening

(В случае sshd (и других подобных демонов) криптополитика реализуется unit-ом systemd, добавляющим определенные опции командной строки, которые переопределяют настройки, найденные в /etc/ssh/sshd_config.)

Ваши варианты для SSH-демона на системе RHEL 9 следующие:

• Переключить системную криптографическую политику на режим совместимости с более ранними выпусками, как описано в руководстве по упрочнению RHEL 9. В качестве root (или с sudo) выполните:

  # update-crypto-policies --set LEGACY
  Установка системной политики в LEGACY
  

  и перезагрузитесь.

  Примечание: это изменяет все демоны и системные настройки и является избыточным, если вам нужно настроить только ssh и sshd.

• Исключить (только) sshd из системной криптографической политики.
  Вы можете отказаться, отредактировав /etc/sysconfig/sshd и раскомментировав строку # CRYPTO_POLICY=, (при необходимости вы можете дополнительно настроить /etc/ssh/sshd_config и добавить старые крипто-настройки). Это заставит ssh-демона снова обращаться только к файлу конфигурации для крипто-настроек. Может потребоваться использовать [sudo] systemctl daemon-reload, и вам точно нужно будет перезапустить ssh-демона с помощью [sudo] systemctl restart sshd