This trick works for Linux servers and also if you are using WSL2 on Windows to run Ubuntu (or whatever *nix OS) and you are trying to utilize ssh keys with your ssh operations (rsync, ssh, SCP, etc), then you might come across the issue of ssh key having too open of permissions. Error message: WARNING: UNPROTECTED PRIVATE KEY FILE!. So you might try to chmod them to be correct permissions for example chmod 600 <yourkey>, however, you noticed that it didn’t fix the issue because the permissions remained the same. You can’t change the permissions as these might be sitting on a Windows partition (at least at the time of writing this, I couldn’t figure out how to change them). One option is to copy them to your Linux partitions like to your ~ directory. However, what if you don’t want to have multiple copies of your keys laying about. The problem with ssh is that there is no way to bypass this warning. It’s hardcoded into it. In this serverfault link you can see that actual part of the code. That link provides several workarounds, one is that you can rewrite that bit of the code to be ignored and recompile. However, that’s not a convenient option. Another option is to pretend sudo into nobody user and then ssh it. This tricks it into ignoring the too open permission.

So lets say you come across this error:

kostia@PC:/mnt/c/Users/Admin$ ssh -i /mnt/d/path/to/your/key/idrsa.openssh user@yourserver.com
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0666 for '/mnt/d/path/to/your/key/idrsa.openssh' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/mnt/d/path/to/your/key/idrsa.openssh": bad permissions
root@www.infotinks.com: Permission denied (publickey).

Per that serverfault page you, can use trick the system to ignore the permissions by running ssh thru the nobody user:

sudo -u nobody ssh -i <path to identity file> <ssh server>

With this fix you can connect, but it will complain about the authenticity of the host. You will need to type “yes” and hit Enter to get in, but you will get in

ssh -i /mnt/d/path/to/your/key/idrsa.openssh user@yourserver.com

Could not create directory ‘/nonexistent/.ssh’.
The authenticity of host ‘user@yourserver.com (1.2.3.4)’ can’t be established.
ECDSA key fingerprint is SHA256:QvEcr3Rm+Y8cD5sdfgsdfgsdfgjUuO+VFgUYMPlzBmAATg.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
yourserver:~# 

So now you can add the trick from this article, which I wrote a couple year back: http://www.infotinks.com/ignoring-ssh-authenticity-of-host

So with the final command, you can bypass having to type “yes” and Enter.

sudo -u nobody ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -i /mnt/d/path/to/your/key/idrsa.openssh user@yourserver.com

You will get right in without any prompts, but you will see some warnings you can rightfully ignore:

Could not create directory ‘/nonexistent/.ssh’.
Warning: Permanently added ‘www.infotinks.com,168.235.98.183’ (ECDSA) to the list of known hosts.
Linux www.infotinks.com 3.16.0-1160.21.1.vz7.174.13 #1 SMP Thu Apr 22 16:18:59 MSK 2021 x86_64
yourserver:~# 

For this it will ask you for your users password (luckily not everytime), so you will need to use tricks to bypass that. If you are root it will not ask. If you know of other tricks, leave them in the comments.