CLOUDFLARE ZERO TRUST SSH PASSWORD
> Would be cool if somehow it could wedge into sudo auth so you could login as a a user and sudo without password if allowed by ACLs macOS support is kinda there (in git) but not entirely done and not included in the GUI builds.
CLOUDFLARE ZERO TRUST SSH WINDOWS
> I know it says it's linux-only right now, but is that client side or server only? Can my Windows users TailSSH into linux boxes? I think I've resolved myself to setting up Nebula for the server overlay network, and using Tailscale for physical users, with a traditional firewall bridging them.Īgain, Tailscale SSH looks very nice, job well done! Now that I'm typing this, I realize I guess we could just buy ~15-20 users despite needing only 10. I presume "custom" would help with that but I got no reply from sales. I'd like every box to talk over tailscale directly, as an overlay network, but servers I hope aren't users, that'd get expensive fast. I'd like to run it on ~120 dev+stg+prod VMs, with 10 people (devs, testers, ops). One thing that has prevented me from trying Tailscale, despite the great word on the street, is I can't figure out pricing, despite contacting sales. Would be cool if somehow it could wedge into sudo auth so you could login as a a user and sudo without password if allowed by ACLs, especally if I could add "check" to the ssh. I know it says it's linux-only right now, but is that client side or server only? Can my Windows users TailSSH into linux boxes? :-) This looks insanely cool, a couple questions:
Hey bradfitz, guy who previously had 32150 here. 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". 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. For performance reasons, it's preferred to avoid the Tailscale/wireguard overhead when copying data between adjacent machines in a rack.Īt 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. A user copying a few hundred gigabytes of data with "scp" is normal.Ĥ. Remote users frequently need to move large amounts of data between machines. Each machine is individually on the same tailnet so they can be accessed remotely.ģ. They are all on the same local network and connected with 10Gb (and likely soon 40Gb ethernet interfaces).Ģ. There exists a cluster of machines, each with large amounts of locally attached storage. Here is a specific use case that is painful:ġ. The fundamental problem with the approach really is that connections are different over the tailnet and over the local network. I've been using Tailscale for years but will likely not use this feature, even though I would like to.
0 kommentar(er)
