How to use remote assistance with Ubuntu Frame

Contents:


This document describes how to use the remote assistance function in Ubuntu Frame.

The ubuntu-frame-vnc snap

The remote assistance feature of Ubuntu Frame is provided by the ubuntu-frame-vnc snap. This needs to run on the same device as Ubuntu Frame and, under the hood, it uses wayvnc built and configured to work with Ubuntu Frame.

You can install the snap:

$ snap install ubuntu-frame-vnc

Using as a daemon

The default on Ubuntu Core, using as a daemon allows you to always have the remote access enabled. To turn the daemon feature on or off, use:

$ sudo snap set ubuntu-frame-vnc daemon=true
# or
$ sudo snap set ubuntu-frame-vnc daemon=false

Running manually

To run the server manually, just issue:

$ ubuntu-frame-vnc
# Ctrl+C to stop

NB: If you’re running Frame on a Wayland desktop, by default this will try and connect to your desktop rather than Frame. On Ubuntu 22.04, for example, the symptom is:

$ ubuntu-frame-vnc 
wl_registry@2: error 0: invalid version for global wl_output (5): have 2, wanted 3
ERROR: Compositor doesn't support screencopy! Exiting.
ERROR: Failed to initialise wayland

To make sure you’re using the same WAYLAND_DISPLAY, run all the components with the same value of the variable:

$ WAYLAND_DISPLAY=wayland-99 ubuntu-frame
# in another terminal
$ WAYLAND_DISPLAY=wayland-99 ubuntu-frame-vnc

Authentication

Version 82:

This feature is only available from version 82 onward on the 24 track.

To improve security of the connection, you can configure the daemon to require a username and password - it’s recommended to use read -s to avoid the password getting into your shell history:

$ snap set ubuntu-frame-vnc username=user password=$( read -s P; echo P )
# type your password and press Enter

The daemon will restart and require the provided username and password on connection.

NB: not all clients support this mechanism, see Client compatibility below.

To disable again, set both username and password to empty:

$ snap set ubuntu-frame-vnc username= password=

Remote access

Rather than expose an extra attack surface, ubuntu-frame-vnc is configured to only listen on localhost, on port 5900 (the default VNC port). It is up to the operator to expose it securely to the outside or provide other means of access.

SSH port forwarding is a common approach. On your host, issue:

$ ssh -L 5900:localhost:5900 <user>@<hostname>

You will then be able to connect to localhost with any VNC client running on your host.


Here is the same, wrapped in an example using the frame-it snap and gvncviewer:

$ sudo snap install frame-it
$ sudo apt install gvncviewer
...
$ frame-it.vnc <user>@<hostname>

Client compatibility

The following VNC client software was tested against this:

Debugging

When things don’t work as expected, the general rules apply when debugging snaps.

The first place to look would be snap logs ubuntu-frame-vnc. Use -n <number> to see more history.

You can also use [sudo] snap run --shell ubuntu-frame-vnc to get into the environment of the VNC server and poke around. Use ${SNAP}/usr/local/bin/wayvnc to run it, and provide configuration options, like --log-level trace to get more information.

Please file any issues you find, with as much context as possible, on the GitHub page.

2 Likes

@saviq Works great, thank you for this snap!

Is there a specific reason that remote access via SSH tunnel does not work with macOS’ built-in Screen Sharing.app (the same that’s launched when using Finder > Connect to server … with vnc://localhost:5900)?

I set up port forwarding with ssh -L 22590:localhost:5900 user@remote-host and remote access works fine with TigerVNC. So just curious if I can get it to work with built-in tools. Currently, when I launch Screen Sharing.app with open vnc://localhost:22590, it fails with **Connection failed with “localhost”.

Hey @glancr,

VNC is unfortunately notoriously incompatible… Part of the reason why we decided to go the SSH route rather than adding authentication / encryption in the snap.

The macOS internal client is… ancient, and upstream neatvnc doesn’t seem to want to go there:

https://github.com/any1/neatvnc/issues/48

Yikes, seems Apple needs to clear up the cruft there. Thanks for the clarification, I was looking for related issues in the wayvnc repository and didn’t catch the upstream repo.

I am a bit confused over here. Can someone please help me out? I am running ubuntu core on raspberry Pi. I have installed ubuntu frame and ubuntu-frame-vnc snaps on it. I need to access it via VNC, but I am not able to do it. Where do I run the “ssh” command provided in the Remote Access section above? What username and hostname do I need to provide?

When you set up Ubuntu Core you configured a user account with ssh access. I assume that is what you used to install Frame?

That is the account to use, from where you use ssh to access it.

2 Likes

@prof_paradox SSH is just one way to go about it. We have left this to the operator by design. VNC is really bad at security vs. client compatibility, so exposing it outside of localhost would be a big security risk.

If you don’t have SSH access to your device(s), you’ll need to work on a different way of accessing them - VPN with port forwarding is one other way.

1 Like

Hi Everytone
Loved this discussion, thanks for sharing.
But I didn’t really found (in this topic and all over the internet) an answer to my need :

  • I would like to avoid any SSH connection to forward 5900 port to the user … because my users will assist the customers, but don’t have the technical skills to use command line and port forwarding.
  • on the other hand, I fully understand the Cyber objectif to not expose this VNC server to the worlwide.
  • but , at the end, our targets running Ubunutu frame and associated VNC are protected by a VPN? with only the necessary ports open (on this VPN, so double level)
    How can I expose 5900 port to any peaople already loggued in network (the VPN in my case)?
    YEs my question is how to kill this portection ?

Thanks and BR

Nota : I already tried a port forwarding on my server with no success (forward 5900 to 0.0.0.0 on the VNC server machine) :
sudo iptables -t nat -A PREROUTING -p tcp --dport 5900 -j DNAT --to-destination 127.0.0.1:5900
sudo iptables -A FORWARD -p tcp -d 127.0.0.1 --dport 5900 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

You would need to do two things:

  1. create a version of Frame VNC that doesn’t restrict connections to localhost. (it is a bad idea, but the project is open source…); and,
  2. To configure Frame to enable the Wayland protocol extensions this needs (zwlr_screencopy_manager_v1, zwlr_virtual_pointer_manager_v1, zwp_virtual_keyboard_manager_v1)

Thanks @alan_g

  1. that’s typically what I also want to avoid :slight_smile:
  2. thanks, but sorry, I’m not sure to understand : configuring for wayland, then using wayvnc typically?
    BR

By default Frame allows the listed Wayland protocol extensions for ubuntu-frame-vnc, but not for arbitrary snaps. If you create another version of the snap, Frame won’t recognise it. So you need to enable those extensions for snaps Frame doesn’t recognise.

That sounds exactly like what you should be going for. I’m no iptables expert, but it should work, provided you use the right incantations.

Did you enable IPv4 forwarding on the system?

Ref.:

Hey Saviq and Alan
Thanks for your both feedback : sharing my solution :

sudo sysctl -w net.ipv4.conf.all.route_localnet=1
sudo iptables -t nat -I PREROUTING -p tcp --dport 5900 -j DNAT --to 127.0.0.1:5900

And that’s it !
Of course, for anyone who read this : this is dangerous because VNC server si set without any password, so to use only if you have another level of security, e.g a VPN

Just need to keep them persistant :slight_smile: )

BR

Hello
New question please about ubuntu-frame-vnc : how can I improve speed / velocity of the display ?
Typically, what are the available options about the ubuntu-frame-vnc server to encode in 256 colors, compresse at its maximum, even reduce the resolution of the pictures sent to the client ?

I tried to find some documentation about this, but no success yes.

Thanks in advance
and BR

@VincentA hey, it’s the client that requests the connection properties (colour space, compression), so you have to tweak on the receiving side.

The only options available on the server side are these:

https://manpages.ubuntu.com/manpages/noble/man1/wayvnc.1.html

Out of these, only --max-fps you could try and change, but it’s simply the maximum, the client can still do less than that.

1 Like

Thanks @saviq , will have a look
Understood, everything is linked to WayVNC for this topic
I will RTFM :slight_smile:

Dear All
New question, please
ubuntu-frame-vnc perfectly answer to my VNC client.
BUt, the real monitor is a 1080p in portrait mode, so 1920X1080 ==> 1080x1920
The target /VNC server is still running Ubuntu 24, and display is as expected on the real monitor.
but on client side (with TightVNC, RealVNC or others), mouse click are not correct in front of the display.
ALso : the VNC client displays a picture of 1920x1080 (portrait with black sides, and in the middle, perfectly displayed my SW interface)

And obviously, impossible to use the client mouse as I click on the wrong zone …
Surprisingly, the client finds a portrait resolution.
2024-11-15 (3)

Any please, plase?
Thanks and BR

Hi @VincentA, indeed this was reported before and I’m afraid we have no immediate resolution, or a timeline for this to be fixed.

Please subscribe to Rotated outputs and input dimensions confused · Issue #16 · canonical/ubuntu-frame-vnc · GitHub and if you can help with debugging or fixing, please do.

Hi @saviq
Thanks, I will follow.
I’m not an expert but if I can help.
This is a complex topic, because It as to be investigated in the correct context (that is not gdm I guess, but perhaps wayland)
On my side, I tried to just rotate the ubuntu login screen to sync any SW, … without success.
PErhaps running another VNC server? (x11vnc?)
If any idea , success, I will share.
All the best !