Сервер sFTP OpenSSH на Windows перестал работать в выходные… после установки обновлений Windows.

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

У меня есть сервер Windows Server 2019, который использует sFTP уже много лет. Сегодня утром клиент позвонил и сказал, что не может передать файлы. Я попытался войти и не смог подключиться. Файл sshd.config не менялся с прошлого июня. Я отключил брандмауэр и попробовал снова, все равно без подключения. Попробовал войти локально и тоже не удалось. Посмотрел, сервер OpenSSH SSH не запущен. Я попытался его запустить, но получил ошибку 1067: процесс завершился неожиданно. Он работал как LocalService, поэтому я подумал, что войду с правами администратора. Получил ошибку 1297: привилегия, необходимая для правильной работы, отсутствует в конфигурации учетной записи сервиса.

Поэтому я открываю окно PowerShell с повышенными правами и запускаю службу:

Start-Service sshd
Start-Service : Не удалось запустить службу 'OpenSSH SSH Server (sshd)'.
На строке:1 символ:1
+ Start-Service sshd
+ ~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OpenError: (System.ServiceProcess.ServiceController:ServiceController) [Start-Service],
   ServiceCommandException
    + FullyQualifiedErrorId : StartServiceFailed,Microsoft.PowerShell.Commands.StartServiceCommand

Затем я открываю окно командной строки с повышенными правами и запускаю ssh в режиме отладки, получаю:

sshd.exe -d
debug1: версия sshd OpenSSH_for_Windows_9.5, LibreSSL 3.8.2
debug1: закрытый ключ хоста #0: ssh-rsa SHA256:ixF6JOfSlckeBsfwuDiQ
debug1: закрытый ключ хоста #1: ecdsa-sha2-nistp256 SHA256:t1rxR6lpymsxXr
debug1: закрытый ключ хоста #2: ssh-ed25519 SHA256:NiPzl9YqLX+JPEekVL
debug1: rexec_argv[0]='C:\\Windows\\System32\\OpenSSH\\sshd.exe'
debug1: rexec_argv[1]='-d'
debug1: Привязка к порту 22 на ::.
Сервер прослушивает на :: порт 22.
debug1: Привязка к порту 22 на 0.0.0.0.
Сервер прослушивает на 0.0.0.0 порт 22.

На этом этапе он ждет. Я пытаюсь подключиться с помощью Filezilla и получаю:

debug1: Сервер не будет создавать процессы при запуске в режиме отладки.
Подключение от 10.0.0.9 порт 50769 на 10.0.0.9 порт 22
debug1: локальная версия SSH-2.0-OpenSSH_for_Windows_9.5
debug1: удаленная версия протокола 2.0, удаленная версия программного обеспечения FileZilla_3.64.0
debug1: compat_banner: нет совпадения: FileZilla_3.64.0
debug1: list_hostkey_types: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT отправлено [preauth]
debug1: SSH2_MSG_KEXINIT получено [preauth]
debug1: kex: алгоритм: curve25519-sha256 [preauth]
debug1: kex: алгоритм ключа хоста: ssh-ed25519 [preauth]
debug1: kex: шифр клиент->сервер: [email protected] MAC: <implicit> сжатие: none [preauth]
debug1: kex: шифр сервер->клиент: [email protected] MAC: <implicit> сжатие: none [preauth]
debug1: ожидая SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: SSH2_MSG_KEX_ECDH_INIT получено [preauth]
debug1: rekey out после 4294967296 блоков [preauth]
debug1: SSH2_MSG_NEWKEYS отправлено [preauth]
debug1: Отправка SSH2_MSG_EXT_INFO [preauth]
debug1: ожидая SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS получено [preauth]
debug1: rekey in после 4294967296 блоков [preauth]
debug1: KEX завершен [preauth]
debug1: запрос userauth для пользователя LDNClient сервис ssh-connection метод none [preauth]
debug1: попытка 0 неудач 0 [preauth]
debug1: get_user_token - не удалось сгенерировать токен пользователя для ldnclient, так как я не работаю как системный
ga_init, не удалось разрешить пользователя ldnclient
debug1: do_cleanup
debug1: Убиваем дочерний процесс privsep 4624

Я иду и проверяю Просмотр событий… ничего в OpenSSH/Admin или OpenSSH/Operational. Я проверяю Operational, и ведение журнала включено. Я смотрю в C:\ProgramData\ssh\sshd.config и вижу:

LogLevel VERBOSE
SyslogFacility LOCAL0

Я смотрю в C:\ProgramData\ssh\logs, но ни одного файла. Так что я, по сути, исчерпал все, что мог придумать, чтобы проверить. Я смотрю на строки:

get_user_token - не удалось сгенерировать токен пользователя для ldnclient, так как я не работаю как системный
ga_init, не удалось разрешить пользователя ldnclient

и уверен, что это проблема каким-то образом. Однако этот пользователь/логин/пароль были одинаковыми уже много лет. Перезагружал несколько раз для удовольствия, но это не изменило ничего.

Есть ли что-то еще, что я могу попробовать, чтобы снова привести это в рабочее состояние?

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

Как восстановить работу SFTP-сервера OpenSSH на Windows после установки обновлений

Проблема, с которой вы столкнулись, может быть связана с изменениями, внесенными в конфигурацию служб или необходимыми привилегиями после установки обновлений Windows. Приведем рекомендации по диагностике и устранению неполадок SFTP-сервера OpenSSH на Windows Server 2019.

Шаг 1: Проверка состояния службы OpenSSH

Вы упомянули, что служба OpenSSH SSH Server (sshd) не запускается, и вы получили ошибку 1067. Эта ошибка часто указывает на проблемы с конфигурацией или разрешениями. Для начала проверьте состояние службы sshd с помощью следующей команды в PowerShell:

Get-Service sshd

Если служба не запущена, попробуйте запустить её от имени администратора:

Start-Service sshd

Если возникает ошибка 1297, это может означать, что служба настроена с недостаточными правами для выполнения. В таком случае убедитесь, что служба настроена правильно для запуска под учетной записью «Local Service» или рассмотрите возможность её изменения на «Local System».

Шаг 2: Изменение учетной записи службы

  1. Откройте services.msc.
  2. Найдите службу OpenSSH SSH Server.
  3. Щелкните правой кнопкой мыши и выберите «Свойства».
  4. Перейдите на вкладку «Вход в систему» и проверьте настройки учетной записи. Для тестирования можно временно изменить ее на «Local System».

Шаг 3: Проверка конфигурации

Проверьте файл конфигурации sshd_config, расположенный по пути C:\ProgramData\ssh\sshd.config. Убедитесь, что параметры LogLevel и другие настройки указаны верно.

Шаг 4: Просмотр журналов

Вы отметили, что в C:\ProgramData\ssh\logs нет журналов. Убедитесь, что журналы включены, и проверьте права доступа к этой директории. Запустите sshd в «debug» режиме, чтобы получить дополнительную информацию о проблемах. Используйте следующую команду:

sshd.exe -d

Это позволит вам увидеть дополнительные сообщения в процессе аутентификации.

Шаг 5: Устранение неполадок с аутентификацией

Строки:

get_user_token - unable to generate user token for ldnclient as i am not running as system
ga_init, unable to resolve user ldnclient

указывает на проблемы с аутентификацией пользователя. Проверьте, существует ли пользователь ldnclient и есть ли у него необходимые права доступа. Попробуйте временно создать нового пользователя, у которого также должны быть права доступа к службам SSH, чтобы провести тесты.

Шаг 6: Сброс службы OpenSSH

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

  1. Отключите службу OpenSSH:

    Stop-Service sshd
  2. Переименуйте конфигурацию:

    Rename-Item "C:\ProgramData\ssh\sshd_config" "sshd_config_backup"
  3. Запустите службу для автоматического создания нового файла конфигурации, а затем те необходимые параметры, которые могут потребоваться для работы.

Заключение

Ситуация с вашими подключениями SFTP может быть комплексной. Тщательное следование вышеописанным шагам должно помочь вам выявить источник проблемы и восстановить работу OpenSSH на вашем сервере. Если проблема сохраняется, рассмотрите возможность привлечения специалистов по IT-безопасности или поддержки Microsoft для более глубокой проверки конфигураций и обновлений.

Не забудьте делать резервные копии конфигурационных файлов перед внесением изменений для быстрого восстановления в случае необходимости.

Если у вас есть дополнительные вопросы или вам требуется помощь, всегда готовы помочь!

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

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