As mentioned in previous post, the time has come to install proper development tools on every environment that I used. And so I had my first chance to use OpenSSH Beta on Windows.
While installation is rather simple (and does not require to reboot computer — looks like Microsoft is finally learning something from *nix Systems), for configuration there were some surprises for me. See the post details to read more about it!
How to get it?
Installation is rather simple, and as it is provided on the Microsoft official blog, I won’t describe the set-up here as well. Of course main requirement is to have Windows 10 Fall Creator’s Update installed (which you should do, as not keeping your software up to date is one of the worst practices that you could do).
How to use it?
Now that was my first surprise. After installing OpenSSH Beta Client, I have received access to following commands: scp, sftp, ssh, ssh-add, ssh-agent, ssh-keygen. Turned out I had much more tools that I expected — anything except for ssh and perhaps ssh-keygen was a surprise for me. After all, we are talking about Microsoft and beta release.
And I didn’t had to bother about setting up PATH at all. Everything was done for me already, and I was able to run those commands using cmd.exe, Powershell.exe and even custom command prompts from Visual Studio.
One command to connect to them all
I have it installed, now it is time to connect to some of my servers. So of course I ran ssh-keygen and generated new keys for authentication. As it turned out (what you can also read in the blog post with instalation) you need to use Start-Service ssh-agent to create service for SSH support. And after this only you can use ssh-add to add generated key. So I did just that and tried to connect to some servers that I used… And then this happened:
As it turned out, by default current version of OpenSSH on Windows by default uses ed25519 algorithm for generating keys. That was something new for me, as I was expected to use RSA as I always did on my Linux servers. But my servers also weren’t expecting them, as both the first one (Debian Jessie) and second (CentOS 7) didn’t offer support for that key.
RSA? Never heard about it.
So I should simply change the type of a key during ssh-keygen call, right? After all when I write ssh-keygen — help on my command line, I receive following output:
PS C:\Users\Michał> ssh-keygen — help unknown option — — usage: ssh-keygen [-q] [-b bits] [-t dsa | ecdsa | ed25519 | rsa] [-N new_passphrase] [-C comment] [-f output_keyfile]
PS C:\Users\Michał> ssh-keygen — help
usage: ssh-keygen [-q] [-b bits] [-t dsa | ecdsa | ed25519 | rsa]
[-N new_passphrase] [-C comment] [-f output_keyfile]
So let’s get down to it!
PS C:\Users\Michał> ssh-keygen -t rsa
unknown key type rsa
Now that is a surprise.
As it turned out, RSA is not yet implemented in OpenSSH Beta for Windows — you can check it on GitHub issue tracker of OpenSSH Windows project. It will be deployed with next release (approx April, based on one of the posts). But we can always use newest possible version from Repo (18.104.22.168-beta was latest while this blog post was written) to get RSA functionality working back. And then hopefully I can somehow connect to my servers.
ssh-add for RSA key that I had didn’t work as well. Not yet supported.
Just a quick info: while doing everything that was written in this blog post I had my private key available, but without access to any other computer/OS from which I was able to run instantly SSH — and using a Virtual Machine with some Linux was TOO EASY, SO WHY DON’T WE TRY SOMETHING HARDER INSTEAD? And then the only decision would be if I wanted to update OpenSSH on servers or do something weird on my Windows machine, so that would be no fun.
I only need to replace files in the folder, right?
So I downloaded latest version as a .zip archive and unzipped it locally. Once again I was greeted by the same applications that was installed with OpenSSH function. Even more, as function install splitted OpenSSH into Server and Client packages, and here I received everything at once. So now I should just replace those files in my C:\Windows\System32\OpenSSH directory and everything should work.
Unless you don’t have admin rights. Or you have them, but then after confirming that you want to do operation that requires admin rights Windows throws you an error with information that you don’t posses required rights to change those files. And default OpenSSH installation doesn’t contain sudo mv command, so bad luck for me.
So my only solution was to keep them in some other directory and overwrite the PATH to get the OpenSSH version that I expected. And then by magic everything started working.
So unless you keep all your OpenSSH servers up to date — Kids, don’t do OpenSSH on Windows. Just yet, wait until we get Beta 1.0 as out-of-box solution.
Originally published at www.blog.smyk.it on February 23, 2018.