Introduction and broad statements

To a Windows novice like me, Powershell appears to be the real way to get things done on Windows machines. Since I am only familiar with the string-oriented way in which bash, sh, and other Unix shells work, it has been an interesting experience learning some basic Powershell concepts.

For example, as opposed to the command line arguments being passed as just strings, it seems that there is some further processing and object-orientation that goes on in the form of Powershell parameters.

Another thing is that the cmdlets that Powershell uses to execute commands appear to be dlls. It seems like Powershell is able to load shared objects on the fly and let you directly pass arguments to them and whatnot. While there may be some projects to make this doable with bash as well that I’ve come across (for example, this ctypes.sh project), it seems very much the standard /modus operandi/ her with Powershell.

In any case, interfacing with Windows machines is something I do at work primarily when communicating with Active Directory to set up new systems with authentication. I would love to work with OpenLDAP or some other non-Microsoft alternative to see how other directory systems tick, but so far my career has had me interfacing strictly with Active Directory as a directory service provider.

Since work has provided me with a Mac for home use, that is where most of my work is done, and thus where the need to have remote Powershell access becomes useful. While the Microsoft Remote Desktop application from the App Store works just fine, it’s a bit overkill when I would just like to quickly develop and run scripts. The extra baggage and lag of a whole graphical desktop being streamed over (even through what I’ve heard is a great protocol like RDP) the web is unnecessary.

Without further ado, let’s get OpenSSH set up for Windows.

Installing OpenSSH on Windows

The main instructions for installing OpenSSH for Windows rightly come from Microsoft on this page here, and I reckon that works fantastic if you indeed have a Windows 10 version greater than Windows 10 1809, but alas, this desktop I have is running Windows 10 1709.

Finding the link for downloading the OpenSSH installer wasn’t the most straightforward in my case, so I have decided to include the link here for others and future me.

Modifying OpenSSH configuration

After installing the previous package, I had some issues finding C:\ProgramData\ssh where the configuration and log files wind up. Instead, I endeavored to load the sshd_config file from a different location by passing additional parameters to the sshd.exe binary. I took the circuitous route of modifying the ImagePath register under Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\sshd, as it appears there is no way to add Start Parameters to a service via the GUI. After adding a few flags to listen on different ports, read the out-of-place configuration file, and log to a file of my choosing, it looks like we are good to go.

What subsystem should Windows run for users over SSH?

It seems that Powershell support for remoting over SSH was added in the last major version or so. The default Powershell version on my machine for some reason was rather old—in the fifth major release—whereas Powershell 7 was out and about at the time of this post.

PS C:\Users\strackd> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.16299.1146
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.16299.1146
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3

So, I had to grab a later version of Powershell in order for the pwsh.exe binary to support the -sshs flag which makes remoting over SSH tick.

Where should sshd look for authorized_keys?

I am not quite sure my issue here, and I’d like to revisit this in a few days. It seems that sshd was throwing some errors regarding the process being unable to read the C:\ProgramData\ssh\administrators_authorized_keys file. Commenting the following lines from the config allowed the process to read from C:\Users\strackd\.ssh\authorized_keys instead of failing on reading the above.

Match Group administrators
       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

Kerberos (?) and Powershell

I am unsure why, but when using a key to Powershell, all of the Active Directory commandlets appear to be unauthorized to talk with AD. Having the Enter-PSSession prompt for a password works fine, but there is some issue when using public key authentication. I would like to investigate this further and understand why I’m having this issue.