What's Next? (Connecting VNC to dom0)

[colony...@pm.me]

The server is a headless lights-out deal, and actually what I'd like to do is connect x2go to dom0.  But I do not know enough yet so tried to connect VNC.

https://www.qubes-os.org/doc/gui-domain/#vnc-gui-domain-sys-gui-vnc

    A VNC server session is running on localhost:5900 in sys-gui-vnc.

This is clear enough, although I have to take its word for it since a terminal in sys-gui-vnc will not accept my username for unknown reasons.

I really want to set its port to 5904 in this instance though, and I presume this would be done in the template, although that would mean it’s set that way globally which is undesirable.

    In order to reach the VNC server, we encourage to not connect sys-gui-vnc to a NetVM but rather to use another qube for remote access, say sys-remote. First, you need to bind port 5900 of sys-gui-vnc into a sys-remote local port (you may want to use another port than 5900 to reach sys-remote from the outside). For that, use qubes.ConnectTCP RPC service (see Firewall. Then, you can use any VNC client to connect to you sys-remote on the chosen local port (5900 if you kept the default one). For the first connection, you will reach lightdm for which you can log as user where user refers to the first dom0 user in qubes group and with corresponding dom0 password

This is indecipherable.

Running sudo qubesctl --all state.highstate took a long time, until the first stage timed out as unable to reach the network. No wonder, /etc/resolv.conf symlinks to a non-existant file under /run. Have no idea why.

The remaining stages completed though and for some reason it chose the Fedora40 template even though I’ve set Debian as the system default.

No idea what to do now.

[Demi Marie Obenour]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

My recommendation is:

1. Create a _trusted_ VM to run WireGuard or a key-protected onion
service.
2. Allow that VM (and _only_ that VM) to connect to sshd in dom0 via
qubes.ConnectTCP.
3. Forward anything you need over the SSH tunnel.
- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmalUFEACgkQsoi1X/+c
IsH3iBAAsbehCJJcLj0RIc7A6Gn4JyLT0BBp+SsHea7xfep4+sTun2MziLf9TwF+
EtnFUkW5t2PQychQMRGQASgqmSM66v907vKfb3q0ustwNB87PtSh+FB7tfD3Fp3u
5XQTQ0wvYRixAV9HGUaAorX3Uy5YF4wCirodBkcxOv+PrXxFQSxId4yV980oTENB
Hq1wiFLDVNO775f/0ZZ0ZzYUc3EyVrpRX7dLEHHvLR1x1+vv1oCGRltwhjkWSMDI
SfXu/TWeRbiHSLpuUMJiDc4gsioS+acjnQWR/GM4W3JcpPBCqf0WCQJmD7kdXKEK
Q6cqkPlgp51XCuVafG1pWqJANtDDnIwZRd6iBlvv4vEvL2qxLdcYjZIFraSX/Smv
APUD7vjhvUj6YzGCVsI0tsjS6ADaRsypwKByQn3UC9A1fTde0cELsrWIbhrpCyjV
R7DjBDKswWulvtIeWEQMuRkqJrXsYxF2+tgfSsZogR2tzqP7/YfLfey20ueVuBLo
ewqBfhQnXgzFmAFksqY2R13ee0NBoEltc75PLkKxtZqPKmmJcA0WE1xtAe0fmj9r
jqiQD5SdZCAsNZ5FVMIwBEc8cX30CHmtXD+A1K6k4YvojuYVplPYBj7u5+AoHRxb
rjh1wf/68Bffm8iZX6oy6jxROV2wqnYHJwSFRKK+0hLmxtdSIfI=
=pJOH
-----END PGP SIGNATURE-----

[colony...@pm.me]

On Saturday, July 27th, 2024 at 12:53, Demi Marie Obenour <de...@invisiblethingslab.com> wrote:

>
>
> On Thu, Jul 25, 2024 at 02:09:02PM +0000, Qubes OS Users Mailing List wrote:
>
> > The server is a headless lights-out deal, and actually what I'd like to do is connect x2go to dom0. But I do not know enough yet so tried to connect VNC.
> >
> > https://www.qubes-os.org/doc/gui-domain/#vnc-gui-domain-sys-gui-vnc
> >
> > A VNC server session is running on localhost:5900 in sys-gui-vnc.
> >
> > This is clear enough, although I have to take its word for it since a terminal in sys-gui-vnc will not accept my username for unknown reasons.
> >
> > I really want to set its port to 5904 in this instance though, and I presume this would be done in the template, although that would mean it’s set that way globally which is undesirable.
> >
> > In order to reach the VNC server, we encourage to not connect sys-gui-vnc to a NetVM but rather to use another qube for remote access, say sys-remote. First, you need to bind port 5900 of sys-gui-vnc into a sys-remote local port (you may want to use another port than 5900 to reach sys-remote from the outside). For that, use qubes.ConnectTCP RPC service (see Firewall. Then, you can use any VNC client to connect to you sys-remote on the chosen local port (5900 if you kept the default one). For the first connection, you will reach lightdm for which you can log as user where user refers to the first dom0 user in qubes group and with corresponding dom0 password
> >
> > This is indecipherable.
> >
> > Running sudo qubesctl --all state.highstate took a long time, until the first stage timed out as unable to reach the network. No wonder, /etc/resolv.conf symlinks to a non-existant file under /run. Have no idea why.
> >
> > The remaining stages completed though and for some reason it chose the Fedora40 template even though I’ve set Debian as the system default.
> > No idea what to do now.
>
>
> My recommendation is:
>

> 1. Create a trusted VM to run WireGuard or a key-protected onion
> service.
> 2. Allow that VM (and only that VM) to connect to sshd in dom0 via

> qubes.ConnectTCP.
> 3. Forward anything you need over the SSH tunnel.

> --
> Sincerely,
> Demi Marie Obenour (she/her/hers)
> Invisible Things Lab

Ty. I'll try but do not know the basics of making such connections, since the Qubes machine is in a basement and I have to haul down a monitor, keyboard, and mouse to do anything, standing up. Not the best conditions for exploring and learning, but it's what I have.

[colony...@pm.me]

> My recommendation is:
>
> 1. Create a trusted VM to run WireGuard or a key-protected onion
> service.
> 2. Allow that VM (and only that VM) to connect to sshd in dom0 via

> qubes.ConnectTCP.
> 3. Forward anything you need over the SSH tunnel.

> --
> Sincerely,
> Demi Marie Obenour (she/her/hers)
> Invisible Things Lab

Well, here's a question: I'd cloned the firewall qube for my wireguard server, but that's clearly not what you said.

Apparently there's some distinction between a VM, a template, and a qube, which I haven't found in the docs. Maybe making a VM would allow me to make wireguard settings persistent? How is a VM beneficial over making a qube? A template? Are there drawbacks to a VM?

I still don't get how you set up a daemon by basing a qube on a template. Settings can't be persistent in a qube, but a template is in effect a whole OS. On one machine I don't want to install all my server software in template debian, just to spin off qubes from it. Do I have to clone template debian for each individual service?

I've tried to understand this but it doesn't address my questions: https://dev.qubes-os.org/projects/core-admin/en/latest/qubes-vm/index.html