Hi! (I hope, this is the right list for my question. I already posted it to the debian-user ML, but someone pointed me to this list. Alas, there is no virt-manager ML anymore)

In our network we have several Debian systems working as VM host running QEMU+KVM based virtual machines. I usually use virt-manager on my workstation as GUI to connect to the VM host, manage the VMs and also to connect to the VM console if needed. To connect to the VM host I use SSH with public key authentication. On the commandline with virsh this looks like this (example): andreas@ws1:~> virsh -c qemu+ssh://root@maxwell/system Welcome to virsh, the virtualization interactive terminal. Type: 'help' for help with commands 'quit' to quit virsh # So far, so good. Recently I decided to increase our internal network security standards and activated 2FA with time-based one-time passwords on several hosts. (The idea is to eventually have 2FA for SSH for all users on all hosts in our network) This works very well and even quite comfortable with authenticator-apps on my smartphone or KeePassXC on my workstation generating the TOTP. Example: andreas@ws1:~> ssh root@mach Enter OTP: Linux mach 6.1.0-32-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.129-1 (2025-03-06) x86_64 root@mach:~# So for a successful SSH connection I now have to enter a valid TOTP (generated by the authenticator app) and then it connects. Connecting to the host with virsh on the commandline also works in a similar way: andreas@ws1:~> virsh -c qemu+ssh://root@mach/system Enter OTP: Welcome to virsh, the virtualization interactive terminal. Type: 'help' for help with commands 'quit' to quit virsh # All fine. Works as designed... When I use virt-manager to connect to the VM host, the GUI opens a dialog asking for the OTP and then connects, showing the list of all configured VMs etc. I can also open the configuration of a given VM, manage and change it. All fine, too... But when I try to use virt-manager to connect to the console of a specific VM, it doesn't work as expected. virt-manager opens a new window for the console, but also endlessly keeps opening password entry dialogs. As soon as I enter the current OTP and klick "ok", another dialog is opened, again asking for another OTP. And so on... (These are one-time passwords, valid for 30 seconds, which cannot be re-used) I can connect to the VM console with a SPICE viewer like remmina using SSH port forwarding like this: andreas@ws1:~> ssh -L 5906:localhost:5906 root@mach Enter OTP: root@mach:~# (where 5906 is the SPICE port for the VM in question) And then use remmina to connect to port 5906 on localhost. This gives me the SPICE console of the VM. Of course, this is not as comfortable as using virt-manager. But with virt-manager I haven't found a way to successfully connect to the VM console with 2FA in place. So, finally, my question: Did anyone on this list manage to use virt-manager to connect to a VM console using SSH with 2FA?

Thanks! - andreas -- Andreas Haumer *x Software + Systeme | mailto:andreas@xss.co.at Karmarschgasse 51/2/20 | https://www.xss.co.at/ A-1100 Vienna, Austria | Tel: +43-1-6060114

Hi Pavel! Thank you for your reply! Am 14.04.25 um 11:07 schrieb Pavel Hrdina: > On Fri, Apr 11, 2025 at 09:14:23PM +0200, Andreas Haumer via Users wrote: > > Hi! > > > > (I hope, this is the right list for my question. I already > > posted it to the debian-user ML, but someone pointed me to > > this list. Alas, there is no virt-manager ML anymore) > > Hi, > > virt-manager uses github discussions instead of ML. oh, well.. :-( I'll check if I can move this topic to the virt-manager project on github. But I hate web user interfaces for text-based communication... ;-)) [...] > > > > But when I try to use virt-manager to connect to the console of a > > specific VM, it doesn't work as expected. > > virt-manager opens a new window for the console, but also endlessly > > keeps opening password entry dialogs. > > As soon as I enter the current OTP and klick "ok", another dialog > > is opened, again asking for another OTP. And so on... > > (These are one-time passwords, valid for 30 seconds, which cannot be re-used) > > [...] > > Currently this is expected behavior as virt-manager opens new tunnel for > each spice connection. Not sure if it is possible to change or how > difficult it would be to use only single ssh tunnel. > A *single* tunnel for each VM would be ok. But does it have to open *several* SSH tunnels for a single VM console connection? > I have no experience with ssh+2fa but if ssh keys can be still used in > addition to password+totp users can copy their keys to the remote hosts > and avoid entering the password at all. > > If your goal is to use only password+totp and not allowing ssh keys > virt-manager will ask for the password several times. > The goal is to have SSH keys + TOTP for increased security. Rationale: SSH keys are stored in the users home directory and are static. If an attacker gains access to the users account in some way, he or she will get access to the SSH keys as well and thus have doors wide opened to all servers where SSH public key authentication alone is used. As we rely heavily on SSH for remote access to all servers in our network we consider this a security problem and thus we want to establish 2FA for all SSH connections in our network. We have this setup implemented purely with SSHD and PAM configuration settings. No fancy tricks or fairy dust needed. We have it running for several weeks now and it works very well. At least at the command line level between Linux systems, which is our major use case for this. Problems with virt-manager/libvirt connections to VM hosts now are some kind of collateral damage of this increased security, it seems, as these connections rely on SSH tunneling, too. But one has to differentiate: We would be fine if virt-manager asks for the TOTP on the first connection to the VM host. It would also be ok, if virt-manager again asks for a TOTP once(!) if user opens the virtual console of a single VM on the host. But currently if a user opens the virtual console of a single VM in virt-manager, it asks for the TOTP repeatedly in a very short time. And this is the real problem. It looks as if virt-manager opens several SSH connections for a single SPICE connection (I don't know the internal details of the connection between virt-manager and the VM host, though, so this might be a totally wrong guess)

This is very bad as in our setup TOTP keys can not be reused. One would have to wait 30 seconds for the next TOTP. And repeat this for several times in a row. This is not acceptable from a users POV. We could fall back to SPICE viewers like Remmina for VM console access. But it would be more comfortable if VM console access integrated with virt-manager could be used as well.

As it's just running the ssh command, could it just set some combination of the Control{Master,Path,Persist} options so that there is automatic connection sharing? Incidentally you could probably achieve the same thing without any code changes by doing something like this in .ssh/config: Host <vm-host>   ControlMaster auto   ControlPath ~/.ssh/control.%C   ControlPersist no That should share connections to the host until the last one is closed I think.

> Currently this is expected behavior as virt-manager opens new tunnel for > each spice connection. Not sure if it is possible to change or how > difficult it would be to use only single ssh tunnel. > A *single* tunnel for each VM would be ok. But does it have to open *several* SSH tunnels for a single VM console connection?

> I have no experience with ssh+2fa but if ssh keys can be still used in > addition to password+totp users can copy their keys to the remote hosts > and avoid entering the password at all. > > If your goal is to use only password+totp and not allowing ssh keys > virt-manager will ask for the password several times. > The goal is to have SSH keys + TOTP for increased security. Rationale: SSH keys are stored in the users home directory and are static. If an attacker gains access to the users account in some way, he or she will get access to the SSH keys as well and thus have doors wide opened to all servers where SSH public key authentication alone is used. As we rely heavily on SSH for remote access to all servers in our network we consider this a security problem and thus we want to establish 2FA for all SSH connections in our network. We have this setup implemented purely with SSHD and PAM configuration settings. No fancy tricks or fairy dust needed. We have it running for several weeks now and it works very well. At least at the command line level between Linux systems, which is our major use case for this.