VMAccessForLinux "reset" should fix permission problems

When dropping private keys in /etc/ssh or other places, it's easy to accidentally make them more visible than they should be. The sshd itself is quite picky; if it finds critical files are world-readable, it will ignore them. Example:
```
Starting sshd: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for '/etc/ssh/ssh_host_dsa_key' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /etc/ssh/ssh_host_dsa_key
Could not load host key: /etc/ssh/ssh_host_dsa_key
Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Could not load host key: /etc/ssh/ssh_host_ed25519_key
/var/empty/sshd must be owned by root and not group or world-writable.
[FAILED]
```
The VMAccessForLinux extension has a "reset the world" mode. This mode overwrites the existing sshd config file with one which is known valid, but it doesn't do anything to address the ignored keys (and thus blocked accesses) caused by these security problems.

I believe VMA4L should fix this stuff if it can. This might be as simple as fixing permissions in /etc/ssh, or it might go so far as to parse the error message and do something "reasonable" for each detected problem.

Start by tracing the VMAccessForLinux “reset the world” mode and how it rewrites the sshd configuration. Review the permissions of the files and directories shown in /etc/ssh and /var/empty/sshd, then determine which security problems can be fixed reliably. Done means reset addresses the reported ignored host keys and sshd permission failures without relying on an unspecified error parser.

Written by the indexing model from the issue text.