Enabling and using PowerShell remoting: WinRM, TrustedHosts, and the second-hop limit

Goal

Turn on PowerShell remoting on a Windows Server 2019/2022/2025 host and drive it from an agent session — locally over WinRM, or over SSH where only port 22 is open — without leaving an over-broad trust setting behind.

Prerequisites

Local administrator rights on the target; the WinRM service allowed to start; for a non-domain target or a connection by IP address, either an HTTPS listener with a certificate or an explicit TrustedHosts entry, set on the machine that initiates the connection.

Steps

1. Check current state: Get-Service WinRM; Test-WSMan SRV1.
2. Enable remoting non-interactively: Enable-PSRemoting -Force -SkipNetworkProfileCheck. This starts and auto-starts the WinRM service and creates the default listener and firewall rule; -Force suppresses the per-step confirmation prompts so the call does not hang in an unattended run.
3. If the target is not domain-joined, or you must connect by IP rather than name, Kerberos mutual authentication is unavailable. Microsoft's own troubleshooting guidance states: "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." Prefer an HTTPS listener with a certificate; only use Set-Item WSMan:\localhost\Client\TrustedHosts -Value '10.0.0.5' -Force when you accept that TrustedHosts skips server identity verification.
4. Run non-interactive work with Invoke-Command -ComputerName SRV1 -Credential $cred -ScriptBlock { Get-Service }; use Enter-PSSession -ComputerName SRV1 only for interactive troubleshooting, not inside unattended scripts, since it blocks on a prompt.
5. Where only SSH is open, or across mixed platforms, PowerShell 7 can remote over SSH instead of WinRM once the OpenSSH Server has the PowerShell subsystem configured: Invoke-Command -HostName SRV1 -UserName admin -SSHTransport -ScriptBlock { hostname }.

Expected result

Test-WSMan returns a response object, Invoke-Command returns output without prompting, and an SSH-based session authenticates against the configured subsystem.

Limits and test basis

The credentials used to open a remote session do not flow on to a second remote computer accessed from inside that session — Microsoft's documentation names this "the second hop" — because the token is not delegated by default; CredSSP or Kerberos resource-based constrained delegation are the documented workarounds, each with its own trade-offs. To undo: Disable-PSRemoting -Force and Clear-Item WSMan:\localhost\Client\TrustedHosts remove what step 2–3 added; back up the existing TrustedHosts value first with (Get-Item WSMan:\localhost\Client\TrustedHosts).Value if other automation depends on it. No reboot is required for any of these steps; a new PowerShell session is needed for $PSSessionConfigurationName changes to take effect.