Files
MajorWiki/05-troubleshooting/networking/tailscale-ssh-reauth-prompt.md
MajorLinux 6592eb4fea wiki: audit fixes — broken links, wikilinks, frontmatter, stale content (66 files)
- Fixed 4 broken markdown links (bad relative paths in See Also sections)
- Corrected n8n port binding to 127.0.0.1:5678 (matches actual deployment)
- Updated SnapRAID article with actual majorhome paths (/majorRAID, disk1-3)
- Converted 67 Obsidian wikilinks to relative markdown links or plain text
- Added YAML frontmatter to 35 articles missing it entirely
- Completed frontmatter on 8 articles with missing fields

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-02 11:16:29 -04:00

2.9 KiB

title, domain, category, tags, status, created, updated
title domain category tags status created updated
Tailscale SSH: Unexpected Re-Authentication Prompt troubleshooting networking
tailscale
ssh
authentication
vpn
published 2026-04-02 2026-04-02

Tailscale SSH: Unexpected Re-Authentication Prompt

If a Tailscale SSH connection unexpectedly presents a browser authentication URL mid-session, the first instinct is to check the ACL policy. However, this is often a one-off Tailscale hiccup rather than a misconfiguration.

Symptoms

  • SSH connection to a fleet node displays a Tailscale auth URL:
    To authenticate, visit: https://login.tailscale.com/a/xxxxxxxx
    
  • The prompt appears even though the node worked fine previously
  • Other nodes in the fleet connect without prompting

What Causes It

Tailscale SSH supports two ACL action values:

Action Behavior
accept Trusts Tailscale identity — no additional auth required
check Requires periodic browser-based re-authentication

If action: "check" is set, every session (or after token expiry) will prompt for browser auth. However, even with action: "accept", a one-off prompt can appear due to a Tailscale daemon glitch or key refresh event.

How to Diagnose

1. Verify the ACL policy

In the Tailscale admin console (or via tailscale debug acl), inspect the SSH rules. For a trusted homelab fleet, the rule should use accept:

{
    "src":    ["autogroup:member"],
    "dst":    ["autogroup:self"],
    "users":  ["autogroup:nonroot", "root"],
    "action": "accept",
}

If action is check, that is the root cause — change it to accept for trusted source/destination pairs.

2. Confirm it was a one-off

If the ACL already shows accept, the prompt was transient. Test with:

ssh <hostname> "echo ok"

No auth prompt + ok output = resolved. Note that this test is only meaningful if the previous session's auth token has expired, or you test from a different device that hasn't recently authenticated.

Fix

If ACL shows check: Change to accept in the Tailscale admin console under Access Controls. Takes effect immediately — no server changes needed.

If ACL already shows accept: No action required. The prompt was a one-off Tailscale event (daemon restart, key refresh, etc.). Monitor for recurrence.

Notes

  • Port 2222 on MajorRig exists as a hard bypass for Tailscale SSH browser auth — regular SSH over Tailscale network, bypassing Tailscale SSH entirely. This is an alternative approach if check mode is required for compliance but browser auth is too disruptive.
  • The autogroup:self destination means the rule applies when connecting from your own devices to your own devices — appropriate for a personal homelab fleet.
  • Network Overview — Tailscale fleet inventory and SSH access model
  • SSH-Aliases — Fleet SSH access shortcuts