Посещая наш сайт, вы соглашаетесь с нашей политикой конфиденциальности в отношении файлов cookie, статистики отслеживания и т. д.

Главная » Вопросы и ответы » Системное администрирование и сети

sshd не запускается из xinetd в OpenSSH 9.8p1

На чтение 6 мин Опубликовано
Содержание
  1. Вопрос или проблема
  2. Ответ или решение
  3. Причина проблемы
  4. Решение проблемы
  5. Рекомендации по переходу
  6. Заключение

Вопрос или проблема

Мы запускаем sshd с помощью xinetd на нашем шлюзе. Вот файл конфигурации xinetd:

service ssh
{
    instances       = 10
    socket_type     = stream
    wait            = no
    user            = root
    protocol        = tcp
    server          = /usr/local/sbin/sshd
    server_args     = -i
    disable         = no
}

Вот версия OpenSSH из команды ssh -V на шлюзе:

OpenSSH_9.8p1, OpenSSL 3.0.14 4 Jun 2024

Вот версия, работающая на моей виртуальной машине Fedora 37:

OpenSSH_8.8p1, OpenSSL 3.0.9 30 May 2023

Если я пытаюсь подключиться к шлюзу с виртуальной машины Fedora 37, я получаю ошибку “sshd требует выполнения с абсолютным путем”:

$ ssh -vvv foo@g5-5
OpenSSH_8.8p1, OpenSSL 3.0.9 30 May 2023
debug1: Чтение данных конфигурации /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config строка 58: Включение файла /etc/ssh/ssh_config.d/50-redhat.conf глубина 0
debug1: Чтение данных конфигурации /etc/ssh/ssh_config.d/50-redhat.conf
debug2: проверка совпадения для 'final all' хоста g5-5 первоначально g5-5
debug3: /etc/ssh/ssh_config.d/50-redhat.conf строка 3: не совпадает 'final'
debug2: совпадение не найдено
debug3: /etc/ssh/ssh_config.d/50-redhat.conf строка 5: Включение файла /etc/crypto-policies/back-ends/openssh.config глубина 1 (только парсинг)
debug1: Чтение данных конфигурации /etc/crypto-policies/back-ends/openssh.config
debug3: имена kex GSS ок: [gss-curve25519-sha256-,gss-nistp256-sha256-,gss-group14-sha256-,gss-group16-sha512-]
debug3: имена kex ок: [curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512]
debug1: запросы конфигурации завершили прохождение final Match
debug1: повторный парсинг конфигурации
debug1: Чтение данных конфигурации /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config строка 58: Включение файла /etc/ssh/ssh_config.d/50-redhat.conf глубина 0
debug1: Чтение данных конфигурации /etc/ssh/ssh_config.d/50-redhat.conf
debug2: проверка совпадения для 'final all' хоста g5-5 первоначально g5-5
debug3: /etc/ssh/ssh_config.d/50-redhat.conf строка 3: совпадение 'final'
debug2: совпадение найдено
debug3: /etc/ssh/ssh_config.d/50-redhat.conf строка 5: Включение файла /etc/crypto-policies/back-ends/openssh.config глубина 1
debug1: Чтение данных конфигурации /etc/crypto-policies/back-ends/openssh.config
debug3: имена kex GSS ок: [gss-curve25519-sha256-,gss-nistp256-sha256-,gss-group14-sha256-,gss-group16-sha512-]
debug3: имена kex ок: [curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512]
debug3: расширенный UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/xxxx/.ssh/known_hosts'
debug3: расширенный UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/xxxx/.ssh/known_hosts2'
debug2: разрешение "g5-5" порт 22
debug3: resolve_host: поиск g5-5:22
debug3: ssh_connect_direct: вход
debug1: Подключение к g5-5 [x.x.x.x] порт 22.
debug3: set_sock_tos: установка сокета 3 IP_TOS 0x48
debug1: Соединение установлено.
debug1: файл идентичности /home/xxxx/.ssh/id_rsa тип -1
debug1: файл идентичности /home/xxxx/.ssh/id_rsa-cert тип -1
debug1: файл идентичности /home/xxxx/.ssh/id_dsa тип -1
debug1: файл идентичности /home/xxxx/.ssh/id_dsa-cert тип -1
debug1: файл идентичности /home/xxxx/.ssh/id_ecdsa тип -1
debug1: файл идентичности /home/xxxx/.ssh/id_ecdsa-cert тип -1
debug1: файл идентичности /home/xxxx/.ssh/id_ecdsa_sk тип -1
debug1: файл идентичности /home/xxxx/.ssh/id_ecdsa_sk-cert тип -1
debug1: файл идентичности /home/xxxx/.ssh/id_ed25519 тип -1
debug1: файл идентичности /home/xxxx/.ssh/id_ed25519-cert тип -1
debug1: файл идентичности /home/xxxx/.ssh/id_ed25519_sk тип -1
debug1: файл идентичности /home/xxxx/.ssh/id_ed25519_sk-cert тип -1
debug1: файл идентичности /home/xxxx/.ssh/id_xmss тип -1
debug1: файл идентичности /home/xxxx/.ssh/id_xmss-cert тип -1
debug1: строка локальной версии SSH-2.0-OpenSSH_8.8
debug1: kex_exchange_identification: строка баннера 0: sshd требует выполнения с абсолютным путем
kex_exchange_identification: чтение: Соединение сброшено удаленным хостом
Соединение сброшено x.x.x.x порт 22

Я не получаю этой ошибки, если на шлюзе запущен OpenSSH 9.7p1, и могу успешно войти в систему.

Я посмотрел код в sshd.c на github: https://github.com/openssh/openssh-portable

Возможно, ошибка, которую я получаю, связана с тем, что не проверяется флаг inetd на строке 1344? Код sshd.c в 9.7.p1, похоже, проверяет флаг inetd косвенно.

Или это какая-то новая или дополнительная настройка, касающаяся запуска sshd 9.8p1 из xinetd?

Я столкнулся с той же проблемой на Slackware (https://www.linuxquestions.org/questions/slackware-14/openssh-9-8-regression-when-using-inetd-4175739141/).

Похоже, это регресс в openssh 9.8 (https://bugzilla.mindrot.org/show_bug.cgi?id=3717) и это было исправлено в 9.9 (https://www.openssh.com/txt/release-9.9).

Ответ или решение

Проблема, с которой вы столкнулись, действительно связана с изменениями, внесёнными в OpenSSH версии 9.8. Судя по описанию, сообщение "sshd requires execution with an absolute path" указывает на то, что sshd не может быть запущен должным образом из xinetd, что, в свою очередь, связано с изменениями в обработке флага inetd.

Причина проблемы

В OpenSSH 9.8 была обнаружена регрессия, касающаяся запуска sshd в режиме inetd. Этот режим требует, чтобы путь к исполняемому файлу sshd был абсолютным, и предыдущие версии, такие как 9.7, допускали определённые нюансы в этой проверке. С введением версии 9.8 и изменения в коде, sshd теперь требует более строгого выполнения условий.

Решение проблемы

  1. Обновление OpenSSH: Самое простое решение заключается в обновлении до OpenSSH версии 9.9 или выше, в которой данная проблема была исправлена. Это решение эффективно и устранит ошибку, не требуя дополнительных изменений в конфигурации.

  2. Использование альтернативного способа запуска: В качестве временного обойти систему xinetd можно попробовать запустить sshd как отдельный процесс, добавив соответствующую запись в конфигурацию ваших системных служб (например, в systemd). Это позволит вам избежать проблем с xinetd и обеспечит более стабильную работу ssh-сервера.

  3. Проверка конфигурации xinetd: Убедитесь, что конфигурационный файл xinetd содержит правильный путь к sshd. Например, проверьте следующие моменты:

    server          = /usr/local/sbin/sshd

    убедитесь, что файл существует и доступен для выполнения.

Рекомендации по переходу

После обновления OpenSSH до версии 9.9 или выше, вы сможете тестировать подключение с вашего клиента. Для отладки можете воспользоваться ключом -vvv, чтобы получить более подробный вывод и убедиться, что ошибка больше не проявляется.

Заключение

Рекомендуется следить за обновлениями и сообщениями о новых версиях OpenSSH, так как со временем могут появляться другие изменения. Если вы продолжаете использовать xinetd, также полезно следить за совместимостью версий с вашими требованиями безопасности и функциональности.

Пожалуйста, дайте знать, если у вас будут дополнительные вопросы или понадобятся разъяснения по конкретным шагам!

linux ssh
Оцените материал
Добавить комментарий

Капча загружается...

© 2024 IZ6.RU
*В материалах сайта упоминаются социальные сети Фейсбук / Инстаграм, принадлежащие Meta Platforms Inc., деятельность которой запрещена на территории РФ в части реализации данных социальных сетей на основании осуществления ею экстремистской деятельности