You are right, that would be the best option.
Unfortunately this would mean that i have to manually create one vault and one template for every server, which is pretty annoying. My setup is a bit complicated and i really need to be able to create new ssh setups programmatically. If i decide that russia needs 20 more tor bridges right now, i really don’t want to set them up manually…
One could script this, but only by using dom0 as the place to issue the “make new server stuff”. This is impractical as outlined in the linked post. For this i created a admin-vm.
However this admin vm cannot (and should not be able to) modify the policy what the qubes created should be allowed or not allowed.
All i could do is try to restrict access by policy tags (all ssh-clients are allowed to access all ssh-caults) in dom0 and dynamically set the internal split ssh configuration with randomized qube names. The only thing preventing ssh-client-4235123, that should only have access to ssh-vault-4235123 form accessing ssh-vault-11111111 is that it does not know the correct name. Default target would not work either because of this, creating much inconvenience for me 
. So much so, that i would opt to “allow all” in the policy. This would lead to me not needing to manually approve every request and consequently not being alerted to brute force attempts when not at the computer.
I thought about this, but was not able to come up with a clean minimal solution that would be able to handle all sorts of corner cases.
But thanks for pointing out the obvious, i will reevaluate my options with this approach and see if it might fit my use case despite the initial problems i faced when attempting this.