EVERYTHING About PowerShell Remoting

This article contains the video notes that goes with the video https://youtu.be/sg_9r0PHnnM which covers EVERYTHING you should know about PowerShell Remoting.

In order to avoid that the contents of this article looks random, I will recomend you watch the video related to this article FIRST!

IF you already come from the youtube video, first of all THANK YOU SO MUCH for watching it. I spend SO MUCH time preparing that video, that every single view on that video feels like a whole stadium looked at it. Thanks!

Second, you should be able to find the contents I mention in the article in order they appear in the video.

This article might evolve / change over time to complete or add details to the video that the community might would like to see. So, don’t hesitate to subscribe to the blog too, and come back here once in a while to see if thinks have changed.

 

List of PowerShell cmdlets that have Built-In remoting support in PowerShell 5.1 (-ComputerName)

This is the list of PowerShell cmdlets that have built-in remoting capabilities on Windows Powershell (Powershell 5.1)

List of PowerShell cmdlets that have Built-In remoting support in PowerShell 6.X and above (-ComputerName)

The following list contain the PowerShell cmdlets that contain built-in PowerShell remoting capabilities in PowerShell 6.X (PowerShell Core) and above.

It is easy to measure how many PowerShell cmdlets have built-in remoting support using the following Powershell Snippet:

In a nutshell, if the cmdlet has -ComputerName as a parameter, it has built-in PowerShell remoting capability.

The list is WAY shorter than the one in PowerShell 5.1. In PowerShell Core (also known as PowerShell 7+), the -ComputerName parameter is not as prevalent as in Windows PowerShell because PowerShell Core emphasizes cross-platform compatibility and uses PowerShell Remoting (via SSH) or WinRM for remote management, rather than relying on the -ComputerName parameter. As a result, many cmdlets that had -ComputerName in Windows PowerShell do not include it in PowerShell Core.

In PowerShell Core, most of the remoting functionalities are handled through the *-Session cmdlets such as:

  • Invoke-Command
  • Enter-PsSession
  • New-PsSession

For more details on these cmdlets, I invite you to watch my video here

Why is there a difference between the cmdelts in PowerShell 5.1 and Powershell Core in the first place?

Many cmdlets like Get-Process or Get-Service, which used to have -ComputerName in Windows PowerShell, no longer support it in PowerShell Core. The reason is that PowerShell Core was designed to be more modular and platform-independent, focusing on remote management through protocols like SSH or WinRM.

How to change the network profile type to domain / private

List the network card name (alias)

 

Get the current network connection profile

 

How to change the network profile to type Public using powershell

Use the following snippet to change the network profile to type public.

How to change the network profile to type Domain using powershell

If instead you want to change it to the type Domain use the below snippet:

Working with WinRm listeners:

Listing existing WinRM Listeners

List the existing WinRM listeners using the following WinRM command:

 

Creating a new WinRm Listener on Https

Use the following snippet to create a HTTPS WinRM listener

It is also possible to create an HTTPS listener using New-Item and the WSMAN: drive

Removing non used http WinRm Listeners

Creating a new self signed certificate:

Use the following line in order to create a new selfsigned certificate on a Windows Machine.

Creating a session option to skip the CA check

In most cases, the default options for a Remote session will be exactly the ones you need to connect. In some more rare cases, it might not be the case. For that you have the possibility to create a session option, which you can add to your session when you are establishing the connection.

The example I used in my video, is to bypass the CA verification check for a self signed certificate.

Note: This is a BAD IDEA to do this in production, as you are REDUCING the security of your connection. Do this ONLY when it makes sense.

List the currently open connections on a machine

In order to check current open tcp connections, use the following command:

Working with Trusted hosts

List the contents of the trusted hosts

Add a system to the trusted host list:

Remove / clear the trusted host list

Working with PowerShell and OpenSSH

Get state of OpenSSH installation

Install the OpenSSH Client

Change the OpenSSH service to Automatic

This will create a bunch of config files in C:\programData\ssh

Configure Firewall for OpenSSH

Uninstall the OpenSSH Client

Uninstall the OpenSSH Server

Change the default SSH prompt to Powershell

Set the

Add the OpenSSH subsystem

Add the following line under the substem part of your sshd.config file

The default location of the PowerShell executable is c:/progra~1/powershell/7/pwsh.exe. The location can vary depending on how you installed PowerShell.

You must use the 8.3 short name for any file paths that contain spaces. There’s a bug in OpenSSH for Windows that prevents spaces from working in subsystem executable paths. For more information, see this GitHub issue.

The 8.3 short name for the Program Files folder in Windows is usually Progra~1. However, you can use the following command to make sure using the follwing command

Generate SSH keys

Simply use the following executable:

Give administrator access:

Copy the contents of the public key to administrator_known_hosts.pub

Make sure that only the administrator and the system account have access to this file.

Powershell over SSH on Linux systems

Install the openSSH client

Install the OpenSSH server on Linux

Configure the poweshell subsystem

Open the ssd_config file with VIM using the following line

Search for the ‘subsystems’ section, and add the following line beneath the existing subsystem.

Un comment password authentication (make sure it is set to yes)

Restart the sshd deamon

After that, you can use the regular *-PsSession cmdlets to create, use remove the session.