Chris, Thanks for the writeup and information. That's a really good set of notes on how to make this work for the occasional use. Of course this also means that your local home session is now unlocked and visible while you're working on it remotely, and if your home isn't secure, you might be leaving yourself open. I'm sure you're re-locking the X-display when you're done and killing the x0vncserver, but I think it should be a part of your notes, so that things are kept secure. Now if you turn off your monitors at home while on the road, this is a little less of a risk if only because your montiors won't light up when you're using them remotely. I still like the mobaxterm solution for some situations. But if you need to grab info from a running X tool which can't be stopped/restarted, then this works well. John

...

...

...

...

"Chris" == Chris Thompson via WLUG writes:

Hi all,

Following up on a 6 month or so old inquiry...

My request had been to get to my desktop session of X remotely. I seldom use this (mosh is typically more than enough) but occasionally it can be handy - e.g. grabbing a password I forgot to move out from FireFox into KeyPassXC, etc. (I do use FF sync, but not for passwords...call me paranoid - I don't mind).

I ended up going with John's suggestion: something VNC-based. While you can set up Xvnc itself for a separate session, I prefer not to do this (nor do I need/want a Display Manager remotely). I only wanted on-demand access to the desktop shown (i.e. what's on the local monitor), and have found TigerVNC to be a good fit for this.

Setup...

"Client" = laptop on the road, "Server" = the desktop @ home

Client setup: while you can use `ssh -L etc.` to set up port forwards, I prefer just using ~/.ssh/ config, to which I added something like this:

``` Host my_server # the alias I'm using for the server system     LocalForward 5900 127.0.0.1:5900 # forward local port 5900 to 127.0.0.1:5900 on the server site     HostName xxx.xxx.xxx.xxx # IP or fqdn of server system

```

So, my laptop's localhost:5900 is now forwarded (through SSH) to the server system's equivalent of 127.0.0.1:5900. You can of course change the ports as needed, but as I do not run an VNC server process on my laptop, this is fine for me.

This is where Tiger's x0vncserver comes in (x11vnc is another alternative). From `man x0vncserver `:

       x0vncserver  is a TigerVNC Server which makes any X display remotely accessible via VNC, TigerVNC or compatible viewers.  Unlike Xvnc(1), it does not create a virtual display.  Instead, it        just shares an existing X server (typically, that one connected to the physical screen).

Just what I wanted! Once I have connected via SSH, to the server system, I start vnc on the server with ` x0vncserver -localhost -SecurityTypes none -display=:0`. This only listens on localhost, disabling security, and shares out from display :0, which is my normal i3/X11 desktop. There are a few additional security options with tigervnc, but I'm just relying on SSH in this case.

Finally, I connect to my desktop from my client machine with `vncviewer localhost`. You can also just run vncviewer and will be presented with a GUI for specifying options.

The performance is ...well, about what I expected from VNC at times, but overall it's been pretty reasonable/good for my limited use cases. A couple notes specific to me that may apply to you: I normally run a picom (an X11 compositor) - killing this before connecting is a good performance choice. Additionally, I disable a monitor with xrandr. The VNC client works well (when in full screen) with multiple displays by scrolling following the mouse motion, but it's just less practical IMO than dropping a monitor.

There are some other options that make this set up even simpler (e.g. see the `-via` option of vncviewer), but I figured starting with a more spelled-out example was better. My primary reference was the Arch wiki: https://wiki.archlinux.org/title/TigerVNC

Regards, Chris

On 7/24/22 14:37, John Stoffel via WLUG wrote:

"Chris" == Chris (wolcen) Thompson via WLUG writes:

Chris> Great to see you all in the last meeting :-) I was the Chris> skateboarder...who caught me almost falling shortly before I Chris> left? LOL

It was good to meet you, hopefully face to face sometime. And I hope you're all staying cool today, it's been a scorcher!

Chris> [Insert name I've forgotten here (sorry!)] mentioned that their Chris> users connect to a remote session's root desktop (or whatever Chris> you call the initial/primary display :0 deal that you Chris> initially/locally get). Chris> I would like to do this as well. SSH with port forwarding is Chris> probably my preference, but wireguard would be OK as well. I Chris> don't think I want to directly expose anything like xrdp. Chris> Anyway - could you please refresh my memory as to what was Chris> being used? I'm running i3 in this case (started via Chris> lightdm). I generally have not loved using VNC-based tools, but Chris> if that's what is currently recommended, I guess I'll give it Chris> another go.

For a long time I was using NX (or FreeNX) on my work desktop so I could connect between a windows box and a linux desktop using Synergy to map the keyboard/mouse between systems as I moved the mouse between my desktops.

That was using the 'nomachine.com' software, though I used the freenx stuff. But after a while it got to be too painful, and now that I mostly work on a windows laptop for work (due to the work VPN requirements) I don't tend to do anything beyond lots of putty sessions in which I run screen.

I've tried MobaXterm, but never really liked it, even though it does offer native X display, so you can fire up remote graphical tools. This would work better if I wasnt' 80-100 miliseconds of lag (basically across the entire US) distant from the remote systems I manage and work on.

Much as I hate to say it, I've sometimes just fallen back to VNC when I need to fire up a web browser to download a 5-10gb ISO image to do a system install.

Chris> ------------ Chris> SSHFS Optimization Chris> Also - I referred to using sshfs internally for myself to my NAS, and Chris> some optimizations for it. This is my current alias to mount it: Chris> sshfs -o cache=yes -o kernel_cache -o Ciphers=aes128-ctr -o Chris> Compression=no -o ServerAliveCountMax=3 -o ServerAliveInterval=15 -o Chris> reconnect -C -o idmap=user server: /mymountpoint Chris> I got a few of the recommended switches from this article that finally Chris> convinced me to just forget about NFS: Chris> https://blog.ja-ke.tech/2019/08/27/nas-performance-sshfs-nfs-smb.html

This is a great set of info, because I too have used sshfs at times but cursed to slow speed. I'll definitely try this out. It would be nice if the windows client also supported these options as well at times.

Cheers! Joohn _______________________________________________ WLUG mailing list -- wlug@lists.wlug.org To unsubscribe send an email to wlug-leave@lists.wlug.org Create Account: https://wlug.mailman3.com/accounts/signup/ Change Settings: https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ Web Forum/Archive: https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/P6JMCK...

_______________________________________________ WLUG mailing list -- wlug@lists.wlug.org To unsubscribe send an email to wlug-leave@lists.wlug.org Create Account: https://wlug.mailman3.com/accounts/signup/ Change Settings: https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ Web Forum/Archive: https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/3GKRQL...