MajorLinux
6592eb4fea
- 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>
76 lines
2.9 KiB
Markdown
76 lines
2.9 KiB
Markdown
---
|
|
title: "Tailscale SSH: Unexpected Re-Authentication Prompt"
|
|
domain: troubleshooting
|
|
category: networking
|
|
tags: [tailscale, ssh, authentication, vpn]
|
|
status: published
|
|
created: 2026-04-02
|
|
updated: 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`:
|
|
|
|
```json
|
|
{
|
|
"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:
|
|
|
|
```bash
|
|
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.
|
|
|
|
## Related
|
|
|
|
- Network Overview — Tailscale fleet inventory and SSH access model
|
|
- SSH-Aliases — Fleet SSH access shortcuts
|