You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
General question:
Why would a Linux sysadmin stop using BASH with remote commands and swap to a JEA endpoint ?
I mean on a windows machine, I can stop RDP, create a JEA endpoint, and give my NOC team a script to do a specific job using specific cmdlets that I pre-configured in the JEA endpoint. This way I closed the GUI way, didn't give them local admin to the box so they cant use the other methods to remotely run commands.
What's the equivalent in Linux world ? Wouldn't a SSH with BASH just override the JEAL ( JEA on Linux :) )
Good question. From my perspective, this backlog item isn't to copy JEA as it exists on Windows today to Linux, but to investigate scenarios that necessitated JEA and see how it applies to Linux and what experience makes sense on Linux (ideally updating the Windows experience if it makes sense to have it consistent). A possible outcome is that existing Linux tools are fine and this is just a documentation thing.
Can you elevate a powershell script to act as if one used sudo root or similar ?
If I wanted my NOC to run a remote command on a Linux box and I didn't want to give them admin rights but the command itself necessitated higher permission, would PS be able to do it via JEA ?
What tools do Linux Sysadmins have today to carry such delegation tasks ?
Ive always liked the idea of JEA (and DSC) being cross platform. But before we start accepting PRs, we should have clarity over the design. What features would it have, and what new features could be ported back to Windows (JEA v2, so to speak). Then PRs can come.
I'm reopening this for discussion & to gather more background from soroshsabz about their usecase.
As Steve Lee (@SteveL-MSFT) mentioned previously this project may not look at a JEA implementation on Linux at all.
A possible outcome is that existing Linux tools are fine and this is just a documentation thing.
I asked Copilot (copilot.microsoft.com) about this and simply asked about a "fix" - though I'm not sure about the timelines that it has given back
Copilot response
If by "fixing" issue #2198 you mean actually delivering JEA on Linux I'd classify it as a large feature, not a bug fix. The issue itself was never scoped beyond "investigate how to implement JEA on Linux", and even the original discussion questions whether native Linux mechanisms already solve the problem differently.github
My estimate would be:
Scope
Effort
Investigation/design document
1 to 3 weeks
Minimal proof-of-concept
2 to 6 weeks
Production-ready Linux JEA implementation
3 to 9 months
Cross-platform JEA model aligned with Windows
6 to 12+ months
Why so expensive?
The hard part isn't PowerShell
Windows JEA relies heavily on things that don't really exist on Linux in the same form:
Session configurations
RunAs accounts / virtual accounts
WinRM security model
Constrained endpoints
Windows privilege delegation
Linux already has:
sudo
polkit
SSH forced commands
RBAC implementations
containers/namespaces
The challenge is deciding what JEA even means on Linux. Steve Lee basically hints at this in the issue discussion.github
Add a way for specific commands to execute through:
sudo
polkit
custom brokers
without granting full shell access.
This is where things get messy.
Estimate: another 1 to 3 months.
Phase 3 - Full JEA parity
Windows-like concepts:
role capability files
endpoint definitions
delegated identities
auditing
transcription
temporary privilege elevation
This is probably multiple months of design and review.
Estimate: 3 to 6 months.
For PowerShell today
If this landed as a community PR, I'd expect maintainers to accept something closer to:
"Constrained remoting endpoint on Linux"
rather than
"Windows JEA completely reimplemented on Linux"
The first is a realistically reviewable feature. The second is almost an architectural project spanning remoting, security, hosting, and platform abstractions.
So if you asked me as a PowerShell contributor:
Good first implementation: ~1-2 months of focused work.
Something Microsoft could document as "JEA on Linux": ~6 months.
True feature parity with Windows JEA: probably a year-scale effort.
My "What JEA would likely look like on Linux" would be a hardened SSH endpoint that uses auth_keys and defaults to pwsh as the shell of choice, with all access to other tooling restricted
So I then asked.
For a JEA endpoint on linux via PowerShell can we enforce that when someone connects via ssh that they can only load the PowerShell backed session?
Yes, and in fact that's probably the most realistic foundation for a Linux JEA implementation.
SSH already supports forcing a specific command instead of providing an interactive shell. You can configure a user so that every SSH login executes PowerShell and nothing else:
Match User jea-user
ForceCommand /usr/bin/pwsh -sshs -NoLogo -NoProfile
At that point the user cannot drop into bash through the normal SSH login flow.
The next challenge is what happens inside PowerShell.
Today a user could potentially:
bash
sh
/bin/bash
Start-Process bash
or invoke native commands directly. A true JEA-style endpoint would need to restrict that.
I think a Linux JEA MVP could look something like:
SSH login forced into PowerShell remoting.
Connection mapped to a session configuration.
Session configuration exposes only approved cmdlets/functions.
Native command invocation disabled.
Script block creation restricted.
Selected commands elevated through a sudo/polkit broker.
Architecturally that isn't enormously different from Windows JEA. The biggest missing piece is that PowerShell currently lacks a cross-platform constrained language/remoting model that can reliably prevent escaping to native processes.
The interesting question is whether PowerShell itself needs to enforce the restriction, or whether Linux should do it for us.
only gains elevated actions through approved PowerShell functions
In that design, JEA becomes mostly a runspace-constrained remoting endpoint, while Linux handles the outer security boundary.
Honestly, if I were pitching a PR to PowerShell today, I'd scope it as:
"Support Linux Session Configurations and constrained SSH endpoints"
rather than
"Implement Windows JEA on Linux"
The former feels like a few months of engineering. The latter opens the door to virtual accounts, delegated identities, auditing semantics, and all the Windows-specific JEA machinery that would be extremely expensive to reproduce cross-platform.
I then asked
Can we use different authKey lists to grant different access rights for things to run today - or woudl that require essentially a new ssh listening endpoint for these seperate group/s of users?
You can actually get surprisingly far with **existing OpenSSH features** without needing multiple SSH daemons.
Option 1: Different users, different PowerShell endpoints
The simplest model is:
jea-ops
jea-helpdesk
jea-auditors
and then:
Match User jea-ops
ForceCommand /usr/bin/pwsh -sshs -ConfigurationName Ops
Match User jea-helpdesk
ForceCommand /usr/bin/pwsh -sshs -ConfigurationName Helpdesk
Each Linux account maps to a different PowerShell session configuration.
This is essentially how Windows JEA works today via endpoint selection.
This is quite interesting because the SSH key effectively becomes the role assignment.
Option 3: Use groups
You can also drive behaviour from the Linux account's group membership:
Match Group pwsh-helpdesk
ForceCommand /usr/bin/pwsh -sshs -ConfigurationName Helpdesk
Match Group pwsh-ops
ForceCommand /usr/bin/pwsh -sshs -ConfigurationName Ops
So a Linux JEA implementation would likely need one of:
SSH forcing PowerShell with a specific session configuration.
PowerShell determining the role based on user/group/key information.
An enhancement to PowerShell SSH remoting to support endpoint selection natively.
Would you need multiple SSH listeners?
No, not necessarily.
One sshd instance can already handle:
different users
different groups
different keys
different forced commands
through Match rules and authorized_keys options.
I would only introduce separate SSH listeners/ports if I wanted completely separate security boundaries, such as:
22 -> Standard Linux administration
2222 -> PowerShell JEA endpoint
but from a purely technical standpoint, that's not required.
Honestly, if someone proposed Linux JEA to the PowerShell committee, I'd argue the MVP should piggy-back on SSH's existing capability to select a command based on the authenticated identity or key. OpenSSH has already solved most of the endpoint-routing problem; PowerShell would mainly need to provide the constrained runspace once the user lands in pwsh.
Summary
It's technically doable, but is there enough desire in having this feature?
Also, we have to be mindful of being able to support this if it were to be implemented too.
It definitely feels like a "very nice to have" but without any data (that I know of - which may well exist) about how widespread JEA has been used in orgs in Windows environments already.
JEA is definitely one of those features that I personally heard less around implementations of it than I expected, which actually could have tied in with me having multiple periods of time out from the community so missing those discussions, however I think that at least in the UK the sort of orgs that likely did implement this would in many cases not have publicly discussed them doing so anyway.
I don't personally see how this could be implemented outside of this repo, via the likes of a module, due to how interlinked it is to engine features and would need to be of very high quality for this to be accepted as a community PR and definitely would need a predefined feature set to look at implementing PRIOR to any work being started on this.
Note: this isn't me posting on behalf of the Engine WG but dotting down thoughts for a time when that group comes to discuss this.
I believe JEA on Linux is particularly important for appliance products whose administrative interface is based on PowerShell.
The requirement is not to make Linux behave like Windows or to replace SSH, Bash, or sudo. The requirement is to provide a supported, PowerShell-native authorization boundary for appliances that expose PowerShell as their management CLI.
Why SSH and Bash are not an equivalent
A Linux appliance may use SSH as its transport, but SSH by itself does not provide the administrative model required by an appliance CLI:
SSH authenticates the user, but does not define which PowerShell commands that user may execute.
A normal SSH session can provide Bash, arbitrary native commands, file access, tunneling, port forwarding, and access to other management interfaces.
sudo delegates individual Linux executables or command lines, but it does not naturally express PowerShell command visibility, parameter constraints, validation, or PowerShell-specific roles.
A PowerShell script that internally invokes sudo is not, by itself, a security boundary. The effective restriction must be enforced by the host and authorization layer, not merely by the script author.
If a user can obtain an unrestricted Bash or PowerShell session, they can generally bypass restrictions imposed only inside a script.
Linux has excellent building blocks for delegation, including sudo, doas, polkit, file permissions, systemd services, SELinux, AppArmor, containers, and SSH forced commands. However, these mechanisms do not provide a consistent PowerShell endpoint model for a PowerShell-based appliance.
Appliance-specific use case
Consider an appliance with the following operational roles:
A NOC operator may restart a service, collect diagnostics, rotate a certificate, or retrieve a support bundle.
A field engineer may modify a limited set of network settings.
A security administrator may manage users and audit configuration.
The appliance platform administrator may have full access.
The appliance should not need to expose:
A root shell
An unrestricted Bash session
A full PowerShell session
The complete implementation of the appliance
Internal files, credentials, or unrelated administrative functions
Instead, it should expose a narrowly defined management surface such as:
The authorization boundary should be enforced by the endpoint, not by asking every client application or operator to invoke the correct script manually.
This is the same core problem that JEA addresses on Windows: reduce the exposed administrative surface, delegate only the required operations, provide role-based access, and preserve auditing.
Why this matters even when Linux already has sudo
An appliance vendor can implement this using a combination of SSH, sudo, wrapper scripts, and restricted shells. However, that leads to several problems:
Each vendor creates a different authorization model.
PowerShell commands and Linux commands are governed by separate policy systems.
Command and parameter validation must be duplicated in wrapper programs.
The supported management experience differs between Windows and Linux appliances.
It consistent PowerShell remoting and auditing model.
auditing model.
Vendors may accidentally create escape paths through argument handling, environment variables, writable scripts, command substitution, or unrestricted native process execution.
The resulting implementation is difficult to reason about and difficult for customers to audit.
A cross-platform JEA model would allow the appliance to express its administrative contract in the same language as its management interface.
The goal is not to claim that JEA can replace every Linux security mechanism. Linux authorization primitives would still be required underneath the endpoint. The goal is to provide a PowerShell-aware policy and execution layer that integrates with those primitives.
Important design requirement
A Linux implementation should not simply run a restricted PowerShell script over a normal SSH session. That would be insufficient if the user can also obtain Bash, start another PowerShell process, execute unrestricted native commands, or modify the scripts used by the endpoint.
A useful Linux design would need to define at least:
A non-interactive, constrained PowerShell endpoint
Role capabilities and command allowlists
Parameter validation and argument restrictions
Explicit treatment of native commands
A clear policy for privilege transitions such as sudo
Prevention of shell escape and unrestricted child processes
File-system and environment isolation
Authentication and authorization integration
Session and command auditing
Support for SSH, local execution, and potentially other transports
A documented security model for endpoint ownership and writable resources
A way for the appliance vendor to expose only its supported management commands
The privilege model also needs to be explicit. In some cases, the PowerShell process may need to run with a service account that has narrowly scoped Linux capabilities. In other cases, a command may invoke a privileged helper through sudo, systemd, polkit, or a dedicated daemon. That decision should be part of the endpoint policy and appliance architecture, rather than an implicit consequence of the operator having a shell.
Suggested scope for the investigation
I would suggest treating this as a cross-platform administrative endpoint design problem, with the following questions:
What security and delegation scenarios currently require JEA on Windows?
Which of those scenarios are already adequately addressed by Linux primitives?
Which scenarios require a PowerShell-aware endpoint?
What should be common between Windows and Linux?
What must remain platform-specific?
How can native command execution be restricted safely?
How should privileged operations be delegated without granting general root access?
What endpoint and auditing guarantees can be provided over SSH?
How can appliance vendors package and support role capabilities without exposing implementation details?
The outcome may show that some scenarios are best solved with existing Linux tools and documentation. That would still be valuable. However, for appliances whose primary CLI is PowerShell, the investigation should also evaluate whether Linux currently has a supported way to expose a restricted PowerShell administrative endpoint. At present, SSH-based PowerShell remoting is primarily a basic remoting mechanism; it does not provide the same remote endpoint configuration and JEA experience available on Windows.
Proposal
I recommend reopening the issue, but with a design-first scope rather than immediately accepting an implementation.
The deliverable could be a design document or prototype defining:
The threat model
The appliance scenarios
The endpoint lifecycle
Role capability format
Privilege delegation model
Native command policy
Escape prevention requirements
Auditing behavior
SSH and local transport behavior
Compatibility expectations with Windows JEA
Features that could become part of a future JEA v2 model
This would benefit both Linux appliances and Windows. A consistent, cross-platform constrained administration model would allow vendors to build one PowerShell-based management experience while still respecting the security model of each operating system.
For PowerShell-based appliances, this is not merely a convenience feature. It is part of the security boundary of the product. Without it, vendors must either expose a broader shell than intended or build and maintain their own collection of SSH restrictions, wrapper commands, sudo rules, privileged helpers, and auditing mechanisms. A supported JEA model would reduce that duplication and provide customers with a security model they can understand, review, and audit.
For me, a more detailed investigation, based on the headings above, would be useful before we start creating code. The suggested scope seems comprehensive to me. Lets see the results and then move oin?
Thomas Lee (@doctordns) Would you like help drafting that investigation document? I could outline it section by section, mapping each heading to the relevant code in this repo (e.g., InitialSessionStateProvider.cs, SSH remoting code paths) so the design is grounded in what actually exists today.
soroshsabz Thanks for the offer! ;-) As an old retired guy with literally zero Linux skills, I am not sure I'm the right person to help specify JEA V2, aka JEA on Linux/Mac. But some thoughts:
Let's start at the beginning: JEA handles three things:
Managing who is connecting to/from a given host.
Managing what cmdlets and (native) commands they are allowed to run and what arguments they are allowed to use.
Managing the privileges those commands need to function properly.
So, for me, the overall objective should be twofold: to bring JEA V1 functionality to Linux/Mac and to improve the overall JEA feature for Windows.
Managing who connects will obviously be different in Linux using SSL; I don't have the skills to say how connection authorisation would work. But it seems reasonable to assume it should be defined in a session control file. This document probably needs some improvements to handle connecting over SSL.
The current JEA on Windows seems to do an OK job managing the commands someone can run. So I suspect role capability definition files should easily handle restricting PowerShell cmdlets running in a JEA remote session. But I think we still need to work on how to manage and restrict more complex Linux commands. Linux commands can have much more complex and cryptic arguments whose use it may be appropriate to manage via JEA.
I do not know enough about privilege in Linux to speak to how privilege can be managed on Linux.
I would also like to see more AD integration (ie on Windows). I'd like to be able to push the JEA definition files via Group Policy. And while it may be more appropriate for DSC to deal with, should there be some way to push modules to a server which a JEA endpoint may need to utilise?).
I have a suggestion: create a new repo and begin to develop the JEA V2 definition there. Once the definition is complete, we can work on how to implement it.
Activity
ArieHein commentedon Sep 6, 2016
General question:
Why would a Linux sysadmin stop using BASH with remote commands and swap to a JEA endpoint ?
I mean on a windows machine, I can stop RDP, create a JEA endpoint, and give my NOC team a script to do a specific job using specific cmdlets that I pre-configured in the JEA endpoint. This way I closed the GUI way, didn't give them local admin to the box so they cant use the other methods to remotely run commands.
What's the equivalent in Linux world ? Wouldn't a SSH with BASH just override the JEAL ( JEA on Linux :) )
SteveL-MSFT commentedon Sep 6, 2016
Good question. From my perspective, this backlog item isn't to copy JEA as it exists on Windows today to Linux, but to investigate scenarios that necessitated JEA and see how it applies to Linux and what experience makes sense on Linux (ideally updating the Windows experience if it makes sense to have it consistent). A possible outcome is that existing Linux tools are fine and this is just a documentation thing.
ArieHein commentedon Sep 6, 2016
Can you elevate a powershell script to act as if one used sudo root or similar ?
If I wanted my NOC to run a remote command on a Linux box and I didn't want to give them admin rights but the command itself necessitated higher permission, would PS be able to do it via JEA ?
What tools do Linux Sysadmins have today to carry such delegation tasks ?
SteveL-MSFT commentedon Sep 6, 2016
Currently you can elevate the entire powershell session via sudo. There is an existing issue to get sudo working within a PowerShell session #1527
12 remaining items
doctordns commentedon Sep 26, 2026
Ive always liked the idea of JEA (and DSC) being cross platform. But before we start accepting PRs, we should have clarity over the design. What features would it have, and what new features could be ported back to Windows (JEA v2, so to speak). Then PRs can come.
Is it worth reopening this issue?
kilasuit commentedon Sep 27, 2026
I'm reopening this for discussion & to gather more background from soroshsabz about their usecase.
As Steve Lee (@SteveL-MSFT) mentioned previously this project may not look at a JEA implementation on Linux at all.
I asked Copilot (copilot.microsoft.com) about this and simply asked about a "fix" - though I'm not sure about the timelines that it has given back
Copilot response
If by "fixing" issue #2198 you mean actually delivering JEA on Linux I'd classify it as a large feature, not a bug fix. The issue itself was never scoped beyond "investigate how to implement JEA on Linux", and even the original discussion questions whether native Linux mechanisms already solve the problem differently.github
My estimate would be:
Why so expensive?
The hard part isn't PowerShell
Windows JEA relies heavily on things that don't really exist on Linux in the same form:
Linux already has:
The challenge is deciding what JEA even means on Linux. Steve Lee basically hints at this in the issue discussion.github
If I were implementing it today
I'd probably split it into phases:
Phase 1 - Constrained PowerShell endpoint
Allow:
where "Operators":
This is mostly PowerShell engine work.
Estimate: 4 to 8 weeks.
Phase 2 - Privilege elevation integration
Add a way for specific commands to execute through:
without granting full shell access.
This is where things get messy.
Estimate: another 1 to 3 months.
Phase 3 - Full JEA parity
Windows-like concepts:
This is probably multiple months of design and review.
Estimate: 3 to 6 months.
For PowerShell today
If this landed as a community PR, I'd expect maintainers to accept something closer to:
rather than
The first is a realistically reviewable feature. The second is almost an architectural project spanning remoting, security, hosting, and platform abstractions.
So if you asked me as a PowerShell contributor:
My "What JEA would likely look like on Linux" would be a hardened SSH endpoint that uses auth_keys and defaults to pwsh as the shell of choice, with all access to other tooling restricted
So I then asked.
For a JEA endpoint on linux via PowerShell can we enforce that when someone connects via ssh that they can only load the PowerShell backed session?
Yes, and in fact that's probably the most realistic foundation for a Linux JEA implementation.
SSH already supports forcing a specific command instead of providing an interactive shell. You can configure a user so that every SSH login executes PowerShell and nothing else:
or via
authorized_keys:At that point the user cannot drop into
bashthrough the normal SSH login flow.The next challenge is what happens inside PowerShell.
Today a user could potentially:
or invoke native commands directly. A true JEA-style endpoint would need to restrict that.
I think a Linux JEA MVP could look something like:
Architecturally that isn't enormously different from Windows JEA. The biggest missing piece is that PowerShell currently lacks a cross-platform constrained language/remoting model that can reliably prevent escaping to native processes.
The interesting question is whether PowerShell itself needs to enforce the restriction, or whether Linux should do it for us.
For example:
and the Linux account itself:
/usr/sbin/nologin)In that design, JEA becomes mostly a runspace-constrained remoting endpoint, while Linux handles the outer security boundary.
Honestly, if I were pitching a PR to PowerShell today, I'd scope it as:
rather than
The former feels like a few months of engineering. The latter opens the door to virtual accounts, delegated identities, auditing semantics, and all the Windows-specific JEA machinery that would be extremely expensive to reproduce cross-platform.
I then asked
Can we use different authKey lists to grant different access rights for things to run today - or woudl that require essentially a new ssh listening endpoint for these seperate group/s of users?
You can actually get surprisingly far with **existing OpenSSH features** without needing multiple SSH daemons.
Option 1: Different users, different PowerShell endpoints
The simplest model is:
and then:
Each Linux account maps to a different PowerShell session configuration.
This is essentially how Windows JEA works today via endpoint selection.
Option 2: Different public keys, same user
OpenSSH's
authorized_keyssupports per-key options:So:
even though both authenticate as:
This is quite interesting because the SSH key effectively becomes the role assignment.
Option 3: Use groups
You can also drive behaviour from the Linux account's group membership:
Then onboarding someone is just:
Where it gets awkward
PowerShell SSH remoting today doesn't really expose a first-class equivalent of:
over SSH in the same way WinRM remoting does.
So a Linux JEA implementation would likely need one of:
Would you need multiple SSH listeners?
No, not necessarily.
One
sshdinstance can already handle:through
Matchrules andauthorized_keysoptions.I would only introduce separate SSH listeners/ports if I wanted completely separate security boundaries, such as:
but from a purely technical standpoint, that's not required.
Honestly, if someone proposed Linux JEA to the PowerShell committee, I'd argue the MVP should piggy-back on SSH's existing capability to select a command based on the authenticated identity or key. OpenSSH has already solved most of the endpoint-routing problem; PowerShell would mainly need to provide the constrained runspace once the user lands in
pwsh.Summary
It's technically doable, but is there enough desire in having this feature?
Also, we have to be mindful of being able to support this if it were to be implemented too.
It definitely feels like a "very nice to have" but without any data (that I know of - which may well exist) about how widespread JEA has been used in orgs in Windows environments already.
JEA is definitely one of those features that I personally heard less around implementations of it than I expected, which actually could have tied in with me having multiple periods of time out from the community so missing those discussions, however I think that at least in the UK the sort of orgs that likely did implement this would in many cases not have publicly discussed them doing so anyway.
I don't personally see how this could be implemented outside of this repo, via the likes of a module, due to how interlinked it is to engine features and would need to be of very high quality for this to be accepted as a community PR and definitely would need a predefined feature set to look at implementing PRIOR to any work being started on this.
soroshsabz commentedon Sep 28, 2026
I believe JEA on Linux is particularly important for appliance products whose administrative interface is based on PowerShell.
The requirement is not to make Linux behave like Windows or to replace SSH, Bash, or sudo. The requirement is to provide a supported, PowerShell-native authorization boundary for appliances that expose PowerShell as their management CLI.
Why SSH and Bash are not an equivalent
A Linux appliance may use SSH as its transport, but SSH by itself does not provide the administrative model required by an appliance CLI:
sudodelegates individual Linux executables or command lines, but it does not naturally express PowerShell command visibility, parameter constraints, validation, or PowerShell-specific roles.Linux has excellent building blocks for delegation, including sudo, doas, polkit, file permissions, systemd services, SELinux, AppArmor, containers, and SSH forced commands. However, these mechanisms do not provide a consistent PowerShell endpoint model for a PowerShell-based appliance.
Appliance-specific use case
Consider an appliance with the following operational roles:
The appliance should not need to expose:
Instead, it should expose a narrowly defined management surface such as:
The authorization boundary should be enforced by the endpoint, not by asking every client application or operator to invoke the correct script manually.
This is the same core problem that JEA addresses on Windows: reduce the exposed administrative surface, delegate only the required operations, provide role-based access, and preserve auditing.
Why this matters even when Linux already has
sudoAn appliance vendor can implement this using a combination of SSH,
sudo, wrapper scripts, and restricted shells. However, that leads to several problems:A cross-platform JEA model would allow the appliance to express its administrative contract in the same language as its management interface.
The goal is not to claim that JEA can replace every Linux security mechanism. Linux authorization primitives would still be required underneath the endpoint. The goal is to provide a PowerShell-aware policy and execution layer that integrates with those primitives.
Important design requirement
A Linux implementation should not simply run a restricted PowerShell script over a normal SSH session. That would be insufficient if the user can also obtain Bash, start another PowerShell process, execute unrestricted native commands, or modify the scripts used by the endpoint.
A useful Linux design would need to define at least:
The privilege model also needs to be explicit. In some cases, the PowerShell process may need to run with a service account that has narrowly scoped Linux capabilities. In other cases, a command may invoke a privileged helper through sudo, systemd, polkit, or a dedicated daemon. That decision should be part of the endpoint policy and appliance architecture, rather than an implicit consequence of the operator having a shell.
Suggested scope for the investigation
I would suggest treating this as a cross-platform administrative endpoint design problem, with the following questions:
The outcome may show that some scenarios are best solved with existing Linux tools and documentation. That would still be valuable. However, for appliances whose primary CLI is PowerShell, the investigation should also evaluate whether Linux currently has a supported way to expose a restricted PowerShell administrative endpoint. At present, SSH-based PowerShell remoting is primarily a basic remoting mechanism; it does not provide the same remote endpoint configuration and JEA experience available on Windows.
Proposal
I recommend reopening the issue, but with a design-first scope rather than immediately accepting an implementation.
The deliverable could be a design document or prototype defining:
This would benefit both Linux appliances and Windows. A consistent, cross-platform constrained administration model would allow vendors to build one PowerShell-based management experience while still respecting the security model of each operating system.
For PowerShell-based appliances, this is not merely a convenience feature. It is part of the security boundary of the product. Without it, vendors must either expose a broader shell than intended or build and maintain their own collection of SSH restrictions, wrapper commands,
sudorules, privileged helpers, and auditing mechanisms. A supported JEA model would reduce that duplication and provide customers with a security model they can understand, review, and audit.soroshsabz commentedon Oct 2, 2026
Ryan Yates (@kilasuit) Can I more help?
thanks
soroshsabz commentedon Oct 7, 2026
Thomas Lee (@doctordns) How can I help to make clarity over to design?
soroshsabz commentedon Oct 8, 2026
soroshsabz commentedon Oct 19, 2026
Ryan Yates (@kilasuit) Can I help any further?
I need this feature for Linux
soroshsabz commentedon Oct 29, 2026
Any update?
soroshsabz commentedon Oct 29, 2026
Do you want I implement one PoC?
doctordns commentedon Oct 29, 2026
For me, a more detailed investigation, based on the headings above, would be useful before we start creating code. The suggested scope seems comprehensive to me. Lets see the results and then move oin?
soroshsabz commentedon Oct 29, 2026
Thomas Lee (@doctordns) Would you like help drafting that investigation document? I could outline it section by section, mapping each heading to the relevant code in this repo (e.g., InitialSessionStateProvider.cs, SSH remoting code paths) so the design is grounded in what actually exists today.
doctordns commentedon Oct 30, 2026
soroshsabz Thanks for the offer! ;-) As an old retired guy with literally zero Linux skills, I am not sure I'm the right person to help specify JEA V2, aka JEA on Linux/Mac. But some thoughts:
Let's start at the beginning: JEA handles three things:
So, for me, the overall objective should be twofold: to bring JEA V1 functionality to Linux/Mac and to improve the overall JEA feature for Windows.
Managing who connects will obviously be different in Linux using SSL; I don't have the skills to say how connection authorisation would work. But it seems reasonable to assume it should be defined in a session control file. This document probably needs some improvements to handle connecting over SSL.
The current JEA on Windows seems to do an OK job managing the commands someone can run. So I suspect role capability definition files should easily handle restricting PowerShell cmdlets running in a JEA remote session. But I think we still need to work on how to manage and restrict more complex Linux commands. Linux commands can have much more complex and cryptic arguments whose use it may be appropriate to manage via JEA.
I do not know enough about privilege in Linux to speak to how privilege can be managed on Linux.
I would also like to see more AD integration (ie on Windows). I'd like to be able to push the JEA definition files via Group Policy. And while it may be more appropriate for DSC to deal with, should there be some way to push modules to a server which a JEA endpoint may need to utilise?).
I have a suggestion: create a new repo and begin to develop the JEA V2 definition there. Once the definition is complete, we can work on how to implement it.
soroshsabz commentedon Oct 31, 2026
Thomas Lee (@doctordns) thanks for your reply
As you say, I submit RFC draft PR in PowerShell/PowerShell-RFC#420