3

I have a Windows Server 2019 that's been using sFTP for years. This morning, a client called and said they couldn't transfer files. I tried logging on and I couldn't connect. sshd.config not changed since last June. I disabled the firewall and tried again, still no connection. Tried logging on locally and no good. Took a look at the OpenSSH SSH Server was not running. I tried to start it but got the error 1067 The process terminated unexpectedly. Was running as LocalService so I thought I'd log on with Admin privileges. Got error 1297: a privilege required to function properly does not exist in the service account configuration.

So, I open an elevated PowerShell window and start the service:

Start-Service sshd
Start-Service : Failed to start service 'OpenSSH SSH Server (sshd)'.
At line:1 char:1
+ Start-Service sshd
+ ~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OpenError: (System.ServiceProcess.ServiceController:ServiceController) [Start-Service],
   ServiceCommandException
    + FullyQualifiedErrorId : StartServiceFailed,Microsoft.PowerShell.Commands.StartServiceCommand

So, I open an elevated command window and run ssh in debug mode, get:

sshd.exe -d
debug1: sshd version OpenSSH_for_Windows_9.5, LibreSSL 3.8.2
debug1: private host key #0: ssh-rsa SHA256:ixF6JOfSlckeBsfwuDiQ
debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:t1rxR6lpymsxXr
debug1: private host key #2: ssh-ed25519 SHA256:NiPzl9YqLX+JPEekVL
debug1: rexec_argv[0]='C:\\Windows\\System32\\OpenSSH\\sshd.exe'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.

At this point it waits. So I try to connect with Filezilla and get:

debug1: Server will not fork when running in debugging mode.
Connection from 10.0.0.9 port 50769 on 10.0.0.9 port 22
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_9.5
debug1: Remote protocol version 2.0, remote software version FileZilla_3.64.0
debug1: compat_banner: no match: FileZilla_3.64.0
debug1: list_hostkey_types: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: algorithm: curve25519-sha256 [preauth]
debug1: kex: host key algorithm: ssh-ed25519 [preauth]
debug1: kex: client->server cipher: aes256-gcm@openssh.com MAC: <implicit> compression: none [preauth]
debug1: kex: server->client cipher: aes256-gcm@openssh.com MAC: <implicit> compression: none [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: SSH2_MSG_KEX_ECDH_INIT received [preauth]
debug1: rekey out after 4294967296 blocks [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: Sending SSH2_MSG_EXT_INFO [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: rekey in after 4294967296 blocks [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user LDNClient service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: get_user_token - unable to generate user token for ldnclient as i am not running as system
ga_init, unable to resolve user ldnclient
debug1: do_cleanup
debug1: Killing privsep child 4624

I go and check Event Viewer... nothing in OpenSSH/Admin or OpenSSH/Operational. I check Operational and logging is enabled. I look in C:\ProgramData\ssh\sshd.config and have:

LogLevel VERBOSE
SyslogFacility LOCAL0

I look in C:\ProgramData\ssh\logs but not a single file. So, I've about exhausted everything I can think of to check. I look at the lines:

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

and are pretty sure that's the problem somehow. However, that user/logon/password have been the same for years as well. Rebooted a couple of times for fun but it didn't change anything.

Is there anything else I can try to get this working again?

Velocedge
  • 131

2 Answers2

1

It may be a permission issue.

You could check this solution which suggests to remove the C:\ProgramData\ssh\logs folder which may have been created with bad permissions.

Starting the service again will create it with correct authorizations.

I had the exact same issue trying to activate logging.

This page also indicates how to solve other permissions issues using the following commands:

PS C:\>(get-acl .\ssh_host_dsa_key).owner
otheruser
PS C:\>icacls .\ssh_host_dsa_key
ssh_host_dsa_key   NT AUTHORITY\SYSTEM:(F)
                   BUILTIN\Administrators:(F)
                   otheruser:(R) 
Steps to fix these permissions
PS C:\>icacls .\ssh_host_dsa_key /setowner system
PS C:\>icacls .\ssh_host_dsa_key /remove otheruser
At this point, you could do the following to replicate these permissions onto other host keys
PS C:\>get-acl .\ssh_host_dsa_key | Set-Acl ssh_host*key

See also this issue on GitHub

lauhub
  • 119
0

I had a familiar issue on Windows 2019 and made it even worse after what I had to repair even more.

Same situation as yours Error 1067. -> Tried to solve by reinstalling with powershell: Remove-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0 Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0 -> After that Open SSH Service could not be started due to Error 1058. -> Tried to delete C:\ProgramData\ssh as stated in solution of Error 1067 (OpenSSH SSH Server won't start on Windows Server 2019 after Windows Updates). -> Now Error Code changed to Error 1053. -> Tried re-installing several times, Healthchecks with DISM and so on. Plenty Reboots and Registry-Key changes/deletes. Nothing helped. -> MS Copilot gave me hint to check DLLs due to Error 1053. -> Checked libcrypto.dll and found modify-date Nov2024 while installed exe-files Sep2018, exe-files of the SSH-Client-Component (ssh_agent.exe under C:\Windows\System32\OpenSSH) all new from Nov2024, too. See screenshot. enter image description here -> Started to search for all sshd.exe files under C:\Windows. Found several different under "C:\Windows\WinSxS", one from Nov2024 among them. -> Took ownership of the old exe-files under C:\Windows\System32\OpenSSH and changed permission to be able to rename them, renamed. -> Copied over all the new Nov2024-exe-files from "C:\Windows\WinSxS" as visible on screenshot. -> Now Service could start eventually, creating new ssl folder under "C:\ProgramData".

Powershell takes whatever repository version it finds first during installing the SSH component as it seems.

Hope nobody have to go through this like me, but if so, here's a map.

Maybe anything of that can help you with your issue.

Entrepreneur_Dimy
  • 1