Skip to main content
Oct 1, 2026 1:49 PM UTC
Question

SSH Bookmarks hostnames don't support Hyper-V VM name declaration, which use a slash

Hyper-V SSH allows connecting via SSH to a Hyper-V VM (Windows or Linux) without using the actual network, through an in-memory socket. (See here) This is especially useful for disconnected VMs or ones behind a virtual NAT with other VMs.

This is done by running something like:

hvc.exe ssh John@VMName

...where “John” is the VM’s internal user and “VMName” is the virtual machine’s name in Hyper-V, not the hostname. HVC then sets up the virtual socket and eventually runs the real ssh.exe binary and connects it to that socket.

The VM is presented to the SSH binary with the name “hyper-v/VMName”, which you can then use in your SSH config file normally:

Host hyper-v/VMName
User John
IdentitiesOnly yes
IdentityFile ~/.ssh/vmname.pub

However, the way SSH Bookmarks are implemented in 1Password means the generated configuration file uses the hostname extracted from the URL field:

ssh://hyper-v/vmname

Because the / (obviously) means the next part is a path, it gets dropped, and the generated name is “hyper-v”. If you try to escape the slash as %2F, it just comes out as Host hyper-v%2FVMName.

Right now the 1Password SSH Agent’s default behavior of listing all keys works, but if you have too many keys or the VM has a low attempt count, you cannot use the auto-generated SSH config file.

Could you add a special case for ssh:// URLs like those? It could be either:

  1. ssh:// URLs with percent-encoding get resolved before spitting out the config file (Or when doing live lookup by the SSH agent); or
  2. ssh:// URLs can special-case the “hyper-v/” prefix on Windows (and visually when syntax highlighting on other platforms) to support this. It could also instead launch hvc.exe ssh VMName in those cases (though it usually requires elevation), but that’s less important, since hostname-matching and ssh_config generation is what I’m trying to fix here.

1 reply

1P_Gem
1Password Alum
Oct 8, 2026 8:33 AM UTC

Hi ​@SmileyBarry, thanks for bringing this to our attention!

I’ve filed this with the team so we can explore ways to better support this use case.