New pssession connecting to remote server failed with the following error message

enter-PSSession -ConfigurationName powershell.6.1.0-preview.1

New-PSSession : MI_RESULT_ACCESS_DENIED
At line:1 char:1
Enter-PSSession -ComputerName <IP> -Credential <username>
  + CategoryInfo          : InvalidOperation: (:) [New-PSSession], PSInvalidOperationException
  + FullyQualifiedErrorId : InvalidOperation,Microsoft.PowerShell.Commands.NewPSSessionCommand

Name                           Value
----                           -----
PSVersion                      6.1.0-preview.1
PSEdition                      Core
GitCommitId                    v6.1.0-preview.1
OS                             Microsoft Windows 10.0.14393
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Name                           Value
----                           -----
PSVersion                      6.1.0-preview.1
PSEdition                      Core
GitCommitId                    v6.1.0-preview.1
OS                             Linux 3.10.0-514.e17.x86_64 #1 SMP Tue Nov 22 16:42:41 UTC 2016
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

@KaloferovLab remoting over WSMan is supported, but much more limited than what you get with Windows and WinRM. From Linux, you should use -Credential as unlike Windows you can’t use the current security context. Also, use -Authentication Basic.

I have tried many times establishing a new session from linux RHEL7 to windows server 2016.
Always get the same error.
I also tried , athentication Kerberos, Basic, Negotiable, etc….

Enter-PSSession : MI_RESULT_ACCESS_DENIED
At line:1 char:1

• Enter-PSSession -ComputerName WSRVPRD001 -Credential (Get-Credential) …
• CategoryInfo : InvalidArgument: (WSRVPRD001:String) [Enter-PSSession], PSInvalidOperationException
• FullyQualifiedErrorId : CreateRemoteRunspaceFailed

Did anyone manage to establish the connection?

New-PSSession -ComputerName remotehost -Credential $credential -Authentication Negotiate

Use Negotiate for authentication. I don’t recommend using basic as that would send your password in plain text over the network and you would also need to manually allow the remote host to accept basic authentication as it is not allowed by default. Specifying Negotiate results in using NTLM authentication which can be verified by checking $PSSenderInfo.UserInfo.Identity.AuthenticationType

I also facing same problem when I am accessing from ubuntu 16.04, with powershell version and details are included

Name Value

PSVersion 6.2.1
PSEdition Core
GitCommitId 6.2.1
OS Linux 4.15.0-1036-gcp #38~16.04.1-Ubuntu SMP Tue Jun 25 15:30:46 UTC 2019
Platform Unix
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

My error output :
PowerShell credential request
Enter your credentials.
Password for user XXXXXXXXXXXX: **********

enter-pssession : MI_RESULT_ACCESS_DENIED
At line:1 char:1

• enter-pssession -credential XXXXXXXXXXXX
• CategoryInfo : InvalidArgument: (:String) [Enter-PSSession], PSInvalidOperationException
• FullyQualifiedErrorId : CreateRemoteRunspaceFailed

I also face this Issue on Centos 7 and Server 2012r2 / 2016

Same issue on Centos 7 and WinServer 2019

Invoke-Command gives the same error.

So it appears this issue has been open for a while. I recently ran into this issue via #10764. Any plans to get this resolved in future releases? This holding up some progress to port some Windows automation over to Linux based environment.

Experiencing this ongoing issue as well.

Linux > Windows 2012 R2

Enter-PSSession -Credential $creds -ConfigurationName microsoft.exchange -ConnectionUri http://x.x.x.x/powershell -Authentication Negotiate -Verbose

Enter-PSSession : Connecting to remote server x.x.x.x failed with the following error message : MI_RESULT_ACCESS_DENIED For more information, see the about_Remote_Troubleshooting Help topic.     

Linux to Exchange 2013

 Enter-PSSession -Credential $creds -ComputerName x.x.x.x -Authentication Negotiate -Verbose

Enter-PSSession : Connecting to remote server x.x.x.x failed with the following error message : MI_RESULT_ACCESS_DENIED For more information, see the about_Remote_Troubleshooting Help topic.                                           

When remoting from Linux, you will likely need to explicitly use Basic auth. Negotiate requires additional libraries and configuration.

When remoting from Linux, you will likely need to explicitly use Basic auth. Negotiate requires additional libraries and configuration.

Are the extra libraries required on the Windows or Linux side. Or both?

Windows already has the necessary libs built into the OS. Here’s an example where the docker image was updated with a lib to support NTLM on Linux: PowerShell/PowerShell-Docker#124. This issue seems to indicate Kerberos can work on Linux.

Windows already has the necessary libs built into the OS. Here’s an example where the docker image was updated with a lib to support NTLM on Linux: PowerShell/PowerShell-Docker#124. This issue seems to indicate Kerberos can work on Linux.

Hmm. Checked to verify that the package is installed in the Docker image and still get the same issue as above.

PS /> apt show gss-ntlmssp
Package: gss-ntlmssp
Version: 0.7.0-4build3
Status: install ok installed

PS /> Enter-PSSession -Credential $cred -ComputerName xxxxx -Authentication Negotiate -Verbose
Enter-PSSession : Connecting to remote server xxxxx failed with the following error message : MI_RESULT_FAILED For more information, see the about_Remote_Troubleshooting Help topic

Hey @arnydo,
All officially supported Docker images have gss-ntlmssp installed on them, except for Alpine and openSUSE. So as long as you are using one of the others, you should be good.

Hey @arnydo,
All officially supported Docker images have gss-ntlmssp installed on them, except for Alpine and openSUSE. So as long as you are using one of the others, you should be good.

I am using the latest Docker image for Powershell with no luck.

@arnydo Did you check whether /etc/services was the issue? See #7342 (comment).

Hey, what does /etc/services have to do with this particular issue? That isn’t sarcastic…

haha, yes, that’s a fair question! There is an issue with the native OMI library PowerShell uses on Linux that only crops up with NTLM authentication when /etc/services is missing, as it is in some Docker images (like the official PowerShell images, IIRC). See microsoft/omi#623.

@danports I built a new image based on the latest Ubuntu 18.04 Powershell Dockerfile but with the addition of the RUN echo 'http 80/tcp www www-http' > /etc/services.

Same result…

Hmm, perhaps you’re experiencing a different problem then. You might want to try enabling OMI logging inside the container — reviewing the OMI logs is what eventually helped me to diagnose my issue.

Doesn’t look like omi is present at all in the Powershell images…is that even used in this case?

What do you mean by not present? You’ll probably need to create the OMI log and configuration directories to enable logging — I don’t think they are there by default.

@SteveL-MSFT, This is all well and good:

When remoting from Linux, you will likely need to explicitly use Basic auth. Negotiate requires additional libraries and configuration.

Except, it’s not supported:

> Enter-PSSession -Credential $creds -ComputerName <HOSTNAME> -Authentication Basic -Verbose
Enter-PSSession : Basic authentication is not supported over HTTP on Unix.
At line:1 char:1
....

You’d think that such a useful feature, with multiple bug reports, would have been implemented and/or documented properly a year and a half later after the issue was first reported…

Which version of the Power shell

Just bumped against this too, using a rhel7.7 azure devops agent that needs to remote into a windows 2016 vm

I am also facing the same issue with the latest version of PowerShell (7.0.1).

Trying to connect to Windows 2012 from CentOS Linux 7.

As suggested by @BitDesert above, it works for me after installing gss-ntlmssp and with -Authentication Negotiate.

But there is a huge latency. Authentication itself takes around 20 seconds. Both the Linux and Windows machines are in the same subnet.

Any suggestion on how to reduce the latency?

Having the same issue here on Arch Linux with Powershell Core 7.0.0. Installing the gss-ntlmssp AUR package and using -Authentication Negotiate did not solve the problem. Still get:

PS /home/jon> Enter-PSSession -Credential $credentials -Authentication Negotiate -ComputerName 192.168.1.203
Enter-PSSession: Connecting to remote server 192.168.1.203 failed with the following error message : acquiring creds with username only failed Unspecified GSS failure.  Minor code may provide more information SPNEGO cannot find mechanisms to negotiate For more information, see the about_Remote_Troubleshooting Help topic.

Hey guys, op of PowerShell/PowerShell-Docker#124 here.

You can literally just use the docker://mcr.microsoft.com/powershell:centos-7 container w/ podman/docker/rkt/whatev to get it to work. Just run the container w/ interactivity and a tty and it kicks you into pwsh. If it doesn’t work, then check that the server you’re trying to connect to is configured properly because tokens aren’t exchanged across both platforms. Not all platforms support gssapi/ntlm, and I don’t think they’re any tests..but because of @RDIL’s work, it’s super straightforward regardless.

Downloading sha256:d06345b12b6 [=============================]   106 MB / 106 MB 
Downloading sha256:524b0c1e57f [=============================] 75.9 MB / 75.9 MB 
PowerShell 7.0.3
Copyright (c) Microsoft Corporation. All rights reserved.

https://aka.ms/powershell
Type 'help' to get help.

PS /> enter-pssession -computername 10.7.17.218 -Credential $u -Authentication negotiate

PowerShell credential request
Enter your credentials.
User: root
Password for user root: ************************************************

[10.7.17.218]: PS C:UsersrootDocuments> exit

This is literally what containers are for, so you don’t have to fight with crazy deps to get a simple task handled.

If you’re trying to get kerberos to work with it (instead of ntlm), I don’t think the containers will work (despite gssapi supporting it) because you’ll need to get your tgt with kinit and then get the gssapi library to see it. You can probably do some clever mounting to get its library to see your tgt w/ the container though.

I’d like to add that Linux Mint 20 has the same issue as Ubuntu 20.04.

I installed the package with snap and manually installed gss-ntlmssp via apt but I still get the error:

New-PSSession: [SERVER] Connecting to remote server SERVER failed with the following error message : acquiring creds with username only failed Unspecified GSS failure.  Minor code may provide more information SPNEGO cannot find mechanisms to negotiate For more information, see the about_Remote_Troubleshooting Help topic.

I found the problem. Just install inetutils-ping and it will solve. Probably it is depending ping to resolve OP or something.

apt-get install inetutils-ping

🖖

I found the problem. Just install inetutils-ping and it will solve. Probably it is depending ping to resolve OP or something.

apt-get install inetutils-ping

On ubuntu I have iputils-ping — but it does not work with either one of them installed.

I get the same error on Ubuntu 20.04 (running in WSL2), even though inetutils-ping and gss-ntlmssp is installed.

Enter-PSSession: This parameter set requires WSMan, and no supported WSMan client library was found. WSMan is either not installed or unavailable for this system.

unfortunately it seems this kind of situations are terribly poorly documented by Microsoft.
I got the following to work:

• Setup FreeIPA for DNS and Kerberos (on Linux)
• register the window host in FreeIPA (add host — type machine name and IP address — save)
• setup the proper ciphers for Kerberos (GPO/regedit, everything but DES)
• Setup windows to authenticate with Kerberos, with something like:

 ksetup /setdomain IPA.YOURDOMAIN.COM
ksetup /addkdc IPA.YOURDOMAIN.COM idm.ipa.yourdomain.com
ksetup /addkpasswd IPA.YOURDOMAIN.COM idm.ipa.yourdomain.com
ksetup /setcomputerpassword SecretMachinePassword
ksetup /mapuser * *

• Login to the FreeIPA host and generate the keytab:
  ipa-getkeytab -s ipa.yourdomain.com -p host/windows-hostname.ipa.yourdomain.com -e arcfour-hmac -k krb5.keytab.windows-hostname -P
• now install a Linux host you will use to connect with Powershell — then register it with the FreeIPA Kerberos server and install powershell and the gssntlmssp package
• on that same host you should be able to connect now:
  start powershell (pwsh / powershell in bash) then :

  $credential = get-credential user@IPA.YOURDOMAIN.COM
Enter-PSSession -ComputerName windows-hostname.ipa.yourdomain.com -Authentication Negotiate -Credential $credential

A few other notes :

• user needs to exist in FreeIPA, password is the password of the user in FreeIPA. The user also needs to exist as a local user on the Windows machine
• while this worked from Linux, from Windows to Windows I only got it to work with Administrator accounts, then the format for the user is windows-hostnameAdministrator
• the Windows machines are showing the Kerberos Realm as a Workgroup, so they are not in a Domain like with an AD server
• winrm service needs to run on host, setup and network has to be private (not public)

winrm quickconfig
Enable-PSRemoting
Set-NetConnectionProfile -NetworkCategory Private

Finally, the output on CentOS 7 to connect looks like :

 pwsh
PowerShell 7.1.3
Copyright (c) Microsoft Corporation.

https://aka.ms/powershell
Type 'help' to get help.

PS /home/user> $credential = get-credential user@IPA.YOURDOMAIN.COM

PowerShell credential request
Enter your credentials.
Password for user user@IPA.YOURDOMAIN.COM: ****************

PS /home/user> Enter-PSSession -ComputerName windows-hostname.ipa.yourdomain.com -Authentication Negotiate -Credential $credential
[windows-hostname.ipa.yourdomain.com]: PS C:Usersuser.WINDOWS-HOSTNAMEDocuments>

All this was put together by pulling information from all over the net.
This does not contain all details but should give you enough info to get it to work.
I have not tried Basic authentication and I think it is not safe.
The better approach is to use SSH to manage Windows, because Microsoft seems to be unwilling to deliver proper cross platform authentication support (NTLM does not work and Kerberos not the same as in a domain setting).

There are tickets for that that have been open for months, I haven’t checked those for a while, but feel free to try and get those done. Nobody wants to need a Windows server to manage other Windows servers ( or manage any windows server at all for that matter, but that’s beyond the scope of the answer ).

I still have this issue, on Ubuntu 20.04
Powershell installed today with snap.
I’m trying to Enter-PSSession -Authenthication Negotiate using my $creds.

~> snap list powershell
Name        Version  Rev  Tracking       Publisher              Notes
powershell  7.0.1    129  latest/stable  microsoft-powershell✓  classic

~> apt info gss-ntlmssp
Package: gss-ntlmssp
Version: 0.7.0-4build3
...
APT-Manual-Installed: yes

The error message is:

Enter-PSSession: Connecting to remote server 172.18.42.64 failed with the following error message : acquiring creds with username only failed Unspecified GSS failure.  Minor code may provide more information SPNEGO cannot find mechanisms to negotiate For more information, see the about_Remote_Troubleshooting Help topic.

you are not posting your whole command line. Make sure to use hostname and not IP and set up credentials as shown in my post above. it seems you only supply a user. Just google that error and look at examples otherwise. Make sure to post full info if you have the same issue, thanks

yum install gssntlmssp
...

PS > $sesopt = New-PSSessionOption -SkipCACheck -SkipCNCheck
PS > Enter-PSSession -ComputerName 192.168.10.85 -Credential $cred -Authentication Negotiate -UseSSL -SessionOption $sesopt
Enter-PSSession: Connecting to remote server 192.168.10.85 failed with the following error message : Authorization failed For more information, see the about_Remote_Troubleshooting Help topic.

The Windows eventlog shows Error code 0xC000035B. That might be a version problem. Powershell on Linux seems to use NTLMv1. Windows Server needs a newer version.

Client: CentOS 7, Powershell 7.1.3
Server: Windows Server 2019

In order to get the remote work, I have installed the following dependencies on ubuntu 20.4 (without Kerberos).
Install pwsh 7.1.3
Install OpenSSL
Install PSWSman : sudo pwsh -Command ‘Install-Module -Name PSWSMan’
Install gss-ntlmssp : sudo apt-get install -y gss-ntlmssp

While I am trying to setup on RHEL with Kerberos, got the error of «acquiring creds with username only failed Unspecified GSS failure. Minor code may provide more information SPNEGO cannot find mechanisms to negotiate» from Invoke-Command, and «Authorization failed Unspecified GSS failure. Minor code may provide more information Server not found in Kerberos database For more information» from New-PSSession and Enter-PSSession command

This might be a Kerberos configure issue or still missing some other dependencies required on RHEL.

you need to have your Linux machine authenticate with Kerberos first. Depending if you use AD or Linux, you need to make sure that it works. As I wrote, it works with both the Windows and Linux host using a Linux Kerberos server.
So login on the machine with Kerberos and type klist, you should see a valid ticket there.
As far as I know, it will not work without that, correct me if I’m wrong.

@VGerris Thank you for your comment, I am able to create/enter PSSession from Linux to windows server run after turn off FIPS on Linux. Tracing down to md5 hash error and find that gss-ntlmssp is not compatible with FIPS.
Now need find a FIPS compatible gss-ntlmssp package.

I am experiencing similar issues with my setup — I simply cannot make Ubuntu 18.04 or 20.04 to connect to Windows Server 2019 using NTLM. Does anyone have any suggestions?

Looks like Ubuntu and Windows Server 2019 cannot negotiate the correct NTLM.
The same command opens a valid PSSession when it is executed on Windows 10 Client (standalone client, not joined to doimain).

Setup:

• Enabled WinRM on Windows Server 2019. Windows Server is joined to an Azure Active Directory Domain Services domain
• Installed Powershell 7.1.3 on Ubunbtu 18.04 following official Microsoft article
• Installed gss-ntlmssp on Ubuntu 18.04 to enable NTML authentication as per Including support for NTLM for the microsoft/docker container PowerShell-Docker#124
• Install PSWSMAN 2.2.0 (I tested it without it — the same issue occur)

Commands executed on Ubuntu server:

$PSSessionParameters = @{
  Authentication    = 'Negotiate'
  Credential        = [pscredential]::new('user@domaintest.onmicrosoft.com', ('Obfuscated' | ConvertTo-SecureString -AsPlainText))
  UseSSL            = $true
  Port              = 5986
  ConfigurationName = 'PowerShell.7'
  SessionOption     = New-PSSessionOption -SkipCACheck -SkipCNCheck
}
New-PSSession -ComputerName '10.0.104.201' @PSSessionParameters

Error received on Ubuntu:

New-PSSession: [10.0.104.201] Connecting to remote server 10.0.104.201 failed with the following error message : Authorization failed For more information, see the about_Remote_Troubleshooting Help topic.

Error in Windows Server Security log:

Event 4625
Account For Which Logon Failed:
	Security ID:		NULL SID
	Account Name:		user@domaintest.onmicrosoft.com
	Account Domain:		

Failure Information:
	Failure Reason:		An Error occured during Logon.
	Status:			0xC000035B
	Sub Status:		0x0

NTLM audit log on Windows Server:

NTLM server blocked audit: Audit Incoming NTLM Traffic that would be blocked
Calling process PID: 3136
Calling process name: C:WindowsSystem32svchost.exe
Calling process LUID: 0x3E4
Calling process user identity: vm-gs-alt001$
Calling process domain identity: DOMAINTEST
Mechanism OID: 1.3.6.1.4.1.311.2.2.10
Audit NTLM authentication requests to this server that would be blocked if the security policy Network Security: Restrict NTLM: Incoming NTLM Traffic is set to Deny all accounts or Deny all domain accounts.
If you want this server to allow NTLM authentication, set the security policy Network Security: Restrict NTLM: Incoming NTLM Traffic to Allow all.

Please take a look into this threat — jborean93/omi#29
Looks like the limitation comes from the libraries which ship with different version of Windows. The workaround is to set the CbtHardeningLevel to None so Windows doesn’t try to validate the value at all.

New-PSSession -ComputerName remotehost -Credential $credential -Authentication Negotiate

Use Negotiate for authentication. I don’t recommend using basic as that would send your password in plain text over the network and you would also need to manually allow the remote host to accept basic authentication as it is not allowed by default. Specifying Negotiate results in using NTLM authentication which can be verified by checking $PSSenderInfo.UserInfo.Identity.AuthenticationType

Thanks!

Obviously something is wrong with the PowerShell for Linux.
A very interesting blog that can shed the light , especially the topic where the PRs were rejected.

For my Ubuntu18.04 connecting to Win10 Pro over winrm (http port, not joined in AD) , the following worked:

sudo apt install  gss-ntlmssp powershell
pwsh -Command 'Install-Module -Name PSWSMan'
sudo pwsh -Command 'Install-WSMan'

Validation:

$cred=Get-Credential 
Enter-PSSession -ComputerName vmhostname.vmdomain -Credential $cred -Authentication Negotiate

File copy :

$pw = convertto-securestring -AsPlainText -Force -String PASS
$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist "USER",$pw
$session = New-PSSession -ComputerName win10pro.localdomain -Credential $cred  -Authentication Negotiate
Copy-Item -Path 'C:UsersUSERDesktopsomefile.txt' -Destination /tmp/ -FromSession $session

Obviously something is wrong with the PowerShell for Linux. A very interesting blog that can shed the light , especially the topic where the PRs were rejected.

For the record, the blog is definitely titled as being related to Linux..but if you look at the PRs microsoft/omi#669, microsoft/omi#670, and the blog, those are all related to building the library on MacOS (which is unsupported).

The troubleshooting of GSSAPI and everything else from the blog is definitely on-topic, though, and is probably useful for people who need help troubleshooting more details of how pwsh on linux interacts with GSSAPI. Still, though, it’s super cool that the author is actively maintaining OMI for all of the platforms (including MacOS)…because honestly, it needs it.

This comment was marked as off-topic.

Obviously something is wrong with the PowerShell for Linux. A very interesting blog that can shed the light , especially the topic where the PRs were rejected.

For my Ubuntu18.04 connecting to Win10 Pro over winrm (http port, not joined in AD) , the following worked:

sudo apt install  gss-ntlmssp powershell
pwsh -Command 'Install-Module -Name PSWSMan'
sudo pwsh -Command 'Install-WSMan'

Validation:

$cred=Get-Credential 
Enter-PSSession -ComputerName vmhostname.vmdomain -Credential $cred -Authentication Negotiate

File copy :

$pw = convertto-securestring -AsPlainText -Force -String PASS
$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist "USER",$pw
$session = New-PSSession -ComputerName win10pro.localdomain -Credential $cred  -Authentication Negotiate
Copy-Item -Path 'C:UsersUSERDesktopsomefile.txt' -Destination /tmp/ -FromSession $session

Thanks!
Works for me on Manjaro with PS 7.2.1.

This comment was marked as off-topic.

@hunter86bg not to police this thread, but that might be off-topic since we’re in an issue tracker for keeping track of bugs and the thread could get closed or locked if it wanders too far from the original issue. this specific issue is with regards to entering/creating a PSsession and not necessarily performance issues encountered therein.

please create another issue describing your problem so that maybe the devers could look into it.

I spent days trying to figure out why the code below wasn’t working on Amazon Linux 2 (CentOS 7):

$serviceUserName = '<username>@my.company.domain'
$secStringPassword = '<password>'
​$secStringPassword = ConvertTo-SecureString $servicePassword -AsPlainText -Force
$credObject = New-Object System.Management.Automation.PSCredential ($serviceUserName, $secStringPassword)

$ExSession = New-PSSession –ConfigurationName Microsoft.Exchange –ConnectionUri ‘http://<hostname>.<domain>/PowerShell/?SerializationLevel=Full’ -Credential $credObject -Authentication Kerberos

Error message:

Enter-PSSession : Connecting to remote server hostname failed with the following error message : Kerberos verify cred with password failed No credentials were supplied, or the credentials were unavailable or inaccessible For more information, see the about_Remote_Troubleshooting Help topic.

Turns out the domain name in the username simply needed to be capitalized like so: <username>@MY.COMPANY.DOMAIN

Sorry if this is obvious, but hoping it helps someone else like me.

Installing gss-ntlmssp as stated in #11374 solved this issue for me.
I’m using -Authentication Negotiate.

It’s solution…..

This worked for me on Centos 7 with Powershell 7.1.3

Installing gss-ntlmssp as stated in #11374 solved this issue for me.
I’m using -Authentication Negotiate.

It’s solution…..

This worked for me on Centos 7 with Powershell 7.1.3

It’s a Debian package and not available in CentOS 7. There is gssntlmssp package but it is installed here and it’s still not working.