I've been using Tailscale for years but will likely not use this feature, even though I would like to. The fundamental problem with the approach really is that

I've been using Tailscale for years but will likely not use this feature, even though I would like to. The fundamental problem with the approach really is that connections are different over the tailnet and over the local network. Here is a specific use case that is painful: 1. There exists a cluster of machines, each with large amounts of locally attached storage. They are all on the same local network and connected with 10Gb (and likely soon 40Gb ethernet interfaces). 2. Each machine is individually on the same tailnet so they can be accessed remotely. 3. Remote users frequently need to move large amounts of data between machines. A user copying a few hundred gigabytes of data with "scp" is normal. 4. For performance reasons, it's preferred to avoid the Tailscale/wireguard overhead when copying data between adjacent machines in a rack. At this point, if I enable tailscale ssh for remote login, it appears that the problem of key management for connections between local machines (using ssh over the normal interface, not the tailnet) still remains, and in fact, the overall authentication configuration is more complex than it was before. What I would love to exist, and would make me instantly use this feature, is if the tailnet issued SSH certificates (probably injected into its own ssh-agent?), the existing tailscale SSH implemention worked just like it currently does (it's great!), AND I could manually configure servers to accept certificates issued by the tailnet. Then SSH paths like "laptop --> (over tailnet) --> server 1 --> (over local network) --> server 2" could be made to work transparently, for those machines that need it, and for regular users, it still "just works".