Require reauthentication for sensitive SSH

An accepted SSH rule can connect immediately. A check rule adds a recent identity check before the connection proceeds.

The threat here is not a broken policy. It is a correct policy plus an unlocked laptop on a café table. Whoever sits down at that keyboard holds a live tailnet identity and every grant that comes with it.

How check mode works

Check mode asks the user to reauthenticate with the identity provider, then remembers that check for the configured period. The first connection opens a browser page. You log in with your identity provider, including any second factor it enforces, and the SSH session then proceeds. Connections within the check period pass without friction.

{
  "ssh": [
    {
      "action": "check",
      "checkPeriod": "12h",
      "src": ["flavio@example.com"],
      "dst": ["tag:server"],
      "users": ["ubuntu"]
    }
  ]
}

Change action from accept to check and set a checkPeriod. Twelve hours means roughly one browser reauthentication per working day.

Test it

Change the practice SSH rule to check mode, use a short documented check period for the lab, and verify the browser reauthentication flow:

ssh ubuntu@lab-server

# Tailscale SSH requires an additional check.
# To authenticate, visit: https://login.tailscale.com/a/9e8f7a6b5c

Complete the login and the session opens. Open a second SSH connection right away: no prompt this time, because the check is still fresh.

What it does not do

It reduces the value of an unattended unlocked device. It does not replace operating-system authorization or careful control of allowed SSH usernames. The users list still decides which accounts you can become, and what those accounts may do remains the OS’s business.

My advice: use accept for routine paths and check for anything you would call administrative. If typing sudo on that box would make you pause, the connection deserves a check.