Doesn't this require configuration at the end user, so you could just as easily ProxyJump or use a different port?
It's a nice solution but I've been looking for something more transparent (getting them to configure an SSH key is already difficult for them). A reverse proxy that selects backend based solely on the SSH key fingerprint would be ideal
That's all true, but juggling connections based on key fingerprints would also require users to have different keys for different containers -- which is good practice, but I've found that it's equally difficult for users unfamiliar with ssh to set up and properly manage more than one key, and it's equally easy for users familiar with ssh to manage multiple client configs.
That and ProxyJump both also require the container-host to negotiate ssh connections, which is... fine, I guess? But the port knocking approach means that the only thing the container-host is doing is port forwarding, which gives it like half an extra point in my calculus.