Write your first grant

Start with one narrow connection: your user may reach TCP port 22 on the lab server.

One rule, one port, one destination. If this works, you understand the whole model. Everything after is repetition with different values.

Prepare the tag

Use your real tailnet identity as the source and a server tag as the destination. Tags need owners before they can be assigned, so declare that first in the policy file:

{
  "tagOwners": {
    "tag:server": ["flavio@example.com"]
  }
}

Then tag the lab server, either from the admin console machine list or from the machine itself:

sudo tailscale up --advertise-tags=tag:server

Once tagged, the node’s identity is its role, not your user account.

Write the grant

The ip capability names the protocol and port. Add this to the grants section:

{
  "grants": [
    {
      "src": ["you@example.com"],
      "dst": ["tag:server"],
      "ip": ["tcp:22"]
    }
  ]
}

Replace you@example.com with your identity. Save from an existing recovery session so a policy mistake does not remove your only management path. If you edit the policy over tailnet SSH and the edit breaks tailnet SSH, you have locked the door with the keys inside.

Verify both directions

Adapt the identity, define the tag owner, tag the server, and verify SSH succeeds while an unrelated test port remains blocked:

ssh ubuntu@lab-server           # should connect
nc -zv -w 3 lab-server 5432     # should time out

The second command matters as much as the first. A policy that allows what you want proves nothing until you also confirm it blocks what you did not grant. Port 5432 stands in for anything else running on the server: nothing granted, nothing reachable.

If SSH fails after the change, check the exact spelling of your identity and the tag. A typo in src silently matches nobody, and the deny-by-default model does the rest.