the end result will be this: in remmina you can double click on a stored session and it will automatically connect to a remote machine via ssh, start x11vnc on that machine, then create an ssh tunnel and finally connect to the remote vnc session via this tunnel.
first of all make sure you have password-less ssh key authentication in place, so you can ssh to your remote machine without being asked for a password.
your user on the remote machine needs to be able to start x11vnc on that machine
once you have verified this all works, you can start remmina and create a new connection profile.
as Protocol choose VNC-VNC viewer
as Pre Command use
ssh -p 123 firstname.lastname@example.org x11vnc -display :1 -bg
me is the user,
mypc.myhome.ch is the hostname of the machine you ssh into and in my exmaple I've assumed that your server is not listening on the standard port
22 but rather on port
123. Our display we want to connect to is
:1 in this example .. use here whatever parameters you used when you tested x11vnc before but what's imporant is, you must add the
-bg parameter as well. this will send x11vnc to the background once it is started.
as Server use
now go to the
SSH Tunnel tab and select Custom and type
mypc.myhome.ch:123 then enter your User name and select SSH Agent (automatic) as authentication method.
now you Should be all set and you can now click on Save and Connect
by the way: a post command to close your x11vnc server session is not necessary. if not started with the
-loop parameter, the x11vnc server will quit after one connection attempt.
I am using the remmina snap rather than the apt package as the snap comes in a much newer version and i need some of the newly added features for RDP for some other sessions. And since i'm using ubuntu, apparmor is running and ready to cause troubles.
the above instructions did not get me connected in the first place. I had strange issues with the Pre Command. For example a simple
sleep 5 was working just fine, but a
tuch /tmp/precommand did nothing at all. the same was true for any ssh commands.
eventually i found out that the best way to debug pre commands is not the debug console of remmina which is awefully quiet about anything related to the pre command, but rather to look at
conveniently i also saw, that those non-working pre-commands where blocked by apparmor!
after looking into the profile for this snap which can be found in
/var/lib/snapd/apparmor/profiles/snap.remmina.remmina i quickly found the source of the problem. Remmina tries to list any command one could possibly use in a pre or post script and lists them to be allwed to execute.. but it still tries to be restrictive nough that one can't harm the system with such a script..
the problem is: you can't simply edit this file and add
ssh to it, because it will be overwritten durnig the next update of the remmina snap.
the second issue is: i think it is pointless to try and limit a software that should be as powerful as remmina to execute stuff.. as long as it is not run as root we are still quite on the good side here.. so my simple and dirty solution was to switch this profile to
complain mode in apparmor. so it still logs everything but does not block anything anymore that remmina does.
aa-complain does not know anything about the snap profiles.. so i had to first symlink the profile definition from its original location into
/etc/apparmor.d so that i can then switch it to complain mode:
/var/lib/snapd/apparmor/profiles/snap.remmina.remmina aa-complain snap.remmina.remmina
and now FINALLY the above stuff was working as it should!