Question
JEA Endpoint Behavior Changes When Switching PowerShell Remoting to SSH Transport
Ash Sage
0 reputation · 06 Mar 2021, 14:03 UTC
36.2K views1
Loading…
0 reputation · 06 Mar 2021, 14:03 UTC
Organizations evaluating the shift from WinRM to SSH as the transport for PowerShell remoting need to know whether existing Just Enough Administration (JEA) endpoints continue to enforce their role definitions and session restrictions without modification. While SSH provides a cross‑platform, firewall‑friendly channel, it does not expose the full WS‑Management feature set that WinRM‑based remoting relies on for certain JEA behaviors such as constrained language mode enforcement and detailed audit logging.
Because the SSH subsystem invokes the PowerShell executable directly, some WinRM‑specific processing—like the automatic application of ConnectionInfo options and the propagation of certain WS‑Man headers—is absent. This raises uncertainty about whether JEA’s role capability files, session configurations, and logging mechanisms will behave identically when the underlying transport changes.
Does SSH transport preserve JEA role capabilities and session constraints? What configuration adjustments, if any, are required for JEA endpoints to operate over SSH? Are there any limitations in logging or auditing when JEA uses SSH transport?
34775 reputation · 06 Mar 2021, 17:32 UTC
Just Enough Administration (JEA) endpoints are selected by the session‑configuration name supplied at connection time. The underlying transport—WinRM/HTTPS or SSH—does not change which .pssc file is loaded.
When a client connects over SSH, the remote subsystem launches the PowerShell host (pwsh or powershell) with the same invocation parameters used for WinRM remoting. Consequently, the language mode (typically ConstrainedLanguage) and the role‑capability restrictions defined in the JEA endpoint are applied unchanged.
Auditable events generated inside the PowerShell host—module logging, command logging, and any custom logging—are produced identically for both transports because the JEA authorization pipeline runs after the transport handshake.
Any variation in connection reliability, idle timeout, or credential prompting when switching to SSH is usually due to SSH‑specific settings (e.g., ServerAliveInterval, authentication method, AllowTcpForwarding) rather than a change in JEA’s role‑based access controls.
Switching from WS‑Man message framing to an encrypted SSH channel can affect network‑level keep‑alives, but the visible JEA functions and language mode remain the same.
ssh
powershellGet-Date).Enter-PSSession -ComputerName target -UseSSL -ConfigurationName MyJEANew-PSSession -HostName target -SSHTransport -ConfigurationName MyJEAssh user@target -s powershell -c "Enter-PSSession -ConfigurationName MyJEA"Get-PSSessionConfiguration | Where-Object Name -eq 'MyJEA' | Format-List Name, GUID, LanguageModessh -vvv ...) and server logs (/var/log/auth.log or /var/log/secure) for transport‑level disconnects or authentication failures.If you encounter unexpected credential prompts or session termination, please provide the SSH authentication method you are using (password, public key, certificate) and the ServerAliveInterval setting configured on the client or server. This information determines whether the issue is transport‑related rather than a JEA configuration problem.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 06 Mar 2021, 21:34 UTC
While JEA role capabilities remain consistent across transports, it is important to verify how the user's security token is mapped during the SSH handshake compared to WinRM. Because SSH utilizes a different authentication flow, the resulting session identity must be validated to ensure the JEA role is being applied to the correct security principal.
[Security.Principal.WindowsIdentity]::GetCurrent().Name in both a WinRM and SSH session to confirm the identity mapping is identical.Get-PSDrive and Get-Variable. Differences in environment variable propagation or profile loading between the two transports can occasionally affect the initialization of the constrained session.Additionally, ensure the OpenSSH server is explicitly configured to launch the PowerShell process with the intended session configuration to prevent users from inadvertently dropping into a full shell.