Posh-SSH: driving remote Linux hosts from PowerShell

SSH.NET repackaged as cmdlets, not a new protocol

Posh-SSH is a PowerShell module that leverages a custom version of the SSH.NET library to provide SSH functionality inside PowerShell. That framing matters for what it is and is not. It is not an SSH server, and it does not replace the OpenSSH client on the machine. It is a managed .NET implementation of the client side, exposed as cmdlets, so that a script can open a session, run a command and read the output as objects rather than parsing console text. The stated purpose is automating actions against one or multiple SSH enabled Linux servers from a Windows host, and the module has been usable on Linux and macOS as well since version 3.x, through .NET Standard.

A version 4.0 release with a beta in front of it

The release history shows v4.0.0 on 2026-09-25, preceded by v4.0.0-beta2 on 2026-06-27 and v3.2.7 on 2025-11-10. A major version bump in a module of this kind is a compatibility event rather than a cosmetic one, because the underlying library and the cmdlet surface both move together. The last push to the repository was on 2026-09-19, a few days before the 4.0.0 tag, so the release came straight out of that work. For a team that scripted against 3.x, the sensible approach is to run the existing scripts against 4.0.0 in a test environment first, since the README does not enumerate breaking changes and the CHANGELOG.md in the repository root is where that detail lives.

Sessions, SFTP and SCP are the three things you will actually call

The support section lists the functional surface: automating SSH, SFTP and SCP actions, proxy support over SOCKS4, SOCKS5 and HTTP, and remote, dynamic and local port forwarding. The README also links video tutorials for each area, which tells you the intended workflow: creating and managing sessions, managing known hosts, and executing commands. The known hosts topic is the interesting one for security, because it is where host key verification lives, and the module's own repository includes a specs/ directory and a tests/ directory, so the behaviour is at least specified somewhere even if the README does not detail the cmdlet names. Anyone coming from OpenSSH will recognise the concepts, though the parameter names will differ.

The crypto support list is long, and the ciphers are old

The README enumerates supported algorithms in full, and that list is a good guide to the library it embeds. The ciphers include the aes-ctr family in 128, 192 and 256 bit forms, the matching CBC variants, 3des-cbc, blowfish-cbc and the twofish variants, plus arcfour and cast128-cbc. The key exchange list spans curve25519-sha256, the ecdh-sha2-nistp curves, several diffie-hellman-group-exchange and diffie-hellman-group entries, and the older group1-sha1. The MAC list includes hmac-sha2-256 and hmac-sha2-512, their truncated and etm variants, and the legacy hmac-sha1 and hmac-md5 families. Host key algorithms cover ssh-ed25519, the three ecdsa curves, rsa-sha2-512 and rsa-sha2-256, plus ssh-rsa and ssh-dss. The breadth means it can talk to old and new servers, and it also means the module will happily negotiate algorithms a modern hardening policy would have retired.

Key formats are well covered, including the encrypted private key ciphers

The private key support is the more practical half of the crypto list. RSA is accepted in OpenSSL PEM format, marked by a BEGIN RSA PRIVATE KEY header, and in ssh.com format with a BEGIN SSH2 ENCRYPTED PRIVATE KEY header. DSA is accepted in the same two formats. ECDSA at 256, 384 and 521 bits is accepted in OpenSSL PEM format with a BEGIN EC PRIVATE KEY header, and ECDSA, ED25519 and RSA are accepted in the OpenSSH key format marked by a BEGIN OPENSSH PRIVATE KEY header. For keys that carry a passphrase, the module supports DES-EDE3-CBC, DES-EDE3-CFB, DES-CBC and AES in 128, 192 and 256 bit CBC. In practice that means a passphrase-protected key has to use one of those CBC ciphers to load without conversion.

Install is one cmdlet, and the platform floor is spelled out

Installation from the PowerShell Gallery is a single command.

Install-Module -Name Posh-SSH

The runtime requirements are specific. The module targets Windows PowerShell 5.1 or PowerShell 7.x, and on Windows Server version 1709 or older, .NET Framework 4.8 or above is required for the module to load properly. On Linux and macOS the module works through .NET Standard as of version 3.x, so the original Windows-centric design has been widened but not abandoned. The repository also contains Build-Module.ps1 and Publish-ToPSGallery.ps1, the build and publishing scripts, along with Invoke-DocumentationBuild.ps1, which indicates that the documentation is generated rather than hand-written for every release.

BSD-3-Clause with an explicit no-warranty notice

The licence is BSD-3-Clause, with the text in a file named License.md at the repository root. The README also reproduces an explicit warranty disclaimer, stating that all work product is provided as is and that the developer disclaims implied warranties including merchantability and fitness for a particular purpose. That is standard defensive language for a tool that automates changes on production hosts, and it pairs well with the licence: permissive enough to use inside commercial tooling, with no warranty attached to the outcomes of the commands it runs. Practically, it means the burden of testing a script against a real host before pointing it at production stays with you.

Where a native client or a cross-platform tool fits better

The realistic alternative is to call ssh and scp directly from PowerShell, or to use a cross-platform tool written in a single language for a mixed estate. The difference in approach is where the state lives. Posh-SSH keeps the session, the credentials and the key material inside a managed object, so a script can hold a session open across many commands and receive structured results, and it exposes port forwarding and proxying as parameters rather than as separate processes to wire up. Native OpenSSH gives you the reference implementation, the exact configuration file semantics of the system, and whatever your distribution ships, at the cost of text parsing and separate invocations. A team with Windows-only control over the targets will get more from Posh-SSH, and a team with a heterogeneous fleet and strong scripting conventions will often get further with the client that is already on every box.

Editorial conclusion

Posh-SSH is worth adopting for Windows administration where automation has to live in PowerShell, because sessions, key handling and file transfer become cmdlets that compose with the rest of a script instead of shelling out to a separate client. It is a poor fit where the target hosts are already reachable with a native OpenSSH client or where the team prefers a cross-platform tool written in one language, since the module's own history starts on Windows. Verify first that your target framework matches, with .NET Framework 4.8 or above on Windows Server 1709 or older and .NET Standard elsewhere, and confirm the cipher and key exchange algorithms your hardened servers still permit are in the supported lists.

Frequently asked questions

Official sources

1. darkoperator/Posh-SSH on GitHub
2. Issues
3. License: BSD-3-Clause
4. README
5. Releases