Modernising Secure Command-Line Access: From PSM for SSH to CyberArk Secure Infrastructure Access
1. Introduction
Back in 2022 at the CyberArk Impact conference in Boston, I delivered a “PSM for SSH for Windows” presentation making a case for using the CyberArk PSM for SSH component to secure native PowerShell console access in Windows environments. The reason for this was that Windows Administrators need command line access too, and this is something that is not going to change anytime soon.
As the presentation was not recorded, we’ll revisit the core ideas from that session and explore how the landscape has now evolved to allow modern approaches and practices using CyberArk Secure Infrastructure Access (SIA), to simplify and modernise the approach today.
2. The Original Problem Space
For some time, a popular request around Privileged Access Management platforms has been to provide a way to publish PowerShell for use with credentials managed by the PAM solution.
For Privileged Access Management teams, the common approaches to providing a Windows administrator with the ability to use PowerShell in an environment have been:
1. Direct Console Access
This is the least secure method, allowing a user to use the console on their own machine, requiring either knowledge of the credentials they want their commands to run under the context of, or assignment of the required privileges to the account they are using to execute the PowerShell console.
2. A Custom PowerShell Connector
While somewhat secure, this requires a complex configuration and thoughtful administration, publishing the console on the session management servers of the Privileged Access Management solution
This approach is not recommended due to the risks around permitting use of a console running under the context of a powerful account on the Privileged Access Management infrastructure, which could be used to access and affect the PAM infrastructure itself.
3. Running a console on a Jump server connected to via RDP
This is the “least bad” option; users get an interactive shell but must work within an RDP session via the PAM session management component.
While the credentials are not exposed to the user, and the console is isolated and running on a remote system, the user experience is far from ideal.
PAM solutions have been able to add such protections for Unix administrators who connect using SSH, but secure, auditable access to command-line tools like PowerShell has posed a challenge for most organisations. Over the last 3 years, the same requests for PAM providers to support this functionality have collected more votes and more support.
In my presentation, I introduced the use of CyberArk's PSM for SSH, traditionally aimed at Unix and Network Administrators, as a cleaner and more secure option for Windows Administrators, allowing them to use a native PowerShell console on their local machine, which connects through the PAM solution to elevate privileges in an isolated session, all without exposing credentials to the user.
By taking advantage of the native SSH support now built into Windows, infrastructure exposure can be reduced while giving users what they want, a local PowerShell console, authenticated as a user with the appropriate permissions to perform their tasks in an isolated, recorded session, without exposing privileged credentials to the endpoint.
3. What's Changed
To protect the administration interfaces which exist in an environment, a PowerShell, or PWSH Proxy can be introduced in front of the interface. This is a Windows SSH server with its default shell set as PowerShell.
To connect to the PWSH Proxy server, in a CyberArk environment we can use Secure Infrastructure Access as an SSH Proxy to enable access using the command line console on a user’s local system.
Consider a segregated environment, with services split out into infrastructure tiers, accessed via Control or Management Planes in line with modern Privileged Access Enterprise Models. Where an end user’s workstation has no direct connectivity into the segregated infrastructure tiers, by using Secure Infrastructure Access it would be possible to allow a connection to the PWSH Proxy which can subsequently connect to the required administration interface.
For Windows Administrators who need secure access to privileged systems, using this method to connect with CyberArk Secure Infrastructure Access provides a native PowerShell experience with elevated access. Unlike traditional RDP or jump server methods, Using CyberArk SIA ensures credentials are never exposed to the user’s endpoint.
For compliance-driven enterprises who require session isolation and recording, using PowerShell via CyberArk SIA delivers fully audited, isolated command line console sessions. Unlike unmanaged remote access, it ensures traceability and accountability.
For enterprises seeking operational efficiency, CyberArk SIA reduces the need for separate infrastructure for Windows and Unix access. Unlike siloed tools, it consolidates access management under a single platform.
When compared to the previously available options, the benefits are clear:
- Unlike using PowerShell by connecting to a jump server target, a user does not have to RDP to invoke command line
- Unlike publishing PowerShell on a PAM session management server, users are not granted administrative command line access on the PAM infrastructure
- Unlike command line access from the desktop, credentials do not have to be retrieved or revealed to a user
4. PWSH Proxy Setup
Let’s dive into the detail on how you can get this setup and configured ready for use.
Let’s dive into the detail on how you can get this setup and configured ready for use.
On the server you will use as the PWSH Proxy (with PowerShell 7 installed), the first step is to install and configure OpenSSH Server:
Add-WindowsCapability -Online -Name OpenSSH.Server Once that process is complete and OpenSSH Server is reported as available, the sshd Service can be started:
Start-Service sshd By changing the as the default shell to PowerShell 7, when users connect via SSH they will be presented with a PowerShell console instead of CMD.
The following command sets the required default shell in the registry of the PWSH Proxy server:
New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Program Files\PowerShell\7\pwsh.exe" -PropertyType String -Force Finally, in order to use the CyberArk SIA zero standing privileges access capability, SIA authenticates to a target SSH service using an ephemeral certificate. The SIA public certificate can be obtained from your SIA tenant and trusted on the PWSH Proxy server by editing the sshd_config file.
An example entry to trust the SIA public certificate is shown below:
TrustedUserCAKeys C:/ProgramData/ssh/ca.pub The path to the certificate should be edited to match the file path and file name on your own server.
5. Using PowerShell via CyberArk Secure Infrastructure Access (SIA)
MFA Caching Access
As SIA will enforce the MFA policies assigned to a user for authentication to the CyberArk Identity Platform, it is possible to obtain a time limited ssh key which allows access to the SIA SSH Gateway.
We obtain the key for a user with the following command syntax:
sftp #@key@.ssh.cyberark.cloud:/key C:\Temp\Your_Key Now that we have obtained the MFA Caching Key, we can use it for our subsequent connections.
Vaulted Account Access
Without any further configuration in SIA, a user who has access to an account stored in the Privilege Cloud vault can use it to connect via SIA.
Connections with vaulted accounts for our example follow the following syntax:
ssh #@#@pwshproxy@.ssh.cyberark.cloud In the video, after authentication, we see a PowerShell console running under the profile of pwshuser1, an account vaulted in a Privilege Cloud safe. SIA has facilitated connection using the managed credential to the PWSH Proxy server for any further commands or admin activities the user may need to perform.
Zero Standing Privileges Access
A key differentiator of Secure Infrastructure Access is its ability to support zero standing privileged access. This means there does not have to be a vaulted account with existing access to the target we want to connect to.
To use ZSP with SIA for SSH access, we first need to set up a Recurring Access Policy in SIA.
For this demonstration I have created a simple policy which allows my user to connect to the PWSH Proxy server as the built-in local Administrator user.
To connect to the PWSH Proxy server via SIA using ZSP, we use the following syntax
ssh #@pwshproxy@yourtenant.ssh.cyberark.cloud As you can see in the video, using the ZSP connection string results in a session on the PWSH Proxy server under the context of the Administrator account.
This could be any local user on the target server, the recurring access policy just needs to be configured to allow assumption of the appropriate user context.
File Transfer from the PWSH Proxy Server
Using the methods demonstrated so far, it is foreseeable that a user may end up with some data or a file located on the PWSH Proxy server which they need to retrieve to their local machine.
SIA supports file transfer using SCP, the syntax for achieving this is shown below:
scp -i "C:\Temp\Your_Key" -o="user=#@pwshproxy" yourtenant.ssh.cyberark.cloud:C:\Path\To\RemoteFile.csv C:\DestinationPath\ The image above shows the “datareport.csv” file that we want to transfer to our local machine. Let’s see how we can achieve that.
As you can see in the video, users are able to transfer any data they need from the PWSH Proxy server via the SIA solution, staying in the command line without having to switch to another tool.
6. PowerShell via SIA vs PSM for SSH
Setting up SIA for SSH access to a Windows server via PowerShell is fast and straightforward. Once the SSH server is enabled vaulted credentials can be used immediately, and once the SIA certificate is trusted on the PWSH proxy host, zero standing privilege access can be used through an SIA recurring access policy.
In contrast, configuring PSM for SSH for Windows domain accounts requires several extra steps, including adding and customizing the PSMP-SSH connection component and handling domain-specific delimiters. While manageable, this introduces more complexity.
Both solutions are effective, but SIA stands out for its simplicity, speed, strong authentication options and ease of maintenance, making it a solid choice for modern, low-friction session management, and of course, all of the session data is recorded for review in the CyberArk Audit Service.
7. Conclusion
The original PSM for SSH approach was a great option in 2022. Today, with enhanced Windows SSH support and modern security tooling like CyberArk SIA, we can build even more secure, streamlined, and auditable command-line access paths for Windows admins. Whether you're managing traditional infrastructure or modern DevOps environments, the tools are ready to help you do more with less friction and greater control.
If you've been looking for a smart, streamlined way to give your Microsoft service administrators secure PowerShell access through your CyberArk setup, I hope this blog has given you a helpful starting point.
To explore this further, try setting this up in your test environment, or reach out to us at CyberIAM. We’d be happy to help you modernise your approach to Privileged Access Management using the latest tools and show how they can augment and integrate into your existing access strategy.
Get in touch
If you would like more information about CyberIAM’s Services offering, contact us here and a member of our specialised team will be in touch as soon as possible
Current State Assessment guide
Access our comprehensive current state assessment guide to discover how we initiate our end-to-end analysis, setting the foundation for providing you with the best possible advice.
