Start service sshd ошибка

I tried piecing together how to set permissions on a service for «authenticated users».
Below is what I came up with combining information from several websites, mainly this one: https://michlstechblog.info/blog/windows-set-permissions-on-a-service/

Apparently I didn’t get it right b/c its still not working.

Can you provide the command foo for setting permissions?

PS C:Program Files (x86)Windows Resource KitsTools> .subinacl.exe /service sshd /grant=S-1-5-11=QSTOP
sshd : new ace for authenticated users
sshd : 1 change(s)


Elapsed Time: 00 00:00:00
Done:        1, Modified        1, Failed        0, Syntax errors        0
Last Done  : sshd
PS C:Program Files (x86)Windows Resource KitsTools> Start-Service sshd
Start-Service : Service 'sshd (sshd)' cannot be started due to the following error: Cannot start service sshd on
computer '.'.
At line:1 char:1
+ Start-Service sshd
+ ~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OpenError: (System.ServiceProcess.ServiceController:ServiceController) [Start-Service],
   ServiceCommandException
    + FullyQualifiedErrorId : CouldNotStartService,Microsoft.PowerShell.Commands.StartServiceCommand

Goal: I’m trying to set up the Windows built-in OpenSSH server (version 0.0.1.0, as I recall that being the latest one) in order to use my desktop PC remotely should I have the need for raw performance when on the road
through a Windows 10 laptop.

Problem: Despite following the official guide (https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse) to the letter, when I try to run «Start-Service sshd» in PowerShell
I get this error:

    Start-Service : Service ‘OpenSSH SSH Server (sshd)’ cannot be started due to the following error: Palvelun sshd avaamin

    en tietokoneessa . epäonnistui.

    At line:1 char:1

    + Start-Service sshd

    + ~~~~~~~~~~~~~~~~~~

        + CategoryInfo          : OpenError: (System.ServiceProcess.ServiceController:ServiceController) [Start-Service],

       ServiceCommandException

        + FullyQualifiedErrorId : CouldNotStartService,Microsoft.PowerShell.Commands.StartServiceCommand

If I run the executable without «Start-Service», however, it runs and seemingly waits for connections, but according to the Services tab in Task Manager it’s not actually doing anything at all, nor is there an SSH user account associated
with it.

• Restarting Windows (after every installation)
• Uninstalling and re-installing both the server and the client (both from PowerShell and through the Settings application)
• Switched to local account instead of a Microsoft account (suggested on a forum thread, tried the previous steps again)
• Using an elevated PowerShell instance with admin rights

System information:

• Windows 10 Home, version 1809, build 17763.379
• Hardware configuration:
  • CPU: i9-9900k @ 4.9GHz
  • RAM: 32GB 3200MHz DDR4
  • GPU: Asus ROG Strix GTX 1080
  • Motherboard: Asus PRIME Z390-A, BIOS version 0805

Let me know if other information is required.

Страницы: [1]   Вниз

0 Пользователей и 1 Гость просматривают эту тему.

Страницы: [1]   Вверх

So interesting error today; when attempting to start the SSHD (SSH) service, the system failed to start the service with the error (for this I am presuming everything is being run as the root user):

service sshd start
Starting SSH daemon/usr/sbin/sshd: symbol lookup error: /usr/sbin/sshd: undefined symbol: FIPS_mode
startproc: exit status of parent of /usr/sbin/sshd: 127

From the above; the system failed to start.  At this point the system service wasn’t able to find the /usr/sbin/sshd or rather the underlying dependency files for the grid.

FIPS_mode is used to determine the FIPS mode of the operation by a program utilizing the services of the validated library.  The must have been build with the FIPS Object Model and since the SSH service failed to start with this; it was tied to the OpenSSL library on the system.  Specifically the cryptographic services for the grid.
https://wiki.openssl.org/index.php/FIPS_mode()

To check this we can use the ldd command to review the file dependencies and shared libraries with the system
https://www.lifewire.com/find-shared-libraries-ldd-command-4017941

ldd `which sshd` 
ldd `which sshd` | grep crypto

From there; we had the output of the ldd `which sshd` command.

ldd `which sshd`
linux-vdso.so.1 => (0x00007fff50ff0000)
libwrap.so.0 => /lib64/libwrap.so.0 (0x00007fa0aea4a000)
libaudit.so.0 => /lib64/libaudit.so.0 (0x00007fa0ae830000)
libpam.so.0 => /lib64/libpam.so.0 (0x00007fa0ae622000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fa0ae41e000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fa0ae200000)
libcrypto.so.0.9.8 => /lib64/libcrypto.so.0.9.8 (0x00007fa0ade60000)
libldap-2.4.so.2 => /usr/lib64/libldap-2.4.so.2 (0x00007fa0adc17000)
liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007fa0ada08000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007fa0ad804000)
libz.so.1 => /lib64/libz.so.1 (0x00007fa0ad5ee000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fa0ad3d6000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fa0ad19a000)
libopensc.so.2 => /usr/lib64/libopensc.so.2 (0x00007fa0acef6000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fa0accdf000)
libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00007fa0acab1000)
libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00007fa0ac80f000)
libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00007fa0ac5e9000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fa0ac3e4000)
libc.so.6 => /lib64/libc.so.6 (0x00007fa0ac086000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa0aeedc000)
libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00007fa0abe6b000)
libssl.so.0.9.8 => /usr/lib64/libssl.so.0.9.8 (0x00007fa0abc16000)
libopenct.so.1 => /usr/lib64/libopenct.so.1 (0x00007fa0aba0c000)
libltdl.so.7 => /usr/lib64/libltdl.so.7 (0x00007fa0ab802000)
libscconf.so.2 => /usr/lib64/libscconf.so.2 (0x00007fa0ab5fb000)
libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00007fa0ab3f2000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fa0ab1ef000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa0aafd1000).

And below is the output of the ldd `which sshd` | grep crypto command

ldd `which sshd` | grep crypto
libcrypto.so.0.9.8 => /usr/lib64/libcrypto.so.0.9.8 (0x00007fa20dd22000)
libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00007fa20c4ab000)

From the above; we then took the output of the commands from the grep crypto to then compare the path locations to the earlier sshd service (the dependency file path locations).

For this I used the ls -l on the path files to then compare the path directories from earlier

ls -l /usr/lib64/libcrypto.so.0.9.8
-r-xr-xr-x 1 root root 1742842 Jun 19 2014 /usr/lib64/libcrypto.so.0.9.8

ls -l /lib64/libcrypto.so.0.9.8
ls: cannot access /lib64/libcrypto.so.0.9.8: No such file or directory

From the earlier output we can then determine the libcrypto.so.0.9.8 was missing from the /lib64 and then ran a copy from the alternate location from where the file existed

cp /usr/lib64/libcrypto.so.0.9.8 /lib64/

Once done; we then ran the command to start the service for sshd

service sshd start
Starting SSH daemon done

service sshd status
Checking for service sshd running

From there the installation worked and the service started normally.

Additionally why did this occur?

During the installation of a RPM or rather a upgrade in which the OpenSSL service was being updated; the dependency files were updated; however the installation path as seen from earlier isn’t either matched with the path directory for the linked files for the services.

Special NOTE: while the below worked for me; your results will vary, it depends on what the underlying issue is.

For Linux or at least in my case; the system uses a dynamic link for run-time bindings and there was a mismatch causing said service to fail to find the proper service to run the installation:

To check; we could then read /etc/ld.so.conf to then review the Dynamic Linker Run-Time Bindings
https://www.systutorials.com/docs/linux/man/8-ldconfig/

From the earlier output the main thing or rather question was for the libcrypto file missing from the /lib directory further the below output was from an alternate working test grid:

TEST SERVER : ls -l /usr/lib64 | grep rypt
-r-xr-xr-x 1 root root 1689336 Feb 16 2017 libcrypto.so.0.9.8
lrwxrwxrwx 1 root root 18 Nov 20 12:36 libk5crypto.so.3 -> libk5crypto.so.3.1
-rwxr-xr-x 1 root root 154776 Oct 31 2016 libk5crypto.so.3.1

TEST SERVER : ls -l /lib64 | grep rypt
-rwxr-xr-x 1 root root 57699 Feb 17 2016 libcrypt-2.11.1.so
lrwxrwxrwx 1 root root 18 Nov 20 12:35 libcrypt.so.1 -> libcrypt-2.11.1.so
lrwxrwxrwx 1 root root 22 Jun 6 2017 libcryptsetup.so.0 -> libcryptsetup.so.0.0.0
-rwxr-xr-x 1 root root 56440 May 8 2010 libcryptsetup.so.0.0.0
lrwxrwxrwx 1 root root 19 Nov 20 12:36 libgcrypt.so.11 -> libgcrypt.so.11.4.4
-rwxr-xr-x 1 root root 422848 May 6 2014 libgcrypt.so.11.4.4
lrwxrwxrwx 1 root root 18 Nov 20 12:36 libxcrypt.so.2 -> libxcrypt.so.2.0.0
-rwxr-xr-x 1 root root 22896 Aug 24 2011 libxcrypt.so.2.0.0
drwxr-xr-x 2 root root 4096 Nov 20 12:36 xcrypt

From the above; the expected behavior is that the libcrypto dependency files are not in the /lib64 directory path which is expected for the installation.  From there, the installation of a previous RPM must have been attempting to look for the libcrypto.so.0.9.8 but then failed as it wasn’t able to find the package either by dynamic link or in /lib as this wasn’t referenced for the OpenSSL build.

To check I then ran the which openssl to verify the path installation for the package:

TEST SERVER : which sshd
/usr/sbin/sshd

From there; once again: ldd /usr/sbin/sshd (the direct path for the service).

TEST SERVER : ldd /usr/sbin/sshd
 linux-vdso.so.1 => (0x00007fff4b5e6000)
 libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f0f3d633000)
 libaudit.so.0 => /lib64/libaudit.so.0 (0x00007f0f3d419000)
 libpam.so.0 => /lib64/libpam.so.0 (0x00007f0f3d20b000)
 libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f0f3cfed000)
 libcrypto.so.0.9.8 => /lib64/libcrypto.so.0.9.8 (0x00007f0f3cc4d000)
 libutil.so.1 => /lib64/libutil.so.1 (0x00007f0f3ca49000)
 libz.so.1 => /lib64/libz.so.1 (0x00007f0f3c833000)
 libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f0f3c5f8000)
 libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00007f0f3c3cb000)
 libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00007f0f3c129000)
 libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f0f3bf25000)
 libc.so.6 => /lib64/libc.so.6 (0x00007f0f3bbbf000)
 libdl.so.2 => /lib64/libdl.so.2 (0x00007f0f3b9bb000)
 /lib64/ld-linux-x86-64.so.2 (0x00007f0f3dae2000)
 libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00007f0f3b795000)
 libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00007f0f3b58b000)
 libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f0f3b388000)
 libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f0f3b171000)
 libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f0f3af53000)

Now once again verifying the path installation of the package/service for the grid in use.

Further; with the ldconfig -v 2>/dev/null | grep -v ^$’t’ the output was below for file path dependencies

TEST SERVER : ldconfig -v 2>/dev/null | grep -v ^$'t'
/usr/X11R6/lib64:
/usr/X11R6/lib:
/usr/x86_64-suse-linux/lib:
/usr/local/lib:
/lib64:
/lib:
/usr/lib:
/usr/local/lib64:

From the above; we had the topic on this in which the /usr/lib64/libcrypto.so.0.9.8 file wasn’t found when attempting to start the SSHD service.

Why?  Because the service wasn’t found by dynamic links to the active run-time bindings.  As a result; the system literally couldn’t find the path where the service was installed.  In our case; we had previously identified the file was located in the /usr/lib64 path directory so we moved it to the directory the SSHD service was looking for it.

However, the real reason the system wasn’t able to start the service, was the run-time bindings for the service were missing and thus, not found with the ldconfig output.

To correct this; the next step would be to check the /etc/ld.so.conf configuration file.

cat /etc/ld.so.conf

TEST SERVER : cat /etc/ld.so.conf
/usr/X11R6/lib64/Xaw3d
/usr/X11R6/lib64
/usr/lib64/Xaw3d
/usr/X11R6/lib/Xaw3d
/usr/X11R6/lib
/usr/lib/Xaw3d
/usr/x86_64-suse-linux/lib
/usr/local/lib
/opt/kde3/lib
/lib64
/lib
/usr/lib
/usr/local/lib64
/opt/kde3/lib64
include /etc/ld.so.conf.d/*.conf

From there; once again we confirmed the path directory wasn’t to be found for the /usr/lib64 directory.

Special side note: if you don’t know the path of the directory; but from our earlier example the file is: libcrypto.so.0.9.8 so you can use the find command to find the path for the missing files (to find the installation path that’s missing:

Example:

TEST SERVER : find / -name libcrypto.so.0.9.8
/usr/lib64/libcrypto.so.0.9.8

With the /usr/lib64; you can then append this to the /etc/ld.so.conf configuration file.  Once saved; verify the file has been updated:

TEST SERVER : cat /etc/ld.so.conf
/usr/X11R6/lib64/Xaw3d
/usr/X11R6/lib64
/usr/lib64/Xaw3d
/usr/X11R6/lib/Xaw3d
/usr/X11R6/lib
/usr/lib/Xaw3d
/usr/x86_64-suse-linux/lib
/usr/local/lib
/opt/kde3/lib
/lib64
/lib
/usr/lib64
/usr/lib
/usr/local/lib64
/opt/kde3/lib64

And then re-run the ldconfig command to reload the links and cache for the run-time linker.

Once done; without a libcrypto.so.0.9.8 file in the /lib directory the service then started normally after finding the correct path location.

chmod 755 /var/lib/empty/sshd
chmod 755 /var/lib/empty
systemctl restart ssh

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com