Having said that, it seems rather backwards to me. I can think of all kinds of bad things happening if a rogue viewer (controller) connects to a given host, but I have a hard time picturing the same type of concern that I've connected to the wrong host.
I see. And yet, the host identity mechanism as it can be seen in version 6.8 and earlier was to prevent just that - unauthorized replacement of the Host with a rogue/patched copy.
Perhaps I could add this 'shared secret VIEWER verification' option as a feature request. This way I could honestly tell clients/customers that no other RUT viewer can get to their computer. That their host would speak to ONLY MY viewer. The current implementation (and the certificate based scheme in the beta version) does not offer that assurance.
This is the correct behavior. The purpose of shared secret is to provide the means to verify the identity of a remote Host, not to serve as another password or authentication factor. The program logic here is as follows: If there is a shared secret on the Viewer side (in connection properties) then the program performs the identity check. If it's empty , then the check isn't performed because the program assumes that admin doesn't want to perform identity check and it should let admin connect in.
That said in version 6.9 (as of Sep 25, 2018 in beta available for download) this system was totally replaced by a more modern certificate-based check. Now the process is automatic and doesn't require user intervention except only when there is certificate mismatch and the user is warned about it and asked for further actions. Here is a related documentation page for your reference.
By the way, in version 6.9 we also implemented two-factor authentication so if you want to add more security this is just what you need.
I recommend that you upgrade your Viewer, Server and at least one of the Hosts to the latest beta version (available here https://www.remoteutilities.com/download/beta.php ) and see if the issue persists with that Host. There has been a lot of changes made in terms of stability improvement in the latest beta version.
Another important feature that was added to beta 2. Quoted from release notes:
You can now remotely restart the Agent as administrator (provided you know the credentials) in order to perform the necessary tasks during a remote session, such as installing programs and interacting with UAC prompts.
This feature has been long awaited by many. Feel free to test it out and let us know if it works for you as expected.
Windows Defender detects Adware.W32/Unwaders.C!ml in rutview.exe of the new beta.
What's up with that? False positive I assume?
Yes, absolutely. It is a false positive. We will contact Microsoft immediately and file a false positive report.
To their credit I should say that of all antivirus software vendors Microsoft is the fastest in responding and eliminating false positive detections. Besides, they have a very friendly and well-though false positive report interface. We encourage everyone having the same problems with RU files to report a false positive at this link https://www.microsoft.com/en-us/wdsi/filesubmission
Beta 2 has been released. See release notes. The most importation addition was the "PIN" function that let's you protect your self-hosted server's Internet-ID "tunnel" from unauthorized use. Although this hasn't been a security vulnerability in any way, such use was still a nuisance (because of unknown Hosts hanging in the server connections list) and now it has been fixed.
Later today or tomorrow we will publish a blog post that will explain in detail how the new features work.