The PowerShell Team at Microsoft have put in a lot of work to port PowerShell to other (non-Windows) systems. As part of their porting efforts, they’ve also ported OpenSSH over to Windows, but that’s not what this post is about.
I manage a number of client tenancies hosted on Microsoft Office 365. While the web based admin console is continually being improved, occasionally I come across a task that I need to perform and the only way to do it is via PowerShell.
The team writing PowerShell are not long-time Mac experts (by their own admission) and one of the decisions they made early on in the development process was to use the Homebrew package manager instead of, say, MacPorts. The PowerShell software needs to use OpenSSH libraries to communicate with remote hosts (e.g. Office 365) and there are some hardcoded library paths in the software that reference the OpenSSH libraries installed by Homebrew.
While Homebrew is very popular, I will not use it on any systems that I manage because it changes the ownership of core system folders. This, IMHO, is not The Right Way™ to do things. Further, Homebrew explicitly does not support being run as root (e.g. via sudo) so you can’t fix the permissions and have Homebrew still work.
MacPorts is more of a traditional package manager – it doesn’t change system permissions and you need to be root to use it to install software on your system.
Fortunately, you can symlink the OpenSSH library location from MacPorts to where Homebrew puts it, and then PowerShell is quite happy to use it.
sudo ln -s /opt/local/lib /usr/local/opt/openssl/lib
Once you’ve done this, then PowerShell remote sessions should work as expected, e.g. via
$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection