Remote Desktop!

[hornetster]

Sorry, time for a rant....
Why is it SO difficult to securely (or even insecurely!) remote desktop in Ubuntu/Linux? (Check out the number of basically unsolved forum posts.)
There is NO WAY to simply connect to a desktop (I am talking local network here, same subnet - won't even venture onto anything more widespread.)
Sure, can jump through heaps of hoops, and get some form of VNC connected, Remmina, etc, but don't venture into the security side of things - have to have a degree to get anywhere.
Have used TeamViewer for a while, but it even has issues in the linux world - works fine if you have a logged on machine on the other end, but if it is slightly "remote", and difficult to access, there is no way to remote a "logged off" PC. (and from what I can see at the moment, this is also an issue for VNC, and maybe Remmina.)
Please..... Can anyone give me a SIMPLE method of remoting to another desktop? Preferably to it's Plasma/Gnome/etc desktop, not a cutdown XFCE or similar version.
Yes, I do ssh into these machines and do admin from there, but there are times when it would be SO GOOD (and even essential...) to be able to connect to the GUI.
Wish I was a developer, and had a clue....

Thanks.

[Holger_Gehrke]

If you can ssh into the remote machine then you can run graphical applications from the command line. You just need to start the ssh client with the option for X11-forwarding ('ssh -X user@remotemachine'), then ssh will set up a way for the program running on the server to display on the client. No need to send the whole desktop over the network, just the window(s) for the remote application(s).
And as a bonus you can configure the ssh server to offer sftp, then you can connect to the remote file system from your file manager by giving it an URL of the form 'ssh://user@remotemachine/path' as a location. This basically turns your ssh into a network 'share'.

Holger

[hornetster]

lient with the option for X11-forwarding ('ssh -X user@remotemachine'), then ssh will set up a way for the program running on the server to display on the client. No need to send the whole desktop over the network, just the window(s) for the remote application(s).
And as a bonus you can configure the ssh server to offer sftp, then you can connect to the remote file system from your file manager by giving it an URL of the form 'ssh://user@remotemachine/path' as a location. This basically turns your ssh into a network 'share'.

Holger

Hey, great tip. Thanks. Have tried that before, but never really worked it out.... Will have a play with that!
Not a real solution to the full desktop, though.....

[cmcanulty]

I agree. I support 12 computers as our local library. After the upgrade to 20.04 I can't make vnc,, rdp, or anydesk work. All setups are the same as what worked in 18.04. I have wasted days of work trying to fix this. I wish Ubuntu would stop always adding new features yet basic features don't work.

[joeschu2]

Here's my experience. I installed a fresh 20.04LTS onto a 128g SSD from a USB stick. After it was completed, I went to the sharing section to turn on Screen Sharing. It was greyed out. I found out that you need Vino installed. I install Vino only to be told a more current version is already installed and so the install does not take place. I used sudo apt get install vino using terminal. Now I am on the forums trying to find a solution. That is why I am here agreeing with the above posts.

[cmcanulty]

how would I login to use graphical apps when I need to get to a certain port behind a router? I support 12 xubuntu machines at a library and have spent the last several weeks trying to get back access via vnc and rdp since upgrade to xubuntu 20.04 fried all my remmina remote access?

[TheFu]

On the LAN, I use remote X11

ssh -X remote-user@remote-server  command

I do this daily, for many applications. Why be limited to a laptop power when I have a desktop faster than a Cray supercomputer in another room?

For connections outside the LAN, I use x2go, which implements the NX protocol. NX uses ssh, which makes it pretty convenient, until 20.04 when something about x2go got broken and it is requiring a password be used rather than my ed25519 ssh-keys. x2go performance feels 2-3x faster than any VNC I've used. Use the PPA.

As you can see, all roads lead through ssh and for good reason.

I've been doing remote X11 through ssh for about 25 yrs. It is how I work and built into my workflow.
Coming from Windows and expecting non-secure connections like RDP or VNC to be possible doesn't make sense to me. I've heard that in the last year, MSFT finally tried to get RDP working in a secure way, but that broke compatibility with non-MSFT systems.

Now, if you run desktop inside KVM virtual machines, then we can talk about nearly native graphics performance over secure channels, but most people don't do that. Think I saw around 65 fps using the glxgears tests from a remote machine to a VM using the SPICE protocol. On the same hardware, again using SPICE, I just saw 745 fps. Seems fast enough and I know it is fast enough for video. SPICE isn't new, BTW. It has been used over a decade now. Spice supports both remote desktops and remote applications. Too bad they don't have any advertising for their awesome work or the Gnome project pushing it by name. Gnome is off adding bloat to their projects and dumbing down all the GUIs.

Many complaints are simply due to uninformed people. Sometimes that's me.

[hornetster]

Well, have sort of got it working, in an insecure way!! (Only ever use it on the local LAN...)
Installed/configured x11vnc on the machines I want to connect to, and use TigerVNC viewer on my client machine. Seems to be working OK.
Will see if I can work out how to run over ssh....
Thanks.

[hornetster]

Update from my last post....
x11vnc is started as a service on my server machine using: ExecStart=/usr/bin/x11vnc -auth guess -forever -loop -noxdamage -repeat -rfbauth /etc/x11vnc.pwd -rfbport 5900 -shared -o /var/log/x11vnc.log

Connect to this machine, using: ssh -L 5900:localhost:5900 media

Run tigervnc on this machine, and connect to: localhost:5900

It works!
So, I am assuming that this is now running securely over ssh...? Am I correct?
Can I monitor the data being transferred?
Thanks.

[TheFu]

Doesn't the -localhost yes option ensure it can't be contacted except on 127.x.x.x/8?
Check it by running an nmap scan from another system on the LAN.