Desktop sharing

Happy New Year to everybody.
I need to share the desktop between two linux desktops, one is PureOS and the other is Arch, that both are behind their respective home routers. I can not find an easy solution to this. I know I can use teamviewer but would prefer a free software solution.
Jitsi was promising this (like zoom) but unfortunately they have removed this function from their software recently.
Is there any way? I know that the problem is that both computers are NATed and some entity must bring them together. Teamviewer or Chrome Remote Desktop play the role of such an entity. Is there something in the free world?

If not, what if both computers can access a real-IP server with ssh? Again, even in this case it is not clear how to do that with reverse tunnels.

1 Like

Wait what? :thinking: I can still use that and afaik they are improving the screen sharing bit by bit.

That need not be a major problem. Being NATted behind a device that you control (your router) means that you can put in a port forwarding rule.

The stumbling block is then two-fold

  • if the router itself is NATted (i.e. your ISP gives you a private IP address, not a public IP address) then you are relatively stuffed
  • if the router has a public IP address but the IP address is relatively unstable (changes too frequently) then it will be very inconvenient

If that can be overcome then something like VNC works fine, albeit that it is not secure from traffic snooping. If that is a significant problem then you can probably tunnel VNC through SSH - and that would mean port forwarding SSH rather than VNC.

Maybe I was not clear. I mean share the desktop and remote control it. Not just share. Is remote control supported? How do you do that?

Thanks for this information but I need this in order to help the other end. Which means that the user of the one end is not experienced to setup such things. This is why I was looking in a solution similar to teamviewer or possibly Jitsi.

Check here:

remote control has been removed from the client. And I can not see it available in a browser. Where is it?

(sorry this was not for @kieran but for @epinez)

I’ve just recently had a similar problem and found zerotier to work quite well.
It just creates a VPN(in the real sense as a Virtual Private Network) between the two Laptops and you can SSH from one into the other was you would within your own LAN.
For desktop usage you could set up TigerVNC for example.

Ah I understand! The Readme states

currently disabled

so I guess there is hope that this will be re-enabled sooner or later. :slight_smile:

Remmina may be what you’re looking for.

1 Like

I think that Remmina needs real IPs or reverse ssh tunnels. I do not think it works. Correct me if I am wrong.

Zerotier is non-free. I could use teamviewer in the non-free world.

I found “remotely”
which promises what I need but it is tested only on Ubuntu 18 and does not work in PureOs or Arch.
Maybe I have to compile electron for jitsi and find how to enable remote desktop. It seems that the free software is lacking such a capability if you require to be simple (otherwise I can always mess with reverse ssh through a real server or do port forwarding on the router).

@antonis the zerotier code on your device is completely open source as well as I think 99% of the rest of the code in use by zerotier and very well described in their manual.
If you use in it’s free version the only requirement is that your networks can’t have more than 50 members.
using zerotier as a VPN between your two laptops would then enable you to use Remmina(thanks @Gavaudan for that link) with the local IP addresses you get from their network.
I’m now using that setup to support my extended family and friends with their Linux laptops and PCs.
Remmina is still causing some problems, thankfully most problems can be fixed via ssh.

Thanks. I will try that then!

Depends on the level of “inexperience”.

One approach is that

  • You port forward SSH at your end.
  • You set up an SSH server at your end.
  • The other user then executes a single, albeit a bit messy, ssh command that does reverse tunneling over SSH (-R option).

The other user would need a working SSH server safely behind the NAT. As this is a Linux desktop that isn’t a huge ask but, yes, it needs to be done.

  • You then SSH in (so that’s SSH-over-SSH, reverse tunneled).
  • You then install a VNC server for the user.
  • You or they then SSH from them to you in order to reverse tunnel VNC.
  • You then VNC in (VNC-over-SSH, reverse tunneled). Yes, you can use remmina for this but there are other VNC client choices for you. (remmina also supports RDP but that is more useful for remote access into a Microsoft Windows computer.)
  • Optionally at this point, you could set up port forwarding on their router so as to bypass the need for reverse tunneling over SSH.

The net effect is that you might have to communicate via the phone (or, better, via email) one shell command to execute (or two if the other user doesn’t currently have an SSH server running).

I totally get why you want an easier solution but then if the teamviewer client is not installed on the user’s computer then teamviewer is not a zero-experience solution either.

Of course, none of this will work if the inexperienced user breaks his or her network. :frowning:

I wouldn’t recommend this: A large part of security for inexperienced users is that they are in a private network not reachable from public networks. If there is a port-forward forwarding from unsecure public networks to a machine on a private network this concept is broken.

Actually we put any resources we want to have reachable from unsecure public networks into their own broadcast domain we call DMZ (de-militarized zone). Between the public networ and the DMZ we put a firewall. Between the DMZ and the private network there is a firewall located also (the same as between public and DMZ in small setups and a separated one in better protected networks).

To open a port-forward for a user who do not understand the concept and risk is not a good solution - especially not if it is only to avoid a reverse port-forward ssh command (which is on the other hand an example for real good practice: the user has to act to let some third party in).


Fair points.

My assumption is that if @antonis is helping some other user and clearly he understands the options being presented, he can assess what is appropriate security, and what is not, and how long the port should be open for, etc.

I monitor my network fairly closely. Based on that monitoring, if you open SSH on a random port (not on port 22) then you don’t get a lot of attacks (in fact none or close to none) and the assumption is that passwords are strong, so that is a second line of defense.

Also, the default Linux SSH server allows you to specify which users are permitted to use remote access (so you could completely deny the inexperienced user remote access if you are concerned that the user will not keep a strong password).

At the end of the day, a network with an open port is very likely to be less secure than the same network without an open port. That can’t be denied.

I periodically scan my network from the internet, looking for open ports, in case there is something that has been inadvertently left open for longer than it needed to be.

One comment though:

That is IPv4 only. Once we get to IPv6 (I have dual stack) - and I assume that one day IPv6 will be unavoidable for everyone - you can’t rely on a “private network” for “security” any more, so you need to be more focused on what you are actually blocking at the gateway and what your actual configuration is for what you are allowing. In some ways, I don’t mind that i.e. being forced to be more explicit about what is supposed to be allowed and everything else is not supposed to be allowed.

(There are exotic alternatives if a user doesn’t want to face the full reality of an IPv6 world.)

to reinforce this rule in the proper way would mean that people who do seeding for p2p should use a dedicated seedbox behind a DMZ and only SSH into that ‘seedbox’ from a client inside the private network … is this ‘bridge’ possible over a non-managed-switch …

i’ve been contemplating on getting the proper hardware to set-up a pf-sense type ‘router’ but am not quite sure what would be good-enough for simple home use (no guests allowed for now)