Sessione PS remota non riuscita su server non di dominio


10

Sto provando a connettermi a un server Win2008R2 remoto non appartenente al dominio usando PS da un host Win8 (stessa sottorete, è una VM locale). Ho provato tutto quello che ho potuto trovare, niente funziona.

SERVER:

PS C:\Users\Administrator> winrm quickconfig
PS C:\Users\Administrator> enable-psremoting

CLIENTE:

PS C:\scripts> $cred = get-credential -username "administrator" -message "Enter password"

PS C:\scripts> $sess = new-pssession -computername 10.10.106.2 -credential $cred -authentication default
new-pssession : [10.10.106.2] Connecting to remote server 10.10.106.2 failed with the following error message : The
WinRM client cannot process the request. If the authentication scheme is different from Kerberos, or if the client
computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the
TrustedHosts configuration setting. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts
list might not be authenticated. You can get more information about that by running the following command: winrm help
config. For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:9
  + $sess = new-pssession -computername 10.10.106.2 -credential $cred -authenticatio ...
  + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotingTransportException
    + FullyQualifiedErrorId : ServerNotTrusted,PSSessionOpenFailed

PS C:\scripts> winrm set winrm/config/client '@{TrustedHosts="10.10.106.2"}'
WSManFault
Message = The client cannot connect to the destination specified in the request. Verify that the service on the dest
ination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running o
n the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the
destination to analyze and configure the WinRM service: "winrm quickconfig".
Error number:  -2144108526 0x80338012
The client cannot connect to the destination specified in the request. Verify that the service on the destination is run
ning and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destinat
ion, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination t
o analyze and configure the WinRM service: "winrm quickconfig".

PS C:\scripts> $sess = new-pssession -computername 10.10.106.2 -credential $cred -usessl
new-pssession : [10.10.106.2] Connecting to remote server 10.10.106.2 failed with the following error message : WinRM
cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over
the network, and that a firewall exception for the WinRM service is enabled and allows access from this computer. By
default, the WinRM firewall exception for public profiles limits access to remote computers within the same local
subnet. For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:9
  + $sess = new-pssession -computername 10.10.106.2 -credential $cred -usessl
  +         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin   gTransportException
    + FullyQualifiedErrorId : WinRMOperationTimeout,PSSessionOpenFailed

Oh e RDP funzionano bene tra quei due host con le stesse credenziali.

Anche questo funziona:

PS C:\scripts> Get-WinEvent -computername 10.10.106.2 -credential $cred

Risposte:


17

Dal lato client

winrm quickconfig
winrm set winrm/config/client '@{TrustedHosts="Computer1,Computer2"}'

Sul lato server

Enable-PSRemoting -Force
winrm quickconfig

per https

winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="_";CertificateThumbprint="_"}

per http

winrm create winrm/config/Listener?Address=*+Transport=HTTP

Prova con

Test-WsMan ComputerName
Test-WsMan ComputerName -UseSSL

Modifica: imposta TrustedHosts con PowerShell

O con PowerShell (come amministratore)

Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value "Computer1,Computer2"

E controlla (non è necessario l'amministratore per quello)

Get-Item WSMan:\localhost\Client\TrustedHosts

5

Il tuo problema, come riscontrato in uno di questi messaggi di errore, è:

Se lo schema di autenticazione è diverso da Kerberos o se il computer client non è unito a un dominio, è necessario utilizzare il trasporto HTTPS o aggiungere il computer di destinazione all'impostazione di configurazione TrustedHosts.

Fondamentalmente, è necessario impostare WinRM per utilizzare HTTPS (anziché l'HTTP predefinito) oppure aggiungere il computer da cui ci si sta connettendo come host attendibile sul computer a cui ci si sta connettendo.


Non riesco a usare quel comando poiché non esiste un certificato valido sul server. Come vedi nella mia domanda originale, ho provato ad aggiungere la macchina agli host affidabili sul lato client. Devo fare lo stesso anche sul lato server?
Dendory,

RDP nel server remoto e impostare gli host attendibili dalla sessione RDP, se è così che si desidera procedere. Penso che sia più semplice e molto meglio impostare WinRM / WinRS in modo che utilizzi HTTPS anziché HTTP su tutti i computer che gestisco (per più motivi oltre a questo particolare problema), ma immagino che sia la tua chiamata.
HopelessN00b

Sì, ma a quanto pare PS HTTPS richiede un vero certificato (non autofirmato) insieme a un nome DNS pubblico. Perché non utilizza la stessa crittografia di RDP? Non ho bisogno di niente di speciale per questo. Questa è una VM locale per lo sviluppo e tale, nessuna scelta, non può ottenere una CA pubblica per essa.
Dendory,

winrm set winrm/config/client '@{TrustedHosts="10.10.106.1"}'ha funzionato sul server, ma ho ancora gli stessi messaggi di errore sul mio client, non si connetterà ancora.
Dendory,

1
@Dendory WinRM su HTTPS funziona correttamente con un certificato emesso da un'autorità di certificazione interna, a condizione che la macchina sia configurata correttamente per fidarsi della CA emittente. Non richiede che la macchina abbia un nome DNS esterno valido, solo che si utilizza il suo nome DNS e anche il certificato. Se questa non è un'opzione, per qualsiasi motivo, dovrai sperare che arrivi qualcun altro che possa aiutarti a farlo funzionare solo con la voce Trusted Hosts (voci?) - Non lo faccio proprio perché, perché è troppo doloroso nel culo e non sembra funzionare in modo affidabile per me.
HopelessN00b

1

Il mio problema era per un'istanza ospitata in AWS.

  • Ho dovuto aprire 5985 sul gruppo di sicurezza dell'istanza
  • Ho dovuto modificare la regola del firewall per consentire 5985 per tutti i profili e qualsiasi indirizzo remoto

    New-NetFirewallRule -Name PsRemotingHttp -Direction Inbound -Action Allow -Protocol tcp -LocalPort 5985 -DisplayName PsRemotingHttp

L'ho capito quando ho eseguito test-wsman:

"Per impostazione predefinita, l'eccezione del firewall WinRM per i profili pubblici limita l'accesso ai computer remoti all'interno della stessa sottorete locale."


0

Finalmente sono riuscito a far funzionare il mio ... dove xxx.xxx.xxx.xxx è l'indirizzo IP.

PS C:\Users\Administrator> winrm quickconfig
WinRM service is already running on this machine.
WinRM is already set up for remote management on this computer.
PS C:\Users\Administrator> Enable-PSRemoting -Force
WinRM is already set up to receive requests on this computer.
WinRM is already set up for remote management on this computer.
PS C:\Users\Administrator> winrm set winrm/config/client '@{TrustedHosts="xxx.xxx.xxx.xxx"}'
Client
    NetworkDelayms = 5000
    URLPrefix = wsman
    AllowUnencrypted = false
    Auth
        Basic = true
        Digest = true
        Kerberos = true
        Negotiate = true
        Certificate = true
        CredSSP = false
    DefaultPorts
        HTTP = 5985
        HTTPS = 5986
    TrustedHosts = xxx.xxx.xxx.xxx

PS C:\Users\Administrator> Enter-PSSession  -ComputerName xxx.xxx.xxx.xxx -Credential "~\Administrator"
[xxx.xxx.xxx.xxx]: PS C:\Users\Administrator\Documents>

0

Dopo mesi di questo problema, per me è risultato che avevo bisogno di aggiungere sia l'IP del server remoto sia il nome DNS agli host fidati. Basta aggiungere l'IP non era sufficiente!

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.