XY: On a 4K screen, even double-sized fonts of a console-only standalone look way too small and I have no other choice but to access it through an AppVM.
I know how to do this using a firewall rule - it works fine. I am trying to do it “the Qubes way” though. So, I am following the doc.
In dom0 in /etc/qubes/policy.d/30-user-networking.policy I add:
qubes.ConnectTCP * B @default allow target=A
In B:
user@B:~ > qvm-connect-tcp 22:@default:22
Binding TCP '@default:22' to 'localhost:22'...
However, SSH to A does not work:
user@B:~ > ssh -vvv <Qubes_IP_address_of_A>
OpenSSH_9.2p1 Debian-2+deb12u3, OpenSSL 3.0.14 4 Jun 2024
...
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
No connection.
I also monitored sudo journalctl -f in both dom0 and B - nothing, no messages.
You can change the font size in xterm:
Ctrl + Right mouse click in the xterm window → enable TrueType fonts
Ctrl + Right mouse click in the xterm window → enable Enormous
you need to ssh localhost as you expose Qube A port 22 on Qube B port 22, so you need to connect to localhost port 22
This gives:
Request refused
2024/10/08 15:49:27 socat[1112] E waitpid(): child 1113 exited with status 126
kex_exchange_identification: Connection closed by remote host
Connection closed by 127.0.0.1 port 22
can you try to run the qvm-connect-tcp command as sudo ? As socat tries to bind on port 22, it should be forbidden for non root users because the port is under 1024.
If that doesn’t work better, try to open the port 22 in the firewall, I don’t think it should create troubles on localhost but maybe
can you try to run the qvm-connect-tcp command as sudo ? As socat tries to bind on port 22, it should be forbidden for non root users because the port is under 1024.
But the doc clearly shows it should be done as user? I don’t see any error message when running qvm-connect-tcp as user. I hope you can clarify your idea.
user@dom0:~ > qvm-console-dispvm --autostart A
$dispvm:default-mgmt-dvm: Start failed: XML error: maximum memory size must be equal or greater than the actual memory size, see /var/log/libvirt/libxl/libxl-driver.log for details
Traceback (most recent call last):
...
user@dom0:~ > qvm-prefs debian-9 | grep mem
maxmem - 16384
memory - 8192
Is A - a qube based on a template or your standalone qube not based on a template?
The qvm-connect-tcp only works between qubes based on a template (with Qubes tools installed).
I’ve tried in between two app qubes based on a debian-12-xfce template and it worked for me even without sudo.
The error is about disposable qube based on a default-mgmt-dvm disposable template so check the default-mgmt-dvm memory settings.
Is A - a qube based on a template or your standalone qube not based on a template?
Qube A is a standalone based on stock Debian 9 (not template).
The qvm-connect-tcp only works between qubes based on a template (with Qubes tools installed).
I guess this is the key factor which the doc does not mention. Thanks for the tip!
I’ve tried in between two app qubes based on a debian-12-xfce template and it worked for me even without sudo.
Thanks for this info.
The error is about disposable qube based on a default-mgmt-dvm disposable template so check the default-mgmt-dvm memory settings.
Oh, indeed! I have been getting this error recently for many qubes. It seems the most recent updated messed up many qubes and all “problematic” ones now have maxmem=memory and memory balancing ON. Not sure why this is happening.
No, sorry, I don’t know how… I keep my templates up-to-date and never had to install an old version in a newer Qubes release.
On the other hand, as you wrote in the first comment, you know how to tweak the firewall and allow direct SSH to this standalone. I’d call that a win and spend my energy in pursue of other quests.
)