| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005915 | Kali Linux | Kali Package Improvement | public | 2019-12-14 07:16 | 2021-01-21 07:38 |
| Reporter | tjnull | Assigned To | rhertzog | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | won't fix | ||
| Product Version | 2019.4 | ||||
| Summary | 0005915: Powershell PSSession needs subpackages and configurations to properly work. | ||||
| Description | I was doing some testing with Powershell on Kali Linux and I was trying to obtain a PSSession to a Windows. During my testing I was unable to get a session because Powershell stated I needed wsman and the client Library could not be found. Turns out the kali system was missing some subpackages and symlinks to get PSSession to work properly to obtain a session from a Windows Client. | ||||
| Steps To Reproduce | In order to resolve this issue I noticed that Kali was missing three subpackages that were required to obtain a PSSession. krb5-multidev Once the packages were installed I navigated to the powershell directory and added the following symlinks in the powershell 6 directory: cd /opt/microsoft/powershell/6 ln -s /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 ln -s /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2 Once the symlinks were added I re-ran the test to obtain a PSession to my Windows target and was successfully able to get a session. pwsh Enter-PSSession -computername (IP ADDRESS) -Authentication Negotiate -credential haxor | ||||
 |
This should really be reported to Microsoft since we are importing their packages directly. But I also don't understand how your suggested actions are helping: powershell depends on libgssapi-krb5-2 already. I don't see why krb5-multidev or libkrb5-dev package would help. I can understand that gss-ntlmssp might help though, since it's a plugin for the above library. I also don't understand the symlinks, the libraries are available in a public directory and any binary should be able to load them from their public place. Are all of the steps that you suggested really required or can you figure out a subset that is sufficient (based on my feedback) ? Looking at https://github.com/PowerShell/PowerShell/issues/6647 it would seem that installing gss-ntlmssp should be enough. |
|
|
I filed https://github.com/PowerShell/PowerShell/issues/11374 to ask that "gss-ntlmssp" be added as a dependency. |
 |
Just purged the dev libraries (krb5-multidev, libkrb5-dev) and I was able to get a working PSSession from a Windows Client. As for the symlinks for some reason I have to link them into the powershell directory to obtain a PSSession. Otherwise Powershell would be unable to run those libraries to use WSman to intiate the PSSSession. The only step that really is required is placing those symlinks in the powershell directory unless Microsoft can double check to make sure it calls out to those libraries. |
|
|
Also noticed that I made a mistake on the symlinks. These are correct working symlinks to obtain a PSSession from Kali to Windows: ln -s /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 libssl.so.1.0.0 |
|
|
Can show us what error you get when you don't have those symlinks? Can you script this try and then strace the call to powershell running this script and have some proof that it tries (and fails) to find those libraries? Do you have the same issue with powershell-preview? What about the Debian 10 version of powershell-preview? |
|
|
Here is the error I get without those symlinks in place under PowerShell 6 and the Preview version for 7 When I run it in PowerShell preview I get the same error as well. I also downloaded the latest build you linked me and got the same issue as well. I have attached images for both errors on for both versions of PowerShell. If I add those symlinks back into the PowerShell Directory it works fine. image-3.png (208,323 bytes) image-4.png (143,514 bytes) |
|
|
So Microsoft doesn't want to fix this (cf filed https://github.com/PowerShell/PowerShell/issues/11374) so there's not much we can do about it unless we repackage powershell ourselves. I find Microsoft's decision pretty bad, given that they have a double standard between the package and the docker image... but closing anyway. |
