Without thinking it too much, I just went for a SSH-connection on a Windows 10 box with the way it's typically done:
ssh -i .ssh/id_nistp521 user@linux-box
When the result was not a private key passphrase question, but a: Bad owner or permissions on .ssh/config, I started thinking about it. What! What? Why! It worked earlier, why won't it anymore?
For the record:
I am an avid Cygwin user. So, I get a very very Linuxish experience also on my Windows-boxes. So, don't be confused with the rest of the story. This is on a Windows 10, even if it doesn't appear to be so.
Back to the failure. I started poking around the permissions. SSH-clients are picky on private key permissions (also config file), so I thought that something was going on. Doing a ls -l:
-rw------- 1 jari None 547 Nov 12 17:25 config
-rw------- 1 jari None 444 Jul 15 2017 id_nistp521
Nope. Nothing wrong with that. Still, something HAD to be wrong, as this wasn't acceptable for the client. Doing a which ssh gave it away. I was expecting to see /usr/bin/ssh, not /cygdrive/c/Windows/System32/OpenSSH/ssh!!
So, who put an OpenSSH client to my Windows-directory? Why? When? What kind of sorcery is that? Environment variables:
Yes, there is a PATH-entry for OpenSSH before Cygwin. In the directory, there is a full set of OpenSSH-tools:
Version is 7.6:
OpenSSH_for_Windows_7.6p1, LibreSSL 2.6.4
The expected version in Cygwin is 7.9:
OpenSSH_7.9p1, OpenSSL 1.0.2p 14 Aug 2018
So, to fix this, I yanked the PATH-entry away. Now my SSH-connections worked as expected.