@brucexu_eth: Tailscale is absolutely amazing! Now all my servers and devices are connected via Tailscale, and I've enabled Tailscale SSH. Since then, I've basically never fiddled with Private Keys again, nor do I need to sync SSH keys everywhere. I just ssh root@ta…

X AI KOLs Timeline Tools

Summary

The user shares how they used Tailscale to configure access control and SSH policy to isolate internal and public servers, preventing lateral spread after a breach. By grouping devices with tags, they restrict public servers from reverse-connecting to personal devices, improving security.

Tailscale is absolutely amazing! Now all my servers and devices are connected via Tailscale, and I've enabled Tailscale SSH. Since then, I've basically never fiddled with Private Keys again, nor do I need to sync SSH keys everywhere. I just ssh root@tailscale-ip to log in. Hermes, deployed on one server, can also use Tailscale for cross-server monitoring, service deployment, and daily operations — very convenient. But recently I realized there's a risk: if a Hermes instance is shared with others or deployed on a public server and eventually gets compromised, under the original allow-all network policy, an attacker could laterally access my other servers, or even my personal computer in use. I just spent a little time configuring Tailscale Access Control, and that solved the problem. The approach is straightforward: first use tags to divide devices into personal and public-server groups, then configure network Grants and Tailscale SSH Policy separately. This time I directly created a temporary scoped OAuth client for Hermes, letting it read and back up the original policy, generate new rules, call the Tailscale API to verify, then submit the configuration, and finally run real connection tests from both directions. If doing it manually, it's not too complicated either — the core is to clearly define which tags can actively access which. My current rules are: - personal devices can connect and SSH to each other - personal can connect to public servers - public servers cannot reverse-connect to personal - public servers cannot laterally connect to each other During the process, I also hit a pitfall: Tailscale's network Grants and Tailscale SSH are two separate permission layers. Just because the network works doesn't mean SSH can log in — both sides need to be configured. This way, Hermes deployed on my internal server can still act as a management node and jump box to control other servers, but if the Hermes deployed on a public server has issues, the blast radius is limited externally — no lateral spread through the Tailnet. So awesome. Previously, this kind of internal network management, identity authentication, and permission isolation was usually infrastructure that only big companies would seriously set up. Now Tailscale has democratized it for individuals, and it's free to use. If you haven't started using it, do it now!
Original Article
View Cached Full Text

Cached at: 07/11/26, 11:23 AM

Tailscale is absolutely amazing!

Now all my servers and devices are connected to Tailscale, with Tailscale SSH enabled. I’ve basically stopped messing around with private keys or syncing SSH keys everywhere. I just go straight with ssh root@tailscale-ip to log in.

Hermes, deployed on one of the servers, can use Tailscale to monitor, deploy services, and do daily ops across servers — super convenient.

But recently I realized there’s a risk: if a Hermes instance is shared with others, or deployed on a public server, and it eventually gets compromised, under the old allow-all network policy, the attacker could pivot horizontally to my other servers, or even to the personal computer I’m using right now.

Just spent a bit of time configuring Tailscale Access Control, and that solved the problem.

The approach is straightforward: first, use tags to group devices into personal and public-server, then configure network grants and Tailscale SSH policy separately.

This time I directly created a temporary scoped OAuth client for Hermes, had it read and backup the existing policy, generate new rules, validate them via the Tailscale API, then submit the configuration, and finally run real connection tests from both directions. Manual configuration isn’t hard either — the core is just clearly specifying which tags can actively connect to which.

My current rules are:

  • personal devices can connect and SSH to each other
  • personal can connect to public-server
  • public-server cannot initiate connections back to personal
  • public-server instances cannot connect to each other

One gotcha along the way: Tailscale’s network grants and Tailscale SSH are two separate layers of permissions. Just because the network layer allows traffic doesn’t mean SSH login will work — both sides need to be configured.

Now, Hermes running on my internal servers can still act as a management node and jump box to control other servers. But even if a Hermes on the public internet gets compromised, the impact is contained externally — it won’t spread horizontally through the Tailnet.

So amazing. In the past, internal network management, identity authentication, and permission isolation were infrastructure that only big companies would seriously build. Now Tailscale brings it down to the individual level, and it’s free.

If you haven’t tried it yet, get on it!

Similar Articles

@FeitengLi: Here's how I use it: 1. Mac Mini is not carried around—it stays at home in the living room with Tailscale enabled. When outside, I use Mac's built-in Screen Sharing to connect directly via the Tailscale IP (also use Cloudflare Zero Trust as a backup in case Tailscale is accidentally disconnected, e.g., if I manually turn it off).

X AI KOLs Timeline

Introduces a method to remotely connect to a home Mac Mini via Tailscale and Screen Sharing for a development environment, using tmux to maintain sessions and a consistent setup.

@brucexu_eth: Damn, my internet just went down out of nowhere, all the VPN nodes were down. I messed around for a while, including trying to use Tailscale exit node, and I was just about to get it working when I realized I logged into Tailscale with Google. It was a dead loop, wtf. Finally, @draken_zeng recommended E…

X AI KOLs Timeline

Recommended an open-source project called edgetunnel, an edge computing tunnel decryption based on Cloudflare Workers/Pages, which can serve as a free replacement for paid VPN services.

@PierceZhang34: Practical Guide to SSH Tunnels. Although I use SSH tunnels daily, it always takes a while to recall the correct command. Should it be a local or remote tunnel? What parameters are needed? Is the port order local:remote or the reverse? Through a series of experiments, the author created a visual cheat sheet. Link: http:…

X AI KOLs Timeline

This tutorial provides a visual cheat sheet and practical labs for SSH local and remote port forwarding, covering common use cases like accessing private databases and exposing local servers.

TailMux

Product Hunt

TailMux allows users to connect to multiple Tailscale tailnets simultaneously without switching or using a VM.