Pepa Kokes's community posts

Yes, I am fully upgraded and the issue persists. In fact, it has been in existence since I first started to use RU, some six years ago.

That was my mistake. Yes, I am using version 7.1.5.0 on all machines, both as a host and as a viewer.

When a host is installed, it generates its certificate that can be used to verify the identity of the host. This replaced the older scheme of shared secrets that needed to be set up on both the host and the viewer. However, it seems that this new certificate-based approach does not take into consideration the callback connections. I was just setting up another callback host now and took the precaution to copy its certificate, but it was never needed - I was able to accept the callback connection with no requirements at all, and the moment I entered the shared key I was able to connect. But if it weren't for the fact that the two computers were sitting next to each other on my table, I would have ZERO information on the identity of either. So what's the purpose of the Host certificate if it isn't used to identify the host? Should someone replace my host with a fake one, how would I ever know that the change occurred? I would expect that the viewer would display the server's certificate, ask me whether it is correct, and then it would save it in the host list and warn me if the certificate ever changes.

Also, I would expect my viewer to also have a certificate and I would expect it to get checked by the hosts before they allow the callback connection to be used to control them. Currently, if someone replaced my Viewer machine with their own, the hosts would not be able to detect that and would happily allow an intruder to control them (assuming that the intruder knew the password, but that's not too difficult).

(Incidentally, it would be great if *I* could generate the certificates using my CA and setup my CA as a source for trusted certificates. But that's a nice-to-have, first I need to resolve the identities using the RU's default method.)

Hi! After a number of years of happy usage of RU, I tried to add a new computer to my RU family and once again encountered an issue that doesn't make any sense. I remember that I encountered that same issue years ago - and apparently it was never resolved and works the same even with the current 7.0.5.0 version.

The setup I am using is this:

1) One machine with a public IP address that runs a RU-Viewer.
2) Several machines without public IP addresses that run a RU-Host in a callback mode (let's call them X and Y).
3) The viewer listens on port 5651.
4) The hosts connect to this port. (Actually, it's a bit more complicated since I am not connecting directly but rather through a SSH tunnel, but that's not really relevant - eventually the traffic reaches port 5651 on the Viewer machine.)

However, I found that I can't get the connections to work properly if multiple hosts are alive at the same time. I would get a message saying that a connection from machine X was automatically accepted by the viewer (which is intended), but then in a few seconds later I would get another message that another connection from machine X was automatically accepted. But I would never ever see a connection from machine Y.

To fix this problem, I need to open the Remote Utilities Host Settings on both X and Y and change their listening port (Network -> Port -> Port) to different values (e.g. 5650 for X and 5651 for Y). Once I do that, I start getting messages about accepting connections from both X and Y and everything would begin to work perfectly - e.g. I can remote control each of the hosts.

But I feel this must be a bug - there's absolutely no reason why the *listen* port on the host should have *any* relevance to that host's callback connections, and in particular, why should the viewer care - but it does. I would understand if the viewer was only capable of handling one connection so the first machine would connect to the viewer's listen port and all others would get refused, but that's not the case - the viewer is perfectly happy to accept several simultaneous connections from several different hosts, provided that *their* listen port (which should not come into play *at all* during callback connections) is different for each host.

Could the developers please look into this and fix the viewer*) to not require different host ports? Thank you.

*) Probably the bug originates with the viewer - if I shutdown host X and only keep Y, it will connect to the viewer fine. The same happens if it is lucky enough to send its connection packet first.

The old topic can be found here: https://www.remoteutilities.com/support/forums/messages/forum1/message4906/1011-callback-connection-docs-need-an-update

Dave Barton: Note that the actual security is not an issue here. The "feature" (or "limitation" if you prefer) is designed to satisfy the requirements of antimalware software. It doesn't matter if these requirements are useful or pointless, smart or stupid - it the application wants to avoid being tagged as malware, it has to comply. Having fought with a similar issue with some of my applications, I can understand the developer's frustration about that, but there is really not much else that can be done - antimalware is in practice a law upon itself.

As far as adding the ability to move to the window - I don't think it's that simple. It seems that the notification window it is not actually a window, so any movement code would have to be implemented from scratch - and any such implementation would create conflicts with the intended "click through" functionality. Given the amount of negative backlash of the feature, I would recommend implementing an option to sel ect fr om a fixed set of possible positions (all four corners plus the center of the top and bottom of the screen), that seems reasonably simple while still achieving the desired effect.

The message is not removed for my reverse (but still direct) connection, even though I am on 7.1.1.0. Doesn't bother me much AND I rather think that reverse connections should display the message (they are as easily exploitable as the Internet-ID-based connections), but it's clearly not true that "We have removed the notification for direct connections" - not for *all* direct connections you didn't.

I would like to ask for a modification to the Portable Viewer. According to the documentation ( https://www.remoteutilities.com/support/docs/portable-viewer/ ), it saves its configuration files in the directory with the .exe file. That is somewhat unfortunate because it encourages the insecure practice of having the program directory writable. While that is a common thing in portable installations, it would still be nice if the configuration files could be saved in a subdirectory (e.g. "Config"), because then the program directory could be kept read only and only the config directory would be made writable.

Or, an optional read-only file could be placed in the .exe directory, containing the path (relative to itself, preferably, unless the user entered an absolute path) to the actual configuration data.

It's not a pressing issue because of the undocumented mitigation factor that if the directory with the .exe file is read-only, then the Portable Viewer will store its configuration in %APPDATA% just like a regular viewer, but a modification would still be preferable - currently, it's not possible to have two Portable Viewers installed at the same time unless at least one of them is installed insecurely (as in, "it's possible to replace the .exe file with a malicious one").

I had the exact same problem even with version 6.10.10.

Viewer 7.0 cannot connect to Host 6.0 for file transfer, reports "Unable to open directory". Remote control works fine, as do the other components that I tried.

Presumably there are some reasons for this limitation, but I find it very strange. It seems to make screen blanking pretty much unusable. Wasn't it better to use the old implementation with a dedicated driver then?