Вопрос или проблема
У меня есть следующая старая система Linux, и я использую проприетарный программный инструмент, который пытается скопировать файлы (с помощью sftp или curl) на более новую систему Linux, но это не удается. Системы:
Свойство | Исходная система | Целевая система |
---|---|---|
OS | Производная от CentOS 7 | Rocky Linux 9.5 |
ssh -V | OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017 |
OpenSSH_8.7p1, OpenSSL 3.2.2 4 Jun 2024 |
При прослушке обмена мы видим:
- Пакет ответа группы обмена Diffie-Hellman сервера подтверждает следующие согласованные параметры:
- Алгоритм обмена ключами (KEX): diffie-hellman-group-exchange-sha256 (совпадает с поддержкой клиента ✅)
- Алгоритм шифрования: aes128-ctr (совпадает с поддержкой клиента ✅)
- Алгоритм MAC: hmac-sha2-256 (совпадает с поддержкой клиента ✅)
- Сжатие: нет (совпадает с поддержкой клиента ✅)
- Тип хоста: 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 для публичного ключа хоста
HostKeyAlgorithms +ssh-rsa
# Принимать подписи SHA1 для публичного ключа клиента
PubkeyAcceptedAlgorithms +ssh-rsa
Реальным решением будет обновление этой старой производной CentOS 7, но прежде чем сделать это, мне нужно завершить несколько тестов, чтобы работа копирования файлов прошла успешно.
Поэтому я ищу временное решение, в котором я мог бы изменить конфигурацию системы 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 (и другими аналогичными демонами) криптополитика влияет на параметры командной строки, добавляемые системной службой systemd, которые переопределяют настройки, найденные в /etc/ssh/sshd_config
.)
Ваши варианты для демон SSH на системе RHEL 9:
-
Переключить систему на криптографическую политику, совместимую с более ранними выпусками, как описано в руководстве по укреплению безопасности RHEL 9. Запустите от имени
root
(или сsudo
):# update-crypto-policies --set LEGACY Setting system policy to LEGACY
и перезагрузите систему.
Примечание: это изменяет все демоны и настройки системы и является чрезмерным, если вам нужно регулировать только настройки ssh и sshd.
-
Исключить (только) sshd из системной криптографической политики.
Вы можете отказаться, отредактировав/etc/sysconfig/sshd
и раскомментировав строку# CRYPTO_POLICY=
, (при необходимости затем можно дополнительно отрегулировать/etc/ssh/sshd_config
и добавить устаревшие криптографические настройки). Это заставит демон ssh снова использовать только его файл конфигурации для криптографических настроек. Может понадобиться выполнить[sudo] systemctl daemon-reload
и обязательно перезапустить демон ssh с помощью[sudo] systemctl restart sshd
Ответ или решение
По сути, проблема связана с несовместимостью криптографических алгоритмов между более старой и более новой версиями OpenSSH, используемыми в вашей системе. Ваше исходное оборудование работает на OpenSSH 7.4, в то время как целевая система использует OpenSSH 8.7. Эти версии OpenSSH отличаются уровнем поддержки различных криптографических алгоритмов и протоколов, что может привести к невозможности установить соединение из-за различий в конфигурации безопасности.
Теория
В версии OpenSSH 8.7 были введены более строгие настройки по умолчанию, направленные на повышение уровня безопасности. Это, в свою очередь, приводит к несовместимости с устаревшими версиями, такими как OpenSSH 7.4, особенно при использовании алгоритмов и протоколов, которые больше не считаются безопасными. В частности, использование хеша rsa-sha2-256
вместо ssh-rsa
в процессе подписи ключей хоста является одной из причин проблем, с которыми вы столкнулись.
Пример
Как вы уже заметили, в вашем случае сервер Rocky Linux 9.5 использует алгоритмы, которые не поддерживаются вашим клиентом. В рамках сетевого обмена, описанного вами, вы видите, что клиент поддерживает ssh-rsa
, но сервер использует подписание rsa-sha2-256
, что несовместимо.
Применение
-
Адаптация системных криптографических политик
RHEL 9 и производные, такие как Rocky Linux, используют системные криптографические политики, которые задают стандартные настройки безопасности для всех сервисов, включая sshd. Вы можете изменить глобальные криптографические политики на более слабые, совместимые с устаревшими системами с помощью этой команды:
sudo update-crypto-policies --set LEGACY
Это позволит вашему серверу использовать более слабые криптографические алгоритмы, включенные в категорию LEGACY. Однако, это изменение повлияет на все сервисы, что может снизить общую безопасность системы.
Важно: Убедитесь, что вы понимаете риски, связанные с переходом на более слабые настройки защиты, особенно если система доступна через интернет.
-
Исключение sshd из глобальных политик криптографии
Если изменение всех криптографических политик системы неприемлемо, можно настроить исключение для sshd. Для этого:
-
Откройте файл
/etc/sysconfig/sshd
и измените (или добавьте) срочку:CRYPTO_POLICY=
Это отключит применение системных криптографических политик исключительно для sshd, вернув его к использованию настроек, заданных в
/etc/ssh/sshd_config
. -
Перезапустите демон ssh с помощью команд:
sudo systemctl daemon-reload sudo systemctl restart sshd
Тогда вы сможете в файле
/etc/ssh/sshd_config
настроить поддержку устаревших алгоритмов, например:HostKeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa
-
Эти действия должны временно решить вашу проблему совместимости, пока вы не обновите более старую систему до более современной версии, где такие проблемы будут менее вероятны.
Резюме
Таким образом, решение вашей проблемы связано с настройками криптографических политик на вашем сервере с Rocky Linux 9.5. Обратите внимание, что данные изменения могут повлиять на уровень безопасности вашей системы. Убедитесь, что после временного решения проблемы вы обновите старую систему или используете иные методы, которые обеспечат более надежную защиту ваших данных и инфраструктуры.