Remote Qubes?

Vael_S · August 18, 2026, 6:51am

Howdy,

Is there any way that a guest can be run remotely as the GUI interface through an SSH tunnel instead of being run locally?

That way can have multiple users logged in to the remote system at one time and do things on the same guest. It would be run on a virtual system, but all the graphical stuff would be handled on the remote machine as the GUI for Qubes would be there.

I know that it would be something that would happen during boot of the guest to use a remote system as essentially remote desktop on each window to the current window manager.

Not thought about yet? Not done yet? Could it be done?

vr2024 · August 18, 2026, 7:03am

The remote qube type was introduced as an experimental feature in R4.3 - See

and

github.com/QubesOS/qubes-issues

Design for "remote" qube type

opened 04:27PM - 06 Mar 24 UTC

closed 05:14PM - 17 Jul 25 UTC

marmarek

C: core release notes P: default targets-4.3

[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/) #…## The problem you're addressing (if any) As an initial step for Qubes Air, there needs to be a way to execute qrexec call into a qube that is running on another system. ### The solution you'd like Create a new "remote" qube type. Such qube can be a target for a qrexec calls, but otherwise have little real properties. It should be flexible enough so the actual remote target can be on another qubes sytem (a qube there) but can be also a non-qubes VM (as long as has appropriate software installed) or not a VM at all (for example, a raspberry pi). The qrexec connection to remote qube should be performed by a separate "proxy" qube, using a qrexec service for that. One proxy may be used for multiple remote qubes, but there can be also multiple proxy qubes on one system. The proxy qube is responsible to enforce qrexec connection properties, especially confidentiality and integrity (by using some encrypted channel). Choosing specific crypto solution is out of scope for this ticket (and in fact, different solutions may be used in different cases). Similarly, remote qube should be able to also initiate qrexec calls. Those will be received by the proxy qube, and then forwarded to requested target (which then goes through usual policy evaluation). The qrexec protocol should be extended to allow the proxy qube executing calls on behalf of remote qubes. The proxy qube should be allowed to identify as qubes for which it works as a proxy. It's yet to be determined what should happen if it tries to pretend to be some different source, possible options include: refuse the call (IMO preferred), treat the call as from the proxy itself, introduce another source type like "unknown source" (that includes information from which proxy it was received). And finally, there should be some registration mechanism that allows the user to conveniently add new remote qubes. Besides setting basic remote qube metadata (to be established what exactly) and which proxy to use, it should also allow configuring transport mechanism for the proxy in the same step (likely by having a field for some proxy-specific opaque data). One idea for interactive remote qube registration is something like magic-wormhole (so, ask the user to type some passphrase on the other device to establish a secure channel for the actual registration protocol). The point of this issue is to design all relevant interfaces, including: - what properties a remote qube should have - how proxy qrexec service should look like (arguments, payload, how the information about the actual proxied call is transferred) - how proxy qube should be configured, where should the connection-related settings be stored (things to consider: should disposable proxy qube be supported? but also, avoid sensitive data in qvm-features etc) - what information proxy qube should receive, how exactly the remote qube setup should work (what services are involved, what formats they use) - how receiving qrexec call should look like, how the information on the original (remote) qube should be transferred - are there any qrexec policy changes necessary? ### The value to a user, and who that user might be At the initial stage, this will allow making qrexec calls between specific qubes on different physical machines. This should allow for example copying files via qvm-copy to another system.

For the ‘big’ picture you can read

Vael_S · August 18, 2026, 10:41am

Okay, so it’s not going to be what I’m after or what I’ve asked about.

Any idea when what I asked about may be instantiated or put into action?

Will this “Qubes-Air” be able to change to what I’m asking about in my original post?

unman · August 18, 2026, 11:17am

Not quite what you are thinking of but I have fairly minimal qubes that
do run GUI interfaces to remote qubes over ssh.
The remote qube runs vnc-server, and the local qube runs vnc over ssh
tunnel. Straightforward to set up and easy to use.

I’m not sure about the “multiple users doing things on the same guest”.
Qubes is not designed to be used as a multi-user system. I have experimented
with running distributed file systems, and NFS: both work, but I’m not
sure they will give you what you want.

Despite your comment I think that Qubes Air would be a good start
for exactly what you want to do. You would have to put the work in to
making the remote qube a multi-user system. I’d be interested in seeing
how you do that.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

qubist · August 19, 2026, 4:17pm

I may be missing the point here but:

Why not use one qube per user instead of having multiple users doing things on the same qube? The latter would hardly provide the benefits of Qubes.