View Issue Details

IDProjectCategoryView StatusLast Update
0005915Kali Linux[All Projects] Kali Package Improvementpublic2021-01-21 07:38
Reportertjnull Assigned Torhertzog  
Status closedResolutionwon't fix 
Product Version2019.4 
Target VersionFixed in Version 
Summary0005915: Powershell PSSession needs subpackages and configurations to properly work.
DescriptionI 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 ReproduceIn order to resolve this issue I noticed that Kali was missing three subpackages that were required to obtain a PSSession.


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/

ln -s /usr/lib/x86_64-linux-gnu/

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.


Enter-PSSession -computername (IP ADDRESS) -Authentication Negotiate -credential haxor



2019-12-14 07:16


image.png (84,685 bytes)
image.png (84,685 bytes)
image-2.png (113,171 bytes)
image-2.png (113,171 bytes)


2019-12-17 09:09

administrator   ~0011692

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 it would seem that installing gss-ntlmssp should be enough.


2019-12-17 09:19

administrator   ~0011693

I filed to ask that "gss-ntlmssp" be added as a dependency.


2019-12-17 18:39

reporter   ~0011708

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.


2019-12-22 21:23

reporter   ~0011751

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/
ln -s /usr/lib/x86_64-linux-gnu/


2019-12-26 12:43

administrator   ~0011765

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?


2019-12-27 23:44

reporter   ~0011776

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-3.png (208,323 bytes)
image-4.png (143,514 bytes)
image-4.png (143,514 bytes)


2021-01-21 07:38

administrator   ~0014129

So Microsoft doesn't want to fix this (cf filed 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.

Issue History

Date Modified Username Field Change
2019-12-14 07:16 tjnull New Issue
2019-12-14 07:16 tjnull File Added: image.png
2019-12-14 07:16 tjnull File Added: image-2.png
2019-12-17 09:09 rhertzog Note Added: 0011692
2019-12-17 09:19 rhertzog Note Added: 0011693
2019-12-17 09:20 rhertzog Assigned To => rhertzog
2019-12-17 09:20 rhertzog Status new => assigned
2019-12-17 18:39 tjnull Note Added: 0011708
2019-12-22 21:23 tjnull Note Added: 0011751
2019-12-26 12:43 rhertzog Note Added: 0011765
2019-12-27 23:44 tjnull File Added: image-3.png
2019-12-27 23:44 tjnull File Added: image-4.png
2019-12-27 23:44 tjnull Note Added: 0011776
2020-12-01 10:48 g0tmi1k Priority urgent => normal
2020-12-01 10:50 g0tmi1k Severity major => minor
2021-01-21 07:38 rhertzog Status assigned => closed
2021-01-21 07:38 rhertzog Resolution open => won't fix
2021-01-21 07:38 rhertzog Note Added: 0014129