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.
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.
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.
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.
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â https://remotely.one
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 my.zerotier.com 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.
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.
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).
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)
half the answer is use tailscale. you can be behind NAT and without static ip (public or private). login on tailscale.com to create a tail, and turn off magicdns. install tailscale on both machines, and add them both to the tail. set the keys to not expire, manually set the vpn ip4 addresses within the allowed range. now each machine can access the other using the vpn ip address behind the natâs on each end wherever they are without exposing ports via forwarding.
you can ssh from one machine to the other, assuming sshd is running and permisions are set. the other half is running desktop sharing or tigervnc, but Iâm looking how to do that part myself so hence, half an answer.
I can still use that and afaik they are improving the screen sharing bit by bit.
so hence, half an answer.