[Feature] Remotely Desktop Connection request

[sinichi19]

Good Day,

I already tried the unattended option and everything works fine.

My question now is for Instant support clients if there is settings to disable the notification when someone remote your computer.

Want to achieve is when the user gave the session ID can now connect or remote the computer

Thank You

[swilkey]

Hi Sinichi,

Not for instant support (unless Jared has introduced a new feature I'm not aware of). Instant support clients are expected to have someone present. Otherwise you should use the unattended client.

Regards, Stephen ------ Original Message ------ From: "Sinichi" notifications@github.com To: "lucent-sea/Remotely" Remotely@noreply.github.com Cc: "Subscribed" subscribed@noreply.github.com Sent: 24/10/2020 3:23:52 PM Subject: [lucent-sea/Remotely] Remotely Desktop (#152)

Good Day,

I already tried the unattended option and everything works fine.

My question now is for Instant support clients if there is settings to disable the notification when someone remote your computer. image https://user-images.githubusercontent.com/44279612/97067771-7b039280-15f3-11eb-8ffa-4d92b4eaabb5.png

Want to achieve is when the user gave the session ID can now connect or remote the computer

Thank You

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/lucent-sea/Remotely/issues/152, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB5UXTBF4V57XXV33PCJTV3SMJJFRANCNFSM4S5J2YSQ.

[sinichi19]

@swilkey noted thank you for your reply. The connection request is nice feature but hopping to add the option to disable, for data privacy some users dont want settings have unattended program running to remote their computer.

And like in support group sometimes user request an assistance, email their session id to remote the computer and leave to attend other things

Like features on TeamV*** after gave the ID and Pass we can remote the computer instantly.

Thank You and More power

[bitbound]

This may be a possibility in the future. I'll leave it open for future consideration. I don't have time to work on new features at the moment, though.

[sinichi19]

Thank You Sir @lucent-sea for consider my request.

---

another suggestion Sir if possible for Instant support client for the Elevated to Service option.

Suggestion 1 : upon open the Remotely_desktop.exe there is pop-up message if requester want to elevate to services (Yes or No) then the Remotely_desktop will opened with session id elevated to service.

Suggestion 2: Change the location of Elevate to service, check box under Session ID and checked box will not change even close the apps only remove when user unchecked again

Thank you for this great system.

More power and God Bless

[Nil0x]

Hmm, so I wouldn't mind taking a run at this. I've seen similar on demand agent behavior implemented in Bomgar/Kaseya . It really just depends on your use case.Usually, large support queues leave it enabled.

https://github.com/lucent-sea/Remotely/blob/940431db709183333d53df6cc17eb213b19fce9f/Server/Hubs/ViewerHub.cs#L215 - This is where the on-demand Screen cast request is sent to the client.

https://github.com/lucent-sea/Remotely/blob/087eb8dfa321f982b128b1e556c63969b2e51b43/Desktop.Win/ViewModels/MainWindowViewModel.cs#L281 - Where the popup actually occurs.

I guess a good plan would be to:

• Add another config variable named RemoteControlInstantNotifyUser ( if that's not too long )
• Reference that variable to the screen cast request that's sent to the client
• Handle the notification condition here: https://github.com/lucent-sea/Remotely/blob/940431db709183333d53df6cc17eb213b19fce9f/Desktop.Core/Services/CasterSocket.cs#L239

Thoughts?

[bitbound]

I think it would also need a password, like TeamViewer does. I wouldn't feel comfortable leaving a session open, even if it is user-initiated, that's only guarded by 9 digits.

So here's what I think will need to change to make this work:

• Add the "Elevate to Service" as a checkbox.
  • The value should be bound to property on the viewmodel.
  • Add a property for this in Services.Config.
  • On set, change the config value and save it.
  • On load, set the property in the viewmodel from the config.
• The client will also generate a password when it starts up.
• Add password as an optional field on the remote control page.
• If password isn't supplied, the connection process works as it does currently.
• If password is supplied and matches, connection is made instantly.
• Reverse the "flow" of session ID.
  • The client will generate the session ID instead of the server.
  • The client tells the server what it's session ID and password is.
  • Hub method responds with boolean. If session ID is taken, responds with false, and client tries a different one.
• The above is necessary to add automatic reconnect to the client in attended mode.
  • Add automatic reconnection to client in attended mode.
  • On reconnect, it sends back the same session ID and password it already generated (so it doesn't change).
  • If Session ID is taken at this point, it's because the previous session hasn't fully disconnected on the server. Wait and try again. On the UI, just stay in "Reconnecting..." state until it's completed successfully.

[bitbound]

Also, the above would need to be done for both Linux (AvaloniaUI) and Windows (WPF).

[sinichi19]

Thank you sir @lucent-sea @Nil0x

1.Option to disable connection request 2.Already elevated to service when open the Instant support.

If the 2 suggestions added to the Remotely Desktop instant support, I think Remotely is more easy to use ,secure and powerful remote desktop

The requestor and the support group benefits this features.

Again, thank you for this great system.

More power and God Bless.

[Nil0x]

Good point @lucent-sea . I didn't consider users who leave instant access open; without a custom password I'm sure it'll be a target for brute forcing since there's isn't rate limit system in place.

I see why you were hesitant to start working on this, it requires quite a bit of changes. I'm still going to attempt to work on this, and I'll push a PR once I get it in a semi-working state.

[bmcgonag]

I was just thinking that the client side could grant access for the single session key, then when the session ends, a new key is generated, and the user would have to again give permission for that session key before leaving their workstation. I kind of understand why this could be useful, but definitely have trust issues given all of the scam companies that use tools like TeamViewer for these tools that don't let the client have total control.

[nako-ruru]

Reverse the "flow" of session ID.

• The client will generate the session ID instead of the server.
• The client tells the server what it's session ID and password is.
• Hub method responds with boolean. If session ID is taken, responds with false, and client tries a different one.

would remotely persist session ids? that is, If one client disconnected for long time, might remotely allow another client generate the same id? And if remotely allowed it, would the former client generate another id?