Pub Key Exchange Between Buster and Windows10

["Martin McCormick" <martin.m@suddenlink.net>]

	It was great news to find out that Windows10 includes an
openssh client and server and I got the Windows10 system and one
Debian Buster system to communicate via ssh/scp which is all
good.  The final step of getting them to connect via shared
public keys is good from the Windows box to the debian box but
not completely the other way around as in debian trying to log in to
Windows10.

	On the Windows box via powershell, I ran ssh-keygen -trsa
which gave the usual prompts for a passfrase and produced the
usual public and private keys in .ssh so I then  copied
id_rsa.pub from my .ssh directory on the Linux box to
authorized_keys on the Windows box after running it through
unix2dos to fix \n.

	I then ran dos2unix on the new Windows box's
.ssh/id_rsa.pub to make it suitable for unix and added it to
.ssh/authorized_keys.

	Both machines have each other's key in .ssh/known_hosts.
Here's what happens.

	Going from Windows to Linux, no password is needed to
remotely execute commands on the Linux system.  For some reason,
right now, if I try to execute Windows commands remotely from the
Linux box, I must always enter the password to the Windows box
and the command runs so the glass is 75% full.

	The Win10 box generated an id_rsa.pub key which is 404
bytes long.  The id_rsa.pub key I generated back in 2016 on the
Linux box is 395 bytes long.  Each files is one byte longer in
Windows because of the \n convention being 0x0d0a in Windows and
0x0a in unix.

	Any idea as to why the Windows box doesn't seem to accept
the Linux credentials?  When I do enter the password, everything
runs fine but I would rather not use the password in scripts on
one system that are running commands on the other.

	What I have got right now is usable but not right.  Any
constructive ideas are appreciated.

Thank you

Martin McCormick