Jordan Borean

What did the French ever do to you to have you avoid them like that?

New PowerShell module out :)
ISpy, using ILSpy's decompiler library.

github.com/trackd/ISpy/
www.powershellgallery.com/packages/ISpy/

Kerberos delegation is possible but setting up constrained delegation only works for specific scenarios while others just won't work without using unconstrained delegation. E.g. SMB works but things where the auth originates in process won't (MS SQL auth, etc).

Also while I definitely don't encourage password auth it's a bit trickier on Windows as it's currently one of the few ways to get delegation working through SSH. It's essentially the CredSSP equivalent and while delegation is always a security risk sometimes people will accept that. ...

Tmds.Ssh/examples/azure_key/AzureKeyCredential.cs at main · tmds/Tmds.Ssh .NET SSH client library. Contribute to tmds/Tmds.Ssh development by creating an account on GitHub.

Yep Tmds.Ssh supports both ssh-agent and key-bound containers. For example here is one I wrote where the key can be stored in an Azure KeyVault HSM with the signing operation done by the Azure API without the key leaving the vault github.com/tmds/Tmds.Ss....

Nice, I’ve been wondering whether I should just have a base class or source generator that can generate the new-pssession and invoke-command boilerplate. That way transport authors can just worry about the transport bits instead of reinventing the wheel all the time.

Yep this will be the best way forward even if it isn’t ideal.

Unfortunately I had a look and BouncyCastle seemed to be the least worst option at the time when I added ED25519 key support. Seems like some more things now to use BC now as well. In saying that the problem probably isn't the BC dep but supporting the whole SSH client that the pwsh team won't like.

Heh I forgot I even added an example github.com/tmds/Tmds.Ss... - no idea if it still works.

In memory key support · Issue #205 · tmds/Tmds.Ssh Right now the only way to use a key file is to specify the filepath of the key. It would be great to support a key that is either specified as a string or with the PrivateKey type itself. The latte...

Yea the server side is just a whole other kettle of fish. Glad Tmds.Ssh is working for the client side. One thing I really wanted to support in the SSHForge that used it was the ability to use a key stored in Azure KeyVault. I even implemented what was needed in Tmds.Ssh github.com/tmds/Tmds.Ss...

What library did you end up using for the SSH transport side?

Thanks will have a look through. There’s just so many extensions to Kerberos that it’s very difficult to see what is MS specific, what is actually required, what can be slipped, etc.

Does anyone know of an up to date article that talks through the content of the Kerberos AS and TGS req/resp messages. I can read through the RFCs, MS-KILE, and inspect the network traffic but I'm hoping for a nice up to date guide on the various PAData values and what/when they are used/required.

Make me think, you could open up a local socket, start a remote process through winrm, have that connect to the local socket and exchange data through that. It bypasses the WSMan layer, only requires outbound access on the remote. Probably more trouble than its worth though.

The transport API is only the stdio packets you see with SSH. The WSMan layer uses a completely separate API which is not public and is designed specifically for WSMan.

You can but it's horribly slow. WinRS (WinRM with process IO) has a delay in the stdout output so the chatty PSRP packets that are exchanged in the session setup and creating the pipe take too long. I tried this with PSWSMan when it turned out hooking wouldn't work on arm64 (at the time).

SSH based PSRemoting only really solves the transport complications with WSMan. It does nothing to improve both the PSRemoting side (running interactive executables doesn't work), and the client side implementation (Enter-PSSession/Invoke-Command) is a complicated mess.

Come back to me when Enter-PSSession can actually meet what ssh does. SSH can emit anything, including CLIXML which is how Invoke-Command over SSH works today. PSRemoting is dead outside of non-scripted scenarios. It is subpar in pretty much every way when it comes to interactive scenarios.

You can always just ignore it, no pressure at all :). I know there are a few things I would do differently and is part of the reason why I haven't finished it off (yet)

CLIXML isn't simple (just look at the 3rd party impls that do basic WinRS vs PSRP. WSMan auth isn't simple outside of the blessed MS realm, Has so many features that no one knows exists (try reading MS-WSMV).

Honestly I think it can all be summed up to overengineering. SSH can be complicated but it's essentially stdio over some pipes with a pretty dead simple authentication mechanism. That makes it flexible for so many scenarios and the authentication is simple for the user to use out of the box.

SSHForge/src/SSHForge/HvcInfo.cs at main · jborean93/SSHForge Hyper-V implementaiton for PowerShell RemoteForge. Contribute to jborean93/SSHForge development by creating an account on GitHub.

If you ever need any inspiration then have a look at that RemoteForge stuff. It was my attempt at trying to make a nicer API but I never completed it. The goal was to make a transport as simple as github.com/jborean93/SS.... Then the forge cmdlets can do Invoke-Remote hvc://something { … }

It can be done, the trick is getting the pwsh team to care about it at all. Right now it's just a tick in the box, I don't even know if anyone is in charge of that part of the codebase anymore. The PSRemoting internals is also a rube goldberg machine that is just too hard to understand.

HTTP/S is the way sounds like the thinking that produced WSMan. SSH is the future even if it's an old tool. It's ubiquitous, implemented in most platforms, and is good enough for these use cases. Best of all it is being constantly updated to support newer features, including security improvements.

RemoteForge/src/RemoteForge/Commands/InvokeRemoteCommand.cs at main · jborean93/RemoteForge PowerShell Custom PSRemoting Transport Manager. Contribute to jborean93/RemoteForge development by creating an account on GitHub.

Implementing your own Invoke-Command is possible but you need to do it all manually, an example of that is at github.com/jborean93/Re... and even then maybe I've gotten something wrong. That also doesn't solve the issue is that people don't care about anything outside of what's builtin.

Sure but doing

$session = New-CustomPSSession ...
Invoke-Command -Session $session { ... }
$session | Remove-PSSession

Is just horrible compared to Invoke-Command host1 { ... }. It also is really complicated to get the fan-out happening in parallel.

The main things that prevent you is ease of use of getting users to actually find/use your code. I find the beauty of PSRemoting comes from how simple it can be to use Invoke-Command and have that fan-out and manage the session. Now you need to implement all that yourself which is not fun.

GitHub - tmds/Tmds.Ssh: .NET SSH client library .NET SSH client library. Contribute to tmds/Tmds.Ssh development by creating an account on GitHub.

Would love to see something like moving to github.com/tmds/Tmds.Ssh but I understand the support concerns. Even then there's so much more that can be done to make wrapping the ssh CLI so much nicer in PowerShell (prompting, password auth, etc).

I've been majorly disappointed with the PSRemoting stuff. There is an API you can use to create your own transports but it's annoying to use and no one cares about using anything outside of PowerShell. Then there's the whole SSH is the future but our builtin impl is stuck in time and no PRs thanks.

PSConfEU-2025-Solo/ALC/1-Problem-AssemblyConflicts.Tests.ps1 at main · jborean93/PSConfEU-2025-Solo Contribute to jborean93/PSConfEU-2025-Solo development by creating an account on GitHub.

In my talk last year I used dbatools and the old MSAL auth module github.com/jborean93/PS.... MSAL.PS isn’t really something people use these days though.