PowerShell 7 can remote over WS-Man/WinRM or over SSH. How do the two transports differ, and how would you choose between them?

seniorshould knowfreq 38%

answer

two ways in, same runspace above
who owns authentication
which one is Windows-only
the feature the newer one lacks

basics

~20 s

WS-Man is the Windows-native transport: SOAP over HTTP on ports 5985/5986, integrated with Windows authentication and session configurations. SSH transport tunnels PowerShell over an existing SSH connection, works uniformly on Linux and macOS, and uses SSH keys, but drops WS-Man-only features such as disconnected sessions.

solid answer

~40 s

WS-Man/WinRM is the original transport and the only one in Windows PowerShell 5.1. It speaks SOAP over HTTP on 5985 (HTTPS on 5986), is enabled with Enable-PSRemoting, authenticates with Windows credentials, and supports the richer session model — named session configurations via -ConfigurationName, constrained endpoints, and disconnect/reconnect with Disconnect-PSSession. SSH transport arrived with PowerShell 6 and is selected with -HostName (plus -UserName, -KeyFilePath, or -SSHTransport when passing an SSH connection hash). It requires PowerShell 7 on both ends and a Subsystem powershell line in the target's sshd_config, and it reuses SSH's authentication — keys, agents, the config you already have. Choose WS-Man inside a Windows domain where you want Windows auth and constrained endpoints; choose SSH for heterogeneous or cross-platform fleets where one transport for every host is worth more than the WS-Man-only features.

WS-Man/WinRM is the original transport and the only one in Windows PowerShell 5.1. It speaks SOAP over HTTP on 5985 (HTTPS on 5986), is enabled with `Enable-PSRemoting`, authenticates with Windows credentials, and supports the richer session model — named session configurations via `-ConfigurationName`, constrained endpoints, and disconnect/reconnect with `Disconnect-PSSession`. SSH transport arrived with PowerShell 6 and is selected with `-HostName` (plus `-UserName`, `-KeyFilePath`, or `-SSHTransport` when passing an SSH connection hash). It requires PowerShell 7 on both ends and a `Subsystem powershell` line in the target's `sshd_config`, and it reuses SSH's authentication — keys, agents, the config you already have. Choose WS-Man inside a Windows domain where you want Windows auth and constrained endpoints; choose SSH for heterogeneous or cross-platform fleets where one transport for every host is worth more than the WS-Man-only features.

code

powershell · 6 lines

powershell

$win = New-PSSession -ComputerName win01
$nix = New-PSSession -HostName linux01 -UserName ops -KeyFilePath ~/.ssh/id_ed25519

Invoke-Command -Session $win, $nix -ScriptBlock { $PSVersionTable.PSVersion }

Remove-PSSession $win, $nix

go deeper

for a junior

Know that PowerShell can reach a remote host two ways: the Windows WinRM service, or an SSH connection, and that the SSH option is what makes remoting to Linux possible.

for a middle

Name the concrete differences — ports 5985/5986 and Enable-PSRemoting versus an sshd_config subsystem entry, Windows credentials versus SSH keys, and the -HostName parameter set that selects SSH.

for a senior

Show you can pick for a real fleet: domain Windows favours WS-Man for Windows auth and constrained session configurations; mixed platforms favour SSH for one auth system and one firewall story. Know disconnected sessions are WS-Man only.

for a principal

Treat transport as an access-control and operations decision, not a preference: which authentication system you are willing to run, how endpoints are constrained, how access is audited and revoked, and how to keep scripts transport-agnostic so the choice can change later.

Same shell, two ways in

PowerShell remoting is layered: the top half — New-PSSession, Invoke-Command, Enter-PSSession, the object serialization, the remote runspace — is identical either way. What changes underneath is how the bytes get there and how you prove who you are.

WS-Man / WinRM

WS-Management is a SOAP-over-HTTP protocol; on Windows it is implemented by the WinRM service. Characteristics that matter in practice:

Ports 5985 (HTTP) and 5986 (HTTPS). The HTTP listener is not plaintext in the sense people fear — the payload is encrypted by the authentication layer when Kerberos or NTLM is used — but many organisations still require the HTTPS listener, which needs a certificate.
Enabled with Enable-PSRemoting, which starts and configures WinRM and registers the default session configurations.
Windows authentication. Inside a domain this is the selling point: Kerberos happens without you managing any key material.
Session configurations. Endpoints are named and registrable (Register-PSSessionConfiguration, Get-PSSessionConfiguration, selected with -ConfigurationName), which is how constrained endpoints — a restricted command set for a restricted audience — are built.
Disconnected sessions. Disconnect-PSSession / Connect-PSSession / Receive-PSSession let a runspace keep working with no client attached.
Workgroup friction. Outside a domain you must deal with the client's TrustedHosts list (WSMan:\localhost\Client\TrustedHosts) or certificate-based setup, which is where most 'it works in the lab' remoting problems come from.

SSH transport

PowerShell 6 added the ability to run remoting over an SSH connection, and it is what makes remoting genuinely cross-platform.

Setup is on the SSH server side: PowerShell registers itself as an SSH subsystem in sshd_config.

Subsystem powershell /usr/bin/pwsh -sshs -NoLogo

On Windows the same line points at pwsh.exe. sshd then knows how to start a PowerShell host for a client that asks for that subsystem.

On the client you select it by parameter set:

powershell

Invoke-Command -HostName linux01 -UserName ops -ScriptBlock { $PSVersionTable.OS }
$s = New-PSSession -HostName linux01 -UserName ops -KeyFilePath ~/.ssh/id_ed25519
Enter-PSSession -HostName linux01 -UserName ops

Note there is no -Credential here in the WS-Man sense: authentication is SSH's problem, so it is keys, agents, and whatever your ~/.ssh/config already does. For a team that already manages SSH access, this is a large operational simplification — no second authentication system, no second set of firewall rules.

What SSH transport gives up

PowerShell 7 on both ends. Windows PowerShell 5.1 cannot participate; a target that only has 5.1 must be reached over WS-Man.
No disconnected sessions. Disconnect/reconnect is a WS-Man capability.
The Windows-auth conveniences are not there, by design — you are on SSH's model instead.

Choosing

Ask what the fleet actually looks like.

Homogeneous Windows domain: WS-Man. Windows authentication is already solved, constrained session configurations give you a real least-privilege story, and disconnected sessions are useful for long jobs.

Linux, macOS, or a mix: SSH. One transport, one authentication system, one set of firewall rules across every host, and it composes with bastion hosts and existing SSH tooling you already operate.

Both: it is legitimate to use both, since the calling code is identical apart from the connection parameters. Write functions that take a PSSession rather than a computer name, and the choice of transport becomes a detail at the edge of your scripts:

powershell

function Get-AppHealth {
    param([System.Management.Automation.Runspaces.PSSession[]]$Session)
    Invoke-Command -Session $Session -ScriptBlock { Get-Service -Name MyApp }
}

That parameterisation is the senior answer: transports are an operational choice that should not leak into every script you write.

## Same shell, two ways in PowerShell remoting is layered: the top half — `New-PSSession`, `Invoke-Command`, `Enter-PSSession`, the object serialization, the remote runspace — is identical either way. What changes underneath is how the bytes get there and how you prove who you are. ## WS-Man / WinRM WS-Management is a SOAP-over-HTTP protocol; on Windows it is implemented by the WinRM service. Characteristics that matter in practice: - **Ports 5985 (HTTP) and 5986 (HTTPS).** The HTTP listener is not plaintext in the sense people fear — the payload is encrypted by the authentication layer when Kerberos or NTLM is used — but many organisations still require the HTTPS listener, which needs a certificate. - **Enabled with `Enable-PSRemoting`**, which starts and configures WinRM and registers the default session configurations. - **Windows authentication.** Inside a domain this is the selling point: Kerberos happens without you managing any key material. - **Session configurations.** Endpoints are named and registrable (`Register-PSSessionConfiguration`, `Get-PSSessionConfiguration`, selected with `-ConfigurationName`), which is how constrained endpoints — a restricted command set for a restricted audience — are built. - **Disconnected sessions.** `Disconnect-PSSession` / `Connect-PSSession` / `Receive-PSSession` let a runspace keep working with no client attached. - **Workgroup friction.** Outside a domain you must deal with the client's `TrustedHosts` list (`WSMan:\localhost\Client\TrustedHosts`) or certificate-based setup, which is where most 'it works in the lab' remoting problems come from. ## SSH transport PowerShell 6 added the ability to run remoting over an SSH connection, and it is what makes remoting genuinely cross-platform. Setup is on the SSH server side: PowerShell registers itself as an SSH subsystem in `sshd_config`. ``` Subsystem powershell /usr/bin/pwsh -sshs -NoLogo ``` On Windows the same line points at `pwsh.exe`. `sshd` then knows how to start a PowerShell host for a client that asks for that subsystem. On the client you select it by parameter set: ```powershell Invoke-Command -HostName linux01 -UserName ops -ScriptBlock { $PSVersionTable.OS } $s = New-PSSession -HostName linux01 -UserName ops -KeyFilePath ~/.ssh/id_ed25519 Enter-PSSession -HostName linux01 -UserName ops ``` Note there is no `-Credential` here in the WS-Man sense: authentication is SSH's problem, so it is keys, agents, and whatever your `~/.ssh/config` already does. For a team that already manages SSH access, this is a large operational simplification — no second authentication system, no second set of firewall rules. ## What SSH transport gives up - **PowerShell 7 on both ends.** Windows PowerShell 5.1 cannot participate; a target that only has 5.1 must be reached over WS-Man. - **No disconnected sessions.** Disconnect/reconnect is a WS-Man capability. - **The Windows-auth conveniences are not there,** by design — you are on SSH's model instead. ## Choosing Ask what the fleet actually looks like. *Homogeneous Windows domain:* WS-Man. Windows authentication is already solved, constrained session configurations give you a real least-privilege story, and disconnected sessions are useful for long jobs. *Linux, macOS, or a mix:* SSH. One transport, one authentication system, one set of firewall rules across every host, and it composes with bastion hosts and existing SSH tooling you already operate. *Both:* it is legitimate to use both, since the calling code is identical apart from the connection parameters. Write functions that take a `PSSession` rather than a computer name, and the choice of transport becomes a detail at the edge of your scripts: ```powershell function Get-AppHealth { param([System.Management.Automation.Runspaces.PSSession[]]$Session) Invoke-Command -Session $Session -ScriptBlock { Get-Service -Name MyApp } } ``` That parameterisation is the senior answer: transports are an operational choice that should not leak into every script you write.

What has to be configured on a Linux host before PowerShell can remote into it over SSH?
PowerShell 7 must be installed, and `sshd_config` needs a subsystem entry pointing at it — `Subsystem powershell /usr/bin/pwsh -sshs -NoLogo` — followed by restarting sshd. After that, normal SSH authentication applies, so the user's key or agent handles credentials and no WinRM configuration exists on that host at all.
Which remoting features are unavailable when you use the SSH transport?
Disconnected sessions are the clearest loss: `Disconnect-PSSession` and `Connect-PSSession` are WS-Man capabilities, so long-running work cannot be detached and reattached. You also give up the Windows-authentication conveniences, because SSH's own key-based model replaces them entirely.
Why do people hit trouble using WS-Man remoting between machines that are not domain-joined?
Without a domain there is no Kerberos, so the client cannot mutually authenticate the target by name. You must either add the target to the client's `TrustedHosts` list under `WSMan:\localhost\Client\TrustedHosts` — which weakens server verification — or set up an HTTPS listener with a certificate. That configuration step is what most lab-only remoting setups skip.
How do you keep a script from being tied to one transport?
Have your functions accept a `PSSession` object rather than a computer name, and create the session at the edge with either `New-PSSession -ComputerName` or `New-PSSession -HostName`. Everything above that line — Invoke-Command, serialization, output shape — is identical, so the transport becomes a caller's decision instead of an assumption baked into every script.

saying these in an interview costs you the question

Claims Windows PowerShell 5.1 can remote over SSH
Thinks SSH transport just runs pwsh through a plain ssh command
Says WS-Man on port 5985 sends credentials in the clear
Assumes -Credential works the same on the SSH parameter set
Believes disconnected sessions work over either transport

PowerShell 7 can remote over WS-Man/WinRM or over SSH. How do the two transports differ, and how would you choose between them?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

Same shell, two ways in

WS-Man / WinRM

SSH transport

What SSH transport gives up

Choosing

▾common follow-ups4 questions

▾red flags5 flags

§ context

▾related questions6 questions

▾related topics4 topics

Same shell, two ways in

WS-Man / WinRM

SSH transport

What SSH transport gives up

Choosing

answer

go deeper

context