Ever since the days of Windows Server 2012, Microsoft has enabled PowerShell remoting by default within its operating systems. This means that an authorized administrator is able to establish a PowerShell session with the machine and manage it from elsewhere. While having the ability to use PowerShell to remotely manage a VM is certainly convenient, you might be able to make your network just a little bit more secure by turning off PowerShell remoting for your Hyper-V virtual machines. You will still be able to use PowerShell remoting to manage your VMs, you will just force the bad guys to jump through a few extra hoops.
So before I show you how this technique works, there are a couple of things that you need to know. First, having PowerShell remoting enabled does not make your VMs inherently insecure. After all, PowerShell remoting is enabled by default. Nobody can remotely manage your VMs unless they know the administrative credentials.
The second thing that you need to know is that the technique that I am about to show you is only suitable for use with relatively small Hyper-V deployments. The reason for this is that the technique that I am about to show you requires you to know which Hyper-V host the VM that you want to manage resides on. In larger organizations, VMs tend to be live migrated from one Hyper-V host to another on a regular basis, so it can be difficult to know which host is currently running a particular VM unless you have System Center Virtual Machine Manager. Incidentally, I recently wrote a separate article explaining how to use PowerShell to figure out which Hyper-V host is running a particular virtual machine.
How to take advantage of PowerShell Direct
So with that said, the trick behind disabling PowerShell remoting, and yet still being able to manage the VM through PowerShell is to take advantage of a Windows Server feature called PowerShell Direct. PowerShell Direct was introduced in Windows Server 2016, and allows you to use PowerShell commands to manage a Hyper-V virtual machine from the host operating system. The cool thing about this technique is that because PowerShell is being run on the Hyper-V host, it completely bypasses the VM’s network stack. You can manage virtual machines from PowerShell regardless of whether or not remote management is enabled, and regardless of how the VM’s firewall is configured. The only caveat is that this only works for VMs that are running on the same host that you are running PowerShell on – well, sort of.
As we all know, most servers do not have dedicated keyboards, mice, and monitors. The days of walking into the datacenter and sitting down at the server console to perform a management task are long gone. That’s OK, though. You can still take advantage of PowerShell Direct, even if you are sitting at your own desk. The trick is to establish a PowerShell remote session with the Hyper-V server, and then use PowerShell Direct to connect to the VM. That’s why you have to know which host the VM is running on.
So let’s take a look at how this works in real life. Earlier today, I set up a Windows 10 virtual machine named Win10-1803. This VM is running on a Hyper-V server named Hyper-V-4. So with that said, the first thing that I am going to do is to disable PowerShell remoting on the virtual machine. To do so, I am logging into the VM directly, and entering the Disable-PSRemoting cmdlet, as shown in the screenshot below.
Once I disabled PowerShell remoting, I attempted to establish a PowerShell session to the VM by using these commands:
$Cred=Get-Credential $Session = New-PSSession -ComputerName Win10-1803 -Credential $Cred
As you can see in the next screenshot, the connection failed, as would be expected.
With PowerShell Remoting disabled I was unable to establish a PowerShell session to the VM.
So now let’s take a look at how to establish PowerShell connectivity using PowerShell Direct. The one thing that you need to know about what I am about to show you is that each of the machines involved is joined to a common domain.
So with that said, the first step in the process is to establish a PowerShell session to the Hyper-V server, which in my case is called Hyper-V 4. To do this, I am going to use exactly the same commands as a moment ago, except that I am using Hyper-V-4 as the computer name. I am also using the Enter-PSSession cmdlet to establish the session. Here are the commands:
$Cred=Get-Credential $Session = New-PSSession -ComputerName Hyper-V-4 -Credential $Cred Enter-PSSession $Session
As you can see in the next figure, I have connected to the remote Hyper-V server.
Now it’s time to work with the VM. Since I don’t have a real management task to perform at the moment, let’s do something simple such as listing the processes that are running within the VM. Here is the command that I would use to do so:
Invoke-Command -VMName Win10-1803 -ScriptBlock {Get-Process}
As you can see, I am using the Invoke-Command cmdlet, and then specifying the name of the virtual machine. Any commands that I include in the script block are executed on the virtual machine. In case you are wondering, when I execute this command, PowerShell does prompt me to enter credentials for the VM. As you can see in the screenshot below, however, I was able to get the virtual machine’s process list, even though PowerShell remoting is disabled.
Test before disabling PowerShell remoting
Disabling PowerShell remoting can potentially make your virtual machines a bit more secure. Even so, I recommend testing this technique out in a lab environment before you try it in production. If you have scripts or applications that depend on PowerShell remoting, then disabling PowerShell remoting will cause problems. It is also worth mentioning that the Disable-PSRemoting cmdlet behaves slightly differently depending on which version of PowerShell you are using. Those differences are listed in the notes section of Microsoft’s Disable-PSRemoting documentation.
Featured image: Pixabay
