hi, i looked around and searched for threads but didn’t find anything too relevant (not interested in vnc or rdp)
can i setup ssh to dom0 from LAN, then use salt or qvm-run to manage appvms from dom0? i don’t need GUI, but shell is nice (qvm-run -p APPVM bash might not be best experience)
how risky is this? there are no targeted attacks, will only be used on small home network, i suppose it is as safe as ssh is and the appvm connecting?
and i will ssh from another qubes machine from a trusted appvm
is it supported and is there maybe community guide to set it up?
You would do better to set up an admin qube, and ssh in to that.
This would give you better control over what is exposed to the network,
and what capabilities are available there, while minimising the major
risk in exposing dom0.
The capability for this was first detailed almost 10 years ago, but is
still little known. Read the original post here
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Thanks to you and @qubist for confirming that this is a sadly neglected
feature of Qubes. I provided a link to the first description in my post.
It is not possible to have a second dom0. It is possible to have a
second/third/fourth admin qube. This is a qube that you create and which
you configure to be able to manage and control aspects of your Qubes
system. These qubes are not of KLASS AdminVM.
This is not necessarily the same as a management qube. Check the
glossary. (The original new post was not clear about this.)
Once you have set up such a qube, you can access it from the network.
You specify in policy files what qubes you want to control, and exactly
what you want to be able to do with them. (At one end would be complete
control and access to all qubes on the system, at another, limited
access to a single qube.)
Naturally, you do not need to make the admin qube externally available
at all. This is useful when working with new salt or ansible features
that are not yet ready for deployment in dom0.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
What about e.g. a service running in dom0 that monitors for specific requests generated by the “admin qube” and executing them? Seems simpler to me (assuming one can write the short scripts about it). It can be as simple as a text file in the “admin qube” that dom0 reads periodically.
Speaking of all that, can you explain or show a link to explanation how exactly dom0 is made network-less?
i will try later, this machine is not so important, and worst case the dom0 should be no more vulnerable than openssh-server and the appvm which i connect from
the appvm i trust, openssh-server too, and no one on my network will attack (can even just allow the other qubes machine to connect)
I have not looked at the code of qrexec-daemon, so I can’t say what it does but I doubt it monitors for any separate/second “admin qube” since one does not exist in default Qubes.
I don’t think it would matter for the daemons as they (1 for each qube) are supposed to handle all qrexec calls. If admin qube (functionally admin, not of class admin) uses qrexec (with default qubes-core-admin-client it does), all admin calls should eventually go through a qrexec daemon:
An exception are calls made by dom0, e.g. qubes-core-admin-client tools with app of class QubesLocal (calling local qubesd socket). They bypass the qrexec part of the diagram and speak the elusive qubes socket API directly. I think. Or I may be mistaken and they just use a weird dom0-specific version of admin API that always sends source (just string “dom0”) as well as destination.
If you mean qube of class AdminVM though, I don’t know… I don’t have a mental image of what non-dom0 AdminVM is or whether it is even possible. For example, if we have a second AdminVM, does it mean it is not domU? According to xen it can’t be that. But then does it mean dom0 is running qrexec daemon instance for that qube? Doesn’t this make it just a normal qube?
