Tailnet Lockを有効にする手順
署名ノードと復旧用シークレットの準備まで

1 作業前に準備する

対象プランはPersonalとEnterpriseです。操作にはOwner、Admin、IT adminのいずれかの権限が必要です。まず、管理コンソールと各端末が同じTailnetを使っていることを確認します。[1]

• 信頼できる署名ノードを最低2台用意する。この記事の初期化には、CLIを使えるLinux・macOS・Windows端末を1台含める。
• Androidは署名ノードにできない。iOSは署名に対応するが、初期化コマンドはPC等で実行する。
• 全端末を最新のサポート対象版へ更新する。v1.46.1は機能の最低要件であり、「今この版なら安全」という推奨ではない。
• Device approvalとの併用はできない。利用中なら、運用責任者と移行方針を決めるまで進めない。
• パスワードマネージャなど、無効化用シークレットの安全な保存先を先に開いておく。

運用上のおすすめ：署名ノードを同時に失わない構成にし、サーバーのコンソールなどTailscale以外の管理経路も確保しておきます。通信が止まると困る時間帯は避けてください。これは公式の必須要件とは別の、作業時の備えです。

2 管理画面から初期化コマンドを作る

手順1 Device managementを開く

公式管理コンソールのDevice managementを開き、対象のTailnetと権限を確認してからEnable Tailnet Lockを選びます。すでに有効なら再初期化せず、次の「確認」へ進みます。

手順2 署名ノードを選ぶ

Add signing nodes → Add signing nodeから、今後の端末追加を承認する端末を最低2台選びます。初期化コマンドを実行する端末自身も、ここで選ぶ署名ノードに含めてください。「普段使うから」だけでなく、更新・端末ロック・紛失対策を維持できる端末かを確認します。

1. 署名ノードを2台以上選ぶ
2. 対象Tailnetと端末を確認
3. 初期化する端末も含める

手順3 復旧用シークレットの扱いを決める

Configure disablement optionsで、追加の無効化用シークレットをTailscaleサポートに提供するか判断します。提供は任意です。自分で保管する分とは別に、復旧支援と信頼範囲を考えて選びます。

手順4 選んだ署名ノードでコマンドを実行する

1. Run command from signing nodeに表示されたコマンドをコピーする。
2. 手順2で選んだ署名ノードのターミナルを開く。
3. 対象Tailnetと実行端末を再確認し、コピーしたコマンドを実行する。
4. 出力された無効化用シークレットを、準備した保存先に保存する。

コマンドはtailscale lock initで始まりますが、後ろの鍵やオプションは環境ごとに異なります。他人の記事やスクショの例をそのまま実行しないでください。

管理画面で生成する標準フローではシークレットが10個作られます。一方、CLIを手で組み立てる場合は--gen-disablementsで数が変わり、省略時の既定値は1個です。「必ず10個出る」とは覚えないでください。既存ノードは初期化時に署名されますが、その後の通信確認は省略しません。[2]

1. 初期化時の出力を確認
2. シークレットを安全に保存
3. 保存先で読み戻す

3 有効化できたか確認する

CLIを使える端末で、次を実行します。これは状態確認のコマンドです。

tailscale lock status

ENABLEDの表示に加えて、そのノードがTailnet Lock下でアクセス可能かを確認します。重要な端末でも同じコマンドを実行し、信頼する署名鍵の一覧が一致するか確認してください。鍵の一覧は公開せず、手元で比較します。出力の各項目は公式CLIのstatus説明で確認できます。

• 署名ノード2台で状態を確認した。
• 普段使うサーバーや必要なサービスへ、いつもの方法で接続できた。
• 無効化用シークレットの保存先と管理担当を把握した。
• 既存のアクセスルールが意図どおりか別途確認した。

スマホの表示だけで全端末の状態を確認したことにはしません。iOSやmacOSの画面名はアプリ版によって変わるため、本記事ではCLIによる確認を基準にします。

4 新しい端末を追加するとき

通常の端末追加では、ログイン後に署名の承認が必要です。管理コンソールのMachinesでLocked outの端末を選び、Sign machineから対応するクライアントまたはCLIの方法へ進みます。表示された署名対象を端末名だけで判断せず、追加した本人と対象端末を照合してから、信頼する署名ノードで承認します。

CLIを使う場合は、画面で選んだCLI用の署名コマンドを署名ノード上で実行します。追加した端末側のtailscale lock statusと、必要な通信を確認して完了です。事前署名済みauth keyを使う運用では個別の手動署名を省ける例外があります。自動登録に使う鍵の管理は別途必要です。[1]

5 SSHと復旧は別のチェック項目

Tailnet LockでSSHの問題を直したことにしない

Tailscale SSHの実行権限や認証・アクセスルールは、端末の署名とは別の話です。「root権限で動く」という設計の説明と、特定バージョンに存在する脆弱性も区別します。出典が確認できないニュースを、今回の原因として断定しないでください。[3]

• 公式Security bulletinsと更新状況を確認する。
• ネットワークアクセスとSSHルールの両方で、接続元・接続先・ログインユーザーを必要な範囲に絞る。
• 使っていないTailscale SSHは、代わりのログイン手段を確保した後に無効化を検討する。

tailscale set --ssh=false

これはサーバー設定を変更するコマンドです。今使っているTailscale SSH経由の管理を失う可能性を考え、リモート接続中に無計画に実行しないでください。OS側の通常のSSHサーバーとは別の設定です。

署名ノードの侵害やシークレット紛失時

署名ノードの鍵も端末内にあります。侵害された鍵は通常の端末整理とは分けて扱い、公式のRevoke a compromised signing nodeを参照してください。単に署名ノードを一覧から外す操作と、侵害鍵の失効は同じではありません。

シークレットを失い、サポートにも提供していない場合、通常の解除・復旧は非常に困難です。公式には端末ごとの緊急手段もありますが、本記事では安全機能を無効にするコマンドを気軽な回避策として案内しません。変更前に復旧方針を確認してください。

侵害が疑われる端末への対応は「削除か再インストールか」の二択ではありません。まず隔離とアクセス失効を検討し、調査、漏えいした認証情報の交換、必要なクリーン再構築を組み合わせます。これは一般的な運用上の整理で、個別の侵害調査の代わりにはなりません。

まずは状態と準備を確認しよう

今日すぐ有効化しなくても、現状、署名ノード候補、復旧用シークレットの保管先を確認するだけで、次の作業を判断しやすくなります。Tailnet Lockは守りの一部です。更新、最小権限、端末管理と組み合わせて運用してください。

公式資料

1. Tailnet Lock：要件、有効化、新規端末、復旧と制限。
2. tailscale lock CLI reference：init・status・失効操作の仕様。
3. Tailscale SSH ／ SSH over Tailscale：SSH機能と通常SSHの区別。
4. Security bulletins：作業時点の対象バージョンと修正版を確認。

関連記事

Tips一覧に戻る

1 Prepare before changing anything

Tailnet Lock is available on Personal and Enterprise plans. An Owner, Admin, or IT admin can enable it. Check that the console and your devices are using the same tailnet. Official requirements

• Choose at least two trustworthy signing nodes. Include a Linux, macOS, or Windows machine with a usable CLI for this initialization workflow.
• Android cannot perform signing operations. iOS supports signing, but use a CLI-capable computer for initialization.
• Update every device to a current supported version. Version 1.46.1 is the feature minimum, not a current security recommendation.
• Device approval and Tailnet Lock are mutually exclusive. If you use device approval, agree on a migration plan with the responsible administrator before proceeding.
• Prepare secure storage, such as a password manager, for disablement secrets.

Practical precautions: avoid a setup in which you could lose all signing nodes together. Keep an alternative administration route, such as a server console, and choose a maintenance window. These are operational recommendations, not additional official prerequisites.

2 Generate the initialization command

Step 1 Open Device management

Open Device management in the official admin console. Confirm the tailnet and your role, then select Enable Tailnet Lock. If it is already enabled, do not reinitialize it; proceed to verification.

Step 2 Select signing nodes

Under Add signing nodes, select Add signing node and choose at least two devices. Include the device on which you will run initialization. Choose devices whose updates, screen locks, and physical security you can maintain.

1. Choose at least two signing nodes
2. Verify the tailnet and devices
3. Include the initialization device

Step 3 Decide how recovery secrets will be handled

In Configure disablement options, decide whether to provide an additional disablement secret to Tailscale support. Consider the recovery benefit and the trust involved separately from your own storage.

Step 4 Run the generated command on a selected node

1. Copy the command from Run command from signing node.
2. Open a terminal on one of the signing nodes you selected.
3. Recheck the device and tailnet, then execute the generated command.
4. Save the resulting disablement secrets in the secure location you prepared.

The command begins with tailscale lock init, but its keys and options are environment-specific. Do not execute someone else's example. The standard console-generated workflow creates ten secrets. A manually constructed CLI invocation has a default of one unless --gen-disablements changes it. Existing nodes are signed during initialization, but you should still test connectivity. CLI reference

1. Read initialization output
2. Store secrets securely
3. Verify you can retrieve them

3 Verify the result

On a CLI-capable device, run this read-only status command:

tailscale lock status

Check for ENABLED, and check whether that node is accessible under Tailnet Lock. Repeat on important devices and compare their trusted signing-key lists privately. A phone's status label is not verification of every device. This guide uses CLI status as its baseline because app labels can vary by version. Status output reference

• Check status on both signing nodes.
• Test the servers and services you normally need.
• Confirm who is responsible for the saved secrets and where they are stored.
• Review access rules separately.

4 Add a new device later

For a normal new-device enrollment, find the device marked Locked out under Machines, then select Sign machine. Choose a supported client or CLI method. Verify the actual device and requester rather than approving solely by a familiar-looking name. When using the CLI method, run the supplied signing command on a trusted signing node, then verify status and required connectivity on the new device.

Pre-signed auth keys are an exception: they can enroll devices without separate manual signing. Keys used for automated enrollment still need appropriate protection. Official enrollment guide

5 Review SSH and recovery separately

Do not treat Tailnet Lock as an SSH fix

SSH process privileges, authentication, and access rules are separate from node signing. An architectural statement that a component runs as root is not itself a description of a specific vulnerability. This guide does not attribute an unverified news story to a particular cause.

• Check official security bulletins and installed versions.
• Limit source devices, destinations, and login users in both network-access and SSH rules.
• If Tailscale SSH is unused, consider disabling it only after confirming an alternative login route.

tailscale set --ssh=false

This command changes server configuration. Do not run it casually through the only remote-administration route you have. It controls Tailscale SSH, not the operating system's separate standard SSH server. Tailscale SSH / SSH over Tailscale

Handle compromised signing keys and lost secrets carefully

Signing keys are stored on their devices. If a signing key is compromised, use the official compromised signing-node revocation procedure. Routine removal and compromise-related revocation are different operations.

If all disablement secrets are lost and none was provided to support, normal disablement and recovery are extremely difficult. The official documentation describes an emergency per-device option, but this guide does not present disabling protection as a casual workaround. Review the recovery plan before making changes.

A suspected compromise is not a choice between deletion and reinstallation. Consider isolation and access revocation, investigation, credential rotation, and clean rebuilding as appropriate. This is general operational guidance, not an incident-specific investigation.

Start by checking the state and your recovery plan

You do not have to enable the feature immediately. First identify the current state, suitable signing nodes, and secure storage. Tailnet Lock is one layer to combine with updates, least privilege, and device security.

Official references

• Tailnet Lock
• tailscale lock CLI reference
• Tailscale SSH
• SSH over Tailscale
• Security bulletins

Related reading

All WorkFrameHub Tips