Вопрос или проблема
Очевидно, что Fedora 35 не перечисляет ssh-rsa в HostKeyAlgorithms или PubkeyAcceptedKeyTypes, поэтому попытка подключиться по ssh с устаревшей машины CentOS 6 выдала ошибку:
$ ssh as1s16.intra.corp.us
no hostkey alg
Поэтому я добавил опции после Include в /etc/ssh/sshd_config:
Include /etc/ssh/sshd_config.d/*.conf
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedKeyTypes +ssh-rsa
но ошибка осталась. Затем я запустил sshd следующим образом:
# /usr/sbin/sshd -ddd
...
debug3: /etc/ssh/sshd_config:20 setting HostKeyAlgorithms +ssh-rsa
debug3: /etc/ssh/sshd_config:21 setting PubkeyAcceptedKeyTypes +ssh-rsa
...
debug1: SELinux support disabled [preauth]
...
debug3: append_hostkey_type: ssh-rsa key not permitted by HostkeyAlgorithms [preauth]
debug1: list_hostkey_types: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
но ошибка все равно осталась. Затем я удалил опции и запустил sshd следующим образом:
# /usr/sbin/sshd -ddd -oHostKeyAlgorithms=ssh-rsa
и это сработало. Я смог успешно подключиться по ssh с клиента CentOS 6.
Затем я поставил опции ПЕРЕД Include:
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedKeyTypes +ssh-rsa
# Чтобы изменить конфигурацию sshd на уровне всей системы, создайте файл *.conf в
# /etc/ssh/sshd_config.d/, который будет автоматически включен ниже
Include /etc/ssh/sshd_config.d/*.conf
и это сработало.
Почему мне нужно поставить эти директивы ПЕРЕД Include? Не должны ли они идти после, чтобы переопределить значения по умолчанию?
Хотя это формулировка не очень ясная, я подозреваю, что каталог config.d/*
предназначен для отдельных конфигурационных файлов для конкретных клиентов/пользователей или входящих интерфейсов/портов, в отличие от “общесистемных”. Это похоже на использование каталогов sites/*
в apache/httpd и nginx (а возможно, и в других), чтобы каждый виртуальный хост или приложение могло быть сконфигурировано отдельно, но при этом всё поддерживалось одним сервером. Просмотрите эти файлы, чтобы увидеть, содержат ли они строки Match (за которыми должны следовать другие реальные строки — не Match, не комментарии и не пустые), что означает, что они применяются только к определённым подключениям, а не ко всем.
Include является текстовым. Если у вас есть файл
blich
Include file*
blech
где blich и blech не содержат строк Match, но по крайней мере некоторые из включаемых файлов имеют, тогда blech фактически становится частью последнего блока Match из слияния файлов — поэтому настройки в blech используются только для входящих подключений, удовлетворяющих этим условиям Match, которые ваше тестовое подключение, видимо, не удовлетворяло.
Если вы хотите, чтобы настройки SSHD были “глобальными”, вы должны поставить их перед любой строкой Match, и если в включаемых файлах есть строки Match, это означает, что вы должны поставить глобальные настройки перед Include.
Все (используемые) настройки в конфигурационном файле переопределяют значения по умолчанию в программе. Если поставить одну и ту же настройку более одного раза в конфигурационном файле (перед/вне любых блоков Match), будет использоваться первая, а не последняя, так что ваша идея о переопределении более раннего “значения по умолчанию” (которое вовсе не является значением по умолчанию, если оно есть в файле) не сработает. Только когда более позднее вхождение находится в блоке Match, условия которого выполняются, оно переопределяет первое.
P.S.: вероятно, это произошло потому, что Fedora является передовой и OpenSSH недавно изменила это окончательно после того, как предупреждала (угрожала?) об этом с версии 8.2 полтора года назад.
Я использовал:
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
в /etc/ssh/sshd_config и перезапустил sshd.
.
Ответ или решение
Вопрос о настройке SSHD на Fedora 35 относительно ошибки "no hostkey alg" стал актуальным из-за изменений в OpenSSH. Ваша проблема связана с тем, что Fedora 35, по умолчанию, не поддерживает алгоритмы ssh-rsa в HostKeyAlgorithms или PubkeyAcceptedKeyTypes, что приводит к несовместимости при попытке подключиться с устаревшей машины на CentOS 6.
Контекст и Решение
Недавно произошедшие изменения в OpenSSH (начиная с версии 8.8) убрали поддержку устаревших алгоритмов, таких как ssh-rsa, что и стало причиной вашей проблемы. Это изменение было предварительно объявлено в версиях OpenSSH с 8.2 и наконец реализовано, что повлияло на новые дистрибутивы, такие как Fedora 35, которые часто интегрируют последние обновления и изменения.
Ваши действия по решению проблемы:
-
Вы добавили алгоритмы ssh-rsa в конфигурацию SSHD. Однако важно понимать, что порядок указанных в конфигурации директив имеет существенное значение.
-
Размещение
HostKeyAlgorithms
иPubkeyAcceptedKeyTypes
до директивыInclude
оказалось ключевым шагом. Дело в том, что директиваInclude
внедряет в конфигурацию дополнительные файлы, которые могут содержать специализированные настройки, применяемые только к отдельным видам соединений — это может блокировать ваши изменения, если они расположены послеInclude
. -
Использование
sshd -ddd
для диагностики проблемы позволило выяснить, какие именно алгоритмы поддерживаются по умолчанию и выявить недостаток конфигурации.
Объяснение механики конфигурации
Ваша догадка верна: директива Include
текстуальная и добавляет содержимое других файлов в основной конфигурационный файл в момент его включения. Таким образом, если другие файлы содержат директивы Match
, ваши изменения станут частью последнего блока Match
, что ограничит применение только к конкретным соединениям. Поэтому, если вы хотите применить изменения глобально, их нужно размещать до всех вклучаемых файлов.
Важно отметить, что OpenSSH применяет первую встречную директиву вне блоков Match
, поэтому попытка перезаписать ранее объявленное значение после Include
не даст желаемого результата, если в Include
есть директория с Match
.
SEO-оптимизация и Заключение
Помните, что правильная настройка SSH не только защищает вашу инфраструктуру, но и поддерживает совместимость с более старыми системами. Впоследствии можете рассмотреть обновление CentOS до более новой версии для использования современных алгоритмов шифрования. Поддержка современных алгоритмов шифрования не только увеличивает безопасность, но и обеспечивает лучшую совместимость с новыми системами.
Возможно, вам будет полезно рассмотреть автоматизацию процесса обновления через скрипты или Ansible для более эффективного управления конфигурациями на множестве машин.
Таким образом, для поддержания безопасности и оптимальной работы системы важно следить за обновлениями, особенно в критически важных службах, таких как OpenSSH, и своевременно вносить изменения в конфигурацию.