USB devices in whonix-ws

Are additional steps needed to get USB devices working in a Whonix workstation VM? I am able to get a USB hardware security key and standard USB drives working in both Debian and Fedora VMs but they don’t work in Whonix.

I use a hardware password/2fa/PGP key that functions like a hybrid keyboard/security key. It fills in login fields, calculates 2fa codes, etc. It doesn’t work in Whonix.

Likewise, when I attempt to attach a standard USB drive to Whonix, I can see the drive in Thunar and the info at the bottom of the window says the drive is “mountable” - but it’s not clear how to access it. When I launch thunar-volman-settings and select “mount removable media when inserted” and “mount removable drives when hot-plugged” and reattach the drive, the drive remains unmounted.

This appears to be a Qubes issue.

“Qubes-Whonix isn’t different in this regard from a Debian based VM in Qubes. Qubes-Whonix has no special code that changes anything related to keyboard.” (my USB security key functions as a keyboard)

This problem still persists and I really need to get it working. Does anyone have any suggestions?

To further clarify… I am able to mount USB drives to my whonix workstation with no problem. I am able to use my USB HID device (a hardware security token that is seen as a keyboard by Linux systems) in other VMs but it does not work in my whonix workstation. sys-usb makes the connection to my whonix workstation with no problem. The whonix workstation also seems to acknowledge the connection (as per journalctl logs) but there is no output from the HID device in the whonix workstation VM.

Patrick @ whonix says that there is no special code or configuration to prevent USB keyboards from working inside of whonix and believes it to be a Qubes issue.

The manufacturer of the HID device recommends installing it as a keyboard directly in dom0 but I don’t want to do that for obvious security reasons - not to mention that the USB passthrough works just fine in most of my VMs.

Is there anything that might be causing this hangup? My workstation is not called “anon-whonix”. Perhaps there is a config file somewhere that expects that name for whonix workstations? There are udev rules for the device that are in sys-usb. Those are enough for functionality in other VMs. I added the same rules to my whonix workstation but that didn’t help either.

hmm. :confused:

English is not my first language, but did you try to mount it with sudo? Or to start thunar with sudo and try to access it? Please apologize if this is silly suggestion - just ignore it, but I had similar problems and that was how I resolved it.

Thanks for the suggestion. Your English is quite good actually.

I ran sudo mousepad from the terminal. Mousepad opened with a warning that I was using the root account and I might “harm my system”. I ignored that, connected my USB HID device from sys-net and it still did not generate text in the mousepad window. :confused:

Thank you. I meant on my English regarding arguably false reading of your English - if I properly understood what you wrote.

So, you resolved the initial problem with attaching USB drives to whonix-ws (how?). Is the HID device seen with lsusb in whonix, after attaching? sudo dmesg significant warnings after attaching? Did you try other ports/controllers? Do you have PS/2 port? If yes, would it make sense to connect to it via usb2ps2 adapter and try? Did you try to clone and then rename the clone to “anon-whonix” and then to attach the HID?

These are all wild guesses, but maybe it’ll give some idea to a someone more competent than me…

Patrick has asked that any Whonix questions be directed at the Whonix
forums, where they are more likely to be seen and dealt with.
There is a specific forum for Qubes-Whonix.

PatrickWhonix ™ developer

Apr '21

Qubes issue.

Not Whonix issue.
Qubes-Whonix isn’t different in this regard from a Debian based VM in Qubes. Qubes-Whonix has no special code that changes anything related to keyboard.

I haven’t seen anywhere that Qubes requires a USB keyboard to be connected to any specific VM. (Excluding USBVM.) Or keyboard support being VM specific.

There please contact Qubes support. See:

What to post in this Qubes-Whonix forum and what not.

@enmus beat me to it … (thank you enmus)

Patrick said this is a Qubes issue.

I guess unman should dig through his emails in order to find out that you already posted link to the whonix topic stating this, so I tried to save everybody’s time, thus filling the empty space and providing enough additional info before someone suggests something more solid, comforting you since it’s obvious how important this is to you.

@enmus lsusb shows the device mounted. sudo journalctl -b looks almost identical to my Debian log of the same device attaching (the device works in Debian VMs). The only difference in the logs (besides working properly) is that MTP-probe ran in the Debian VM and made specific reference to the /dev and /sys device paths. However, the same directories were created in the whonix VM too.

And my other wild guesses are senseless to try? Is the device connected through xHCI controller, which Qubes sometimes doesn’t like?

It’s a USB device… kinda like a Yubikey.



Thanks for that. Very helpful.

A link from April 2021 about a USB keyboard is not particularly
relevant to another USB device, and Patrick asked this in November 2021:
“So I as maintainer of Qubes-Whonix would prefer if everything directly
specific to Qubes-Whonix or Whonix should be posted in Qubes-Whonix
forums at or Whonix forums at

Since the key works as expected in Debian and Fedora qubes, but not in Whonix,
the problem seems likely to be specific to Qubes-Whonix.

I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
1 Like

Well, yeah. On the surface, that seems perfectly reasonable. But what is a user to do when both teams are either pointing the finger at the other or shrugging their shoulders? Not to mention one of the first times I used this key was on a VBox version of Whonix (inside Mac or Debian… can’t remember) and it worked just fine. That is another reason for me to suspect that it is related to Qubes.

I don’t have the understanding that many here do of the Qubes implementation of Whonix, but that’s my point - how else am I supposed to know about possible factors if I don’t ask? And when the lead developer of Whonix says “Qubes-Whonix has no special code that changes anything related to keyboard. Please contact Qubes support.” what would you do?

I am posting here because it seems that there could be unknown factors on the Qubes end that might be causing this problem. The most obvious is the manner in which dom0/qrexec manages the attachment of the device to whonix via sys-usb. From my admittedly uneducated perspective, that seems like the most obvious source of the trouble. I have no idea. I’m not even sure how to troubleshoot such a thing.

And, of course, there could be some issue with the device itself. What if the device developers cut some corner when writing the firmware? Both Qubes and Whonix might be doing everything right but it doesn’t work. But again, I have no idea if that’s the case if I don’t start eliminating other possible causes. I’m still waiting to hear back from the developers of the key.

Above all, I sincerely appreciate your patience and understanding as I sort this out.

Here is another Qubes user with the same problem a year and a half ago. Apparently unresolved. The only concrete advice he received from the Qubes team was that his Whonix template likely doesn’t have the necessary Qubes packages to handle USB passthrough (not unlike minimal templates requiring additional packages). Hence, a “Qubes issue”… or at least something resolvable from the Qubes end of the spectrum.

Do you know of any possible packages or configurations that might make Whonix capable of receiving a USB HID device?

Keep in mind that USB storage devices are able to passthrough without any problem. The problem seems to be specific to HID passthrough. Is it possible that Whonix assumes it is a USB storage device and is configuring it improperly? Are there any Qubes packages that might address this? qubes-usb-proxy and qubes-input-proxy-sender seems to address something else entirely.

@necker are you using a notebook (primary keyboard does NOT depend on USB)? If so, you can triage your issue by creating a whonix workstation qube, making it a HVM and assigning one of your USB controllers to it. When you start that qube it now has direct access to that controller. If it works then after plugging your key into a port belonging to that controller, your problem has something to do with Qubes OS. If it doesn’t it’s specific to Whonix.

@sven Actually, given the feedback from a Qubes dev regarding this very issue, that wouldn’t really prove anything one way or the other - because the suspected cause of the problem is that certain Qubes-specific tools are not installed on the Whonix template to manage USB passthrough. A standalone would be using the same template.

Although I think the problem is that the USB HID passthrough is being seen as a storage device by whonix due to a lack of Qubes-specific configuration in the whonix template. That would be a problem with all types of VMs based on the same template.

Another thought… the .vmx file for VMware virtual machines needs to be tweaked with “allowHID” for USB keyboard/HID devices to work properly. I’m wondering if there is a dom0 configuration or template tweak that would serve to do the same thing.

Yup… so like I thought, it doesn’t work in the standalone but that doesn’t address the problem suspected by the Qubes dev here [] If it’s a lack of Qubes configuration in the Whonix template, the problem will be there regardless of the type of VM I create.

Also, as I mentioned, VMware has a way for .vmx files to be configured to allow HID connectivity via USB. VirtualBox also has a way to allow certain USB devices to be used as a keyboard. It follows that Qubes should have some way to allow USB HID passthrough on standard templates… at least that is what Patrick @ whonix seems to think. It’s something that is usually handled by the platform that handles the virtualization, not Whonix per se.