There is OpenSTF which is similar but for physically remote controlling Smartphones. No need to install any client.
Can be controlled from any browser, even from another smartphone.
Slightly off topic, but it's often bugged me that remote desktop protocols push for things like video and audio redirection as if everyone was on gigabit networking, but I haven't seen much in the way of pushing down down down on bandwidth.
Dameware Mini Remote Control from years ago used to have options to set grayscale and dithering and horizontal scanline interleaving(?) and slow refresh frequency and things, but I imagine going beyond that - a line sketch of the visible window borders and their titles, then let me draw a region to update with the mouse, scrape the text out and send that to me.
There's ways to build TUIs inside CLIs, but what about squishing a GUI down towards a CLI-style-basics?
My problem isn't really the protocol or the client. It's that the device is behind a NAT, a corporate firewall or otherwise not reachable at a public IP address.
I assume this project doesn't help with that?
For now I'm just sticking to products like TeamViewer.
RDP uses a single port so opening a port on the public IP NAT for RDP is trivial, however it's always best to hide RDP behind a VPN. This security rule applies to pretty much any remote access protocol, which you should avoid having listening on the open Internet.
I'm all for defense in depth generally, but if a use case demands the convenience of not having this extra step, can't various application protocols be made as tough as a VPN to crack? At that point the VPN just adds obscurity. Wrapping insecure legacy protocols, like SMB for example, with a VPN is absolutely required.
The step of flipping a switch to connect to a VPN isn’t that bad. Googles IAP is in a lot of ways more annoying since you end up having that step multiple times.
It’s not really the protocol that people are worried about — it’s attack surface. VPNs have basically zero — everything is opaque and an attacker learns nothing except that you’re on a VPN by observing your traffic. An attacker doesn’t even know that the application you’re connecting to exists and can’t even reach it to break in it without first breaking into your VPN.
You can call this obscurity but I think it’s better to say that you’re not leaking side-channel information about your network.
Having a VPN isn’t an excuse to have poor network security internally but a single portal that’s internet facing is much more defensible than n different home-grown apps.
I often maintain hard white list for remote services when VPN is not an option.
A cool option that does not have much implementation out there is using port knocking to open ports on demand. If the scheme is dynamic, it could be virtually impenetrable.
Another way to go is to have a web app on your network, behind some decent authentication scheme, that has a menu option to open a remote access session. This app then white lists your IP on your edge firewall for N time for service and presents a quick launcher link -or- send email with link etc. This would be a good option for an SMB with little tolerance for VPN.
The Guacamole server needs to be reachable from the internet, but the desktops you're connecting to only need to be reachable from the Guacamole server. That helps with some but not all of the situations where desktops aren't reachable with a public IP.
Interestingly Ctrl W can actually be captured in Chrome now (on desktop) if the application is fullscreen and they make use of the keyboard lock API. I'm away from my desktop at the moment - can you try it on Chrome? (if you were using another browser). If it doesn't work we should file an issue and suggest they look into the keyboard lock API!
Siblings are kind of vague about what these project actually are imo.
NoVNC: essentially a web page that presents a VNC client that connects to a VNC server over websocket. Part of the noVNC project is a websocket proxy to vnc that you'd run on the machine with the VNC server; or another machine somewhere either within the network or external internet. In either case the proxy has to have access to the VNC server'd machine so not really good for NAT or restrictive firewalls (although you can work around with port forwarding and setting the VNc port to a well known port).
Quacamole: Also presents a browser client for VNC (and RDP) but Guacamole is designed to exist as a standalone service on an external nextwork that proxies into private networks. It proxies the protocol (VNC or RDP) I don't think it tunnels through websocket. Here I mean Guac to private network; Guac to browser is surely tunneled over ws.
So very similar functionality.
In either case the machine to be accessed must have a VNC server (or enable RDP) and access to the open internet on a non standard port (ie likely blocked by company firewalls), to access that machine. Neither work for restrictive company intranets :)
So if you're trying to setup guerilla access to work desktop, and you don't have admin access to install TeamViewer, there aren't any options that I've found.
What both of these enable is accessing your private desktop from anywhere with a browser.
No you are incorrect. noVNC is still ultimately a client, a simple baked-in static web server does not a PaaS make. Guacamole is a turnkey server that works out of the box where you get a full blown GUI and control panel and everything. Guacamole has the added overhead of the proxy but it's a lot more convenient. Unless you are doing high performance applications like cloud gaming with the server halfway across the globe, Guacamole is more than sufficient if you don't want to fiddle with too many knobs.
As a user of noVNC, I'd be interested in such comparison, too. I haven't used Guacamole, but as I understand, sansnomme's point is that Guacamole compared to noVNC is like Visual Studio compared to GCC - while GCC and noVNC offer you most basic tool, Guacamole and Visual Studio provide some helper utilities around - like session management, config UI, etc.
So when compiling single-file "hello world" app or connecting to a single machine you would prefer a simpler tool (GCC/noVNC), since more complex tools require more complex workflow; but for more complex projects (or when you have tens of machines under your control) you would prefer more complex tools.
Disclaimer: I have never used Guacamole, used Visual Studio very little, and my experience with GCC is rather limited.
Love this project. I maintain a service around Guacamole[1] with slightly modified protocol and client built in nodejs instead of the included Java one.
Nice, are you getting any traction with this? The land page says "No Installation Required" but the users desktop does require either VNC or RDP enabled correct? And from the "user inside the firewall" perspective, ports have to be opened for RDP/VNC?
Last I checked, I had 150+ unique weekly active with successful sessions.
Most use it to connect to their ec2-like machines and not for teamviewer-like usecase.
My main problem is that user’s login creds have to go through our server unencrypted as we essentially provide a translation proxy for VNC/RDP to websockets.
I've used this a ton with cuckoo sandbox. If you haven't already set up your own cuckoo and use it to visir untrusted links and open untrusted files. It is fun! I like how guacamole allows you to interact with the session. I know a few (most?) Paid alternatives that won't let you interact.
Same. I have an installation setup, with KVM, but even after following instructions and setupz cuckoo never reverts the snapshot it used. So after the first use , it reused the potentially malicious snapshot for the next run. If I can't figure out how to fix that , I can't use it.
Has anyone set something like this up with sound + multiple viewers? I've been looking for someone to help me watch TV with friends who are remote. I used to use rabb.it but I think that died.
Have you looked into VLC or OBS for doing this? The big issue that isn't really solved is that most desktop protocols take advantage that the image has a majority of the screen static and only small areas of the screens need updates. Video is the exact opposite problem: nearly every pixel changes across frames and so to have it be reasonably well sync'd especially with sound you need a different kind of protocol.
Rabb.it was really cool because it was a shared web browser that was ephemeral and neutral. Both people could control it, there was very low latency, and you could keep doing sensitive stuff while rabbit was also open. I haven't been able to find a way to do that with RTMP streaming systems.
https://openstf.io