{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/tailscale-ssh-network-policy-local-user-permission/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/tailscale-ssh-network-policy-local-user-permission/",
        "slug": "tailscale-ssh-network-policy-local-user-permission",
        "url": "https://update.dsesecurity.com/updates/tailscale-ssh-network-policy-local-user-permission/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/tailscale-ssh-network-policy-local-user-permission.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/tailscale-ssh-network-policy-local-user-permission/"
        },
        "title": "Review local account names as well as network permission in Tailscale SSH",
        "summary": "Permitting port 22 and permitting a local login identity are separate decisions.",
        "format": {
            "slug": "guide",
            "name": "Guide"
        },
        "priority": {
            "slug": "info",
            "name": "Information"
        },
        "featured": false,
        "image": {
            "theme": "network-infrastructure",
            "label": "Networks & infrastructure",
            "alt": "Resilient network core with engineered blue and gold data paths.",
            "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20",
            "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20",
            "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
            "width": 2400,
            "height": 1350
        },
        "topics": [
            {
                "slug": "cybersecurity",
                "name": "Cybersecurity",
                "url": "https://update.dsesecurity.com/topic/cybersecurity/"
            },
            {
                "slug": "networks-infrastructure",
                "name": "Networks & Infrastructure",
                "url": "https://update.dsesecurity.com/topic/networks-infrastructure/"
            }
        ],
        "author": {
            "name": "DSE Security Editorial Team",
            "url": "https://update.dsesecurity.com/#editorial-team",
            "type": "Organization"
        },
        "publisher": {
            "name": "Detection Systems & Engineering",
            "url": "https://dsesecurity.com/"
        },
        "published_at": "2026-10-15T13:33:20+00:00",
        "modified_at": "2026-10-15T13:36:16+00:00",
        "reviewed_on": "2026-10-15",
        "reading_minutes": 2,
        "word_count": 259,
        "potentially_affected": "This applies to Tailscale-managed SSH on supported destination platforms. An ordinary OpenSSH service reached over a Tailscale network address has its own authentication and account controls.",
        "dse_recommendation": "DSE recommends listing the exact local accounts required for each destination class.",
        "primary_source": {
            "name": "Tailscale — SSH",
            "url": "https://tailscale.com/docs/features/tailscale-ssh",
            "published_on": null,
            "authority": "tailscale.com"
        },
        "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
        "usage_info": "https://update.dsesecurity.com/usage/",
        "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
        "content_html": "<p>Permitting port 22 and permitting a local login identity are separate decisions.</p>\n<h2>Source facts</h2>\n<p>Tailscale SSH requires both network permission between the devices and an SSH policy permitting the source, destination, and host username. It uses local accounts that already exist on the destination; it does not create those accounts. The documentation warns that autogroup:nonroot can authorize any non-root user on a destination when a rule is broadened beyond a user’s own devices. Check mode can require reauthentication before a connection and supports an explicit validity period. Tagged-device source rules cannot use check mode.</p>\n<p>Source: <a href=\"https://tailscale.com/docs/features/tailscale-ssh\">Tailscale — SSH</a>.</p>\n<h2>Applicability</h2>\n<p>This applies to Tailscale-managed SSH on supported destination platforms. An ordinary OpenSSH service reached over a Tailscale network address has its own authentication and account controls.</p>\n<h2>DSE recommendation</h2>\n<p>DSE recommends listing the exact local accounts required for each destination class. Do not retain a broad non-root selector merely because it appeared in an own-device example. Review the source identity, target tag, network permission, and local-user permission together. Apply check mode where interactive identity verification is appropriate, while designing automation separately. Keep another approved administration route available during initial enablement, and document which host accounts remain reachable through other network paths or SSH implementations.</p>\n<h2>Verification</h2>\n<p>In a test environment, try the approved local account and an existing but unauthorized account from the same source. Check that network connectivity alone does not grant the second login. Exercise the reauthentication period where check mode is used, and record the effective policy rather than only its intended design.</p>\n<h2>Official reference</h2>\n<p><a href=\"https://tailscale.com/docs/features/tailscale-ssh\">Tailscale — SSH</a>. Reviewed October 15, 2026.</p>",
        "content_text": "Permitting port 22 and permitting a local login identity are separate decisions.\nSource facts\nTailscale SSH requires both network permission between the devices and an SSH policy permitting the source, destination, and host username. It uses local accounts that already exist on the destination; it does not create those accounts. The documentation warns that autogroup:nonroot can authorize any non-root user on a destination when a rule is broadened beyond a user’s own devices. Check mode can require reauthentication before a connection and supports an explicit validity period. Tagged-device source rules cannot use check mode.\nSource: Tailscale — SSH.\nApplicability\nThis applies to Tailscale-managed SSH on supported destination platforms. An ordinary OpenSSH service reached over a Tailscale network address has its own authentication and account controls.\nDSE recommendation\nDSE recommends listing the exact local accounts required for each destination class. Do not retain a broad non-root selector merely because it appeared in an own-device example. Review the source identity, target tag, network permission, and local-user permission together. Apply check mode where interactive identity verification is appropriate, while designing automation separately. Keep another approved administration route available during initial enablement, and document which host accounts remain reachable through other network paths or SSH implementations.\nVerification\nIn a test environment, try the approved local account and an existing but unauthorized account from the same source. Check that network connectivity alone does not grant the second login. Exercise the reauthentication period where check mode is used, and record the effective policy rather than only its intended design.\nOfficial reference\nTailscale — SSH. Reviewed October 15, 2026.",
        "content_markdown": "Permitting port 22 and permitting a local login identity are separate decisions.\n\n## Source facts\n\nTailscale SSH requires both network permission between the devices and an SSH policy permitting the source, destination, and host username. It uses local accounts that already exist on the destination; it does not create those accounts. The documentation warns that autogroup:nonroot can authorize any non-root user on a destination when a rule is broadened beyond a user’s own devices. Check mode can require reauthentication before a connection and supports an explicit validity period. Tagged-device source rules cannot use check mode.\n\nSource: [Tailscale — SSH](https://tailscale.com/docs/features/tailscale-ssh).\n\n## Applicability\n\nThis applies to Tailscale-managed SSH on supported destination platforms. An ordinary OpenSSH service reached over a Tailscale network address has its own authentication and account controls.\n\n## DSE recommendation\n\nDSE recommends listing the exact local accounts required for each destination class. Do not retain a broad non-root selector merely because it appeared in an own-device example. Review the source identity, target tag, network permission, and local-user permission together. Apply check mode where interactive identity verification is appropriate, while designing automation separately. Keep another approved administration route available during initial enablement, and document which host accounts remain reachable through other network paths or SSH implementations.\n\n## Verification\n\nIn a test environment, try the approved local account and an existing but unauthorized account from the same source. Check that network connectivity alone does not grant the second login. Exercise the reauthentication period where check mode is used, and record the effective policy rather than only its intended design.\n\n## Official reference\n\n[Tailscale — SSH](https://tailscale.com/docs/features/tailscale-ssh). Reviewed October 15, 2026."
    },
    "json_ld": {
        "@context": "https://schema.org",
        "@graph": [
            {
                "@type": "Organization",
                "@id": "https://dsesecurity.com/#organization",
                "name": "Detection Systems & Engineering",
                "alternateName": "DSE Security",
                "url": "https://dsesecurity.com/",
                "logo": {
                    "@type": "ImageObject",
                    "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20"
                }
            },
            {
                "@type": "Organization",
                "@id": "https://update.dsesecurity.com/#editorial-team",
                "name": "DSE Security Editorial Team",
                "url": "https://update.dsesecurity.com/",
                "parentOrganization": {
                    "@id": "https://dsesecurity.com/#organization"
                }
            },
            {
                "@type": "WebSite",
                "@id": "https://update.dsesecurity.com/#website",
                "name": "DSE Updates",
                "alternateName": "DSE Security Knowledge Hub",
                "url": "https://update.dsesecurity.com/",
                "inLanguage": "en-US",
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "potentialAction": {
                    "@type": "SearchAction",
                    "target": {
                        "@type": "EntryPoint",
                        "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}"
                    },
                    "query-input": "required name=search_term_string"
                }
            },
            {
                "@type": "WebPage",
                "@id": "https://update.dsesecurity.com/updates/tailscale-ssh-network-policy-local-user-permission/",
                "url": "https://update.dsesecurity.com/updates/tailscale-ssh-network-policy-local-user-permission/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-10-15"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/tailscale-ssh-network-policy-local-user-permission/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "Review local account names as well as network permission in Tailscale SSH",
                        "item": "https://update.dsesecurity.com/updates/tailscale-ssh-network-policy-local-user-permission/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/tailscale-ssh-network-policy-local-user-permission/#article",
                "identifier": "https://update.dsesecurity.com/updates/tailscale-ssh-network-policy-local-user-permission/",
                "url": "https://update.dsesecurity.com/updates/tailscale-ssh-network-policy-local-user-permission/",
                "headline": "Review local account names as well as network permission in Tailscale SSH",
                "description": "Permitting port 22 and permitting a local login identity are separate decisions.",
                "abstract": "Permitting port 22 and permitting a local login identity are separate decisions.",
                "articleBody": "Permitting port 22 and permitting a local login identity are separate decisions.\nSource facts\nTailscale SSH requires both network permission between the devices and an SSH policy permitting the source, destination, and host username. It uses local accounts that already exist on the destination; it does not create those accounts. The documentation warns that autogroup:nonroot can authorize any non-root user on a destination when a rule is broadened beyond a user’s own devices. Check mode can require reauthentication before a connection and supports an explicit validity period. Tagged-device source rules cannot use check mode.\nSource: Tailscale — SSH.\nApplicability\nThis applies to Tailscale-managed SSH on supported destination platforms. An ordinary OpenSSH service reached over a Tailscale network address has its own authentication and account controls.\nDSE recommendation\nDSE recommends listing the exact local accounts required for each destination class. Do not retain a broad non-root selector merely because it appeared in an own-device example. Review the source identity, target tag, network permission, and local-user permission together. Apply check mode where interactive identity verification is appropriate, while designing automation separately. Keep another approved administration route available during initial enablement, and document which host accounts remain reachable through other network paths or SSH implementations.\nVerification\nIn a test environment, try the approved local account and an existing but unauthorized account from the same source. Check that network connectivity alone does not grant the second login. Exercise the reauthentication period where check mode is used, and record the effective policy rather than only its intended design.\nOfficial reference\nTailscale — SSH. Reviewed October 15, 2026.",
                "datePublished": "2026-10-15T13:33:20+00:00",
                "dateModified": "2026-10-15T13:36:16+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/tailscale-ssh-network-policy-local-user-permission/"
                },
                "inLanguage": "en-US",
                "isAccessibleForFree": true,
                "author": {
                    "@type": "Organization",
                    "name": "DSE Security Editorial Team",
                    "url": "https://update.dsesecurity.com/#editorial-team"
                },
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "image": {
                    "@type": "ImageObject",
                    "@id": "https://update.dsesecurity.com/updates/tailscale-ssh-network-policy-local-user-permission/#primaryimage",
                    "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
                    "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
                    "width": 1200,
                    "height": 630,
                    "caption": "Review local account names as well as network permission in Tailscale SSH"
                },
                "articleSection": [
                    "Cybersecurity",
                    "Networks & Infrastructure"
                ],
                "keywords": [
                    "Cybersecurity",
                    "Networks & Infrastructure",
                    "Guide",
                    "Information priority"
                ],
                "genre": "Guide",
                "about": [
                    {
                        "@type": "Thing",
                        "name": "Cybersecurity",
                        "url": "https://update.dsesecurity.com/topic/cybersecurity/"
                    },
                    {
                        "@type": "Thing",
                        "name": "Networks & Infrastructure",
                        "url": "https://update.dsesecurity.com/topic/networks-infrastructure/"
                    }
                ],
                "wordCount": 259,
                "timeRequired": "PT2M",
                "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
                "usageInfo": "https://update.dsesecurity.com/usage/",
                "copyrightHolder": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
                "citation": {
                    "@type": "CreativeWork",
                    "name": "Tailscale — SSH",
                    "url": "https://tailscale.com/docs/features/tailscale-ssh"
                }
            }
        ]
    }
}