Tailscale SSH

tailnet内のSSH接続の認証と認可を管理する

最終検証日：2026年1月5日
翻訳: 竹洞陽一郎

Tailscale SSHを使用すると、tailnet内のSSH接続の認証と認可をTailscaleが管理します。

Tailscale SSHはPersonal、Personal Plus、Premium、Enterpriseプランでご利用いただけます。

重要な理由

Tailscale SSHでできること：

通常通りSSHを使用する: 認証にTailscaleを使用しながら、これまでと同様にSSHを利用できます。
Tailscale SSHを有効にすると、TailscaleはTailscaleネットワークからの着信SSHトラフィックに対してポート22を引き継ぎます。
TailscaleはWireGuardを介して、Tailscaleノード鍵を用いて接続の認証と暗号化を行います。
SSHクライアントとサーバは引き続き暗号化されたSSH接続を確立しますが、追加の認証は不要になります。
チェックモードで高リスク接続を確認する: 特定の接続、または特定ユーザ（例：root）としての接続に対して、接続前の再認証を任意で要求できます。
これにより、ユーザは再認証後12時間、または指定したチェック期間、これらの高リスクアプリケーションにアクセスできます。

SSHの設定ファイル（/etc/ssh/sshd_config）と鍵ファイル（~/.ssh/authorized_keys）は変更されません。
そのため、Tailscale経由でない同一ホストへのSSH接続は引き続き通常通り機能します。

メリット

SSH鍵管理の削減: Tailscale SSHはWireGuard鍵を使用します。これらの鍵は自動生成され、セッション終了後に有効期限が切れます。
Tailscaleアクセス制御によるアクセス管理の強制: SSHが必要なユーザとグループにのみアクセスを付与し、チェックモードで強制します。
SSHセッション記録: 監査・トラブルシューティング・コンプライアンス要件のためにSSHセッション記録を強制できます。

ユースケース

インフラへのSSHアクセス: すべてのSSHトラフィックをtailnet経由でルーティングします。
ツールの統合: SSHアクセス管理のツールを一元化します。
コンプライアンス要件の充足: SSHに関する業務上の規制・コンプライアンス要件を満たします。

Tailscale SSHの違い

従来のSSH接続を保護するには、接続元マシン（クライアント）で鍵ペアを生成し、秘密鍵をクライアントに保存、公開鍵を接続先デバイス（サーバ）に配布します。
これにより、サーバはクライアントからの通信を認証できます。

Tailscaleを使用すると、ネットワーク上のマシンを接続し、エンドツーエンドで通信を暗号化できます。例えば、業務用ラップトップから業務用デスクトップへのSSH接続も含まれます。
Tailscaleはすでにユーザのアイデンティティを把握しています（tailnetへの接続時に認証されているため）。
Tailscale SSHを有効にすると、TailscaleはTailscale IPアドレスのポート22をtailnetからのトラフィックに対して引き継ぎます。
これにより、デバイスへのSSHトラフィックは標準のSSHサーバではなく、Tailscaleが実行するSSHサーバにルーティングされます。
Tailscale SSHでは、tailnet内のアクセス制御ポリシーに基づき、デバイスのSSH接続において公開鍵の代わりにTailscaleによる認証を利用できます。

	SSH（従来）	Tailscale SSH
IPアドレス	IPアドレスで動作します。	IPアドレスで動作します。
MagicDNS	MagicDNS名で動作します。	MagicDNS名で動作します。
DNSの制限	IPアドレスを使用する場合はDNSが不要です。	カスタム`known_hosts`ファイルにホスト名を使用します。DNSが解決できない場合はエラーが発生することがあります。
アクセス制御	アクセス制御と連携します。	Tailscaleのアイデンティティに基づいた一元的なポリシー管理を使用します。
SSHセッション記録	（対応なし）	SSHセッション記録と連携します。
macOS	利用可能です。	オープンソースの`tailscaled`バリアントの使用が必要です。

追加情報については、制限事項をご参照ください。

仕組み

SSH鍵を使用する方法と比較して、Tailscale SSHは接続の認証、鍵の生成・配布、ユーザアクセスの取り消しの仕組みが異なります。

認証と認可

通常、SSH接続を確立するには、使用しているローカルのSSHクライアントが接続先マシンのSSHサーバに接続します。

Tailscale SSHでは、TailscaleがWireGuardを介してTailscaleノード鍵を用いて接続の認証と暗号化を行います。
SSHクライアントとサーバは引き続きSSH接続を確立しますが、SSHプロトコルの認証フェーズにおいて、Tailscale SSHサーバはすでに相手ノードを把握しているため、SSHクライアントによる追加の証明（SSH認証タイプnoneを使用）は不要です。

Tailscaleは、tailnetのアクセス制御ポリシーが許可している場合にのみ、2つのデバイス間の接続を認可します。
Tailscaleはnetstackによるポートインターセプトと、クライアントのknown_hostsファイルのジャストインタイム自動設定を使用することで、新しいバイナリや設定ファイルなしにssh myhostを動作させます。
TailscaleはSFTP（SSH File Transfer Protocol）を実装しており、新しいSSHクライアントではSCPやSFTPも利用できます。

暗号化

Tailscale SSHでは、SSHプロトコルによる暗号化に加えて、TailscaleがWireGuardを使用してエンドツーエンドで接続を暗号化します。WireGuardによる完全性保護も含まれます。

鍵の管理と配布

Tailscaleはtailnet内のデバイスのノード鍵とマシン鍵をすでに管理・配布しています。
TailscaleはSSH接続の認証・認可・暗号化にノード鍵を使用します。

Tailscale SSHでは、TailscaleはSSHホスト公開鍵も配布します。
秘密鍵はローカルに保存され、公開鍵はTailscaleコントロールプレーンに共有されて配布されます。
このホスト鍵により、SSHクライアントは接続先ホストを認識できます。
ホストが認識されると、Tailscaleはホスト鍵を保存し、「不明なホスト」エラーメッセージが表示されないようにします。

アクセス制御ポリシーに基づき、2つのデバイスの接続が許可されている場合、Tailscaleのコントロールプレーンはデバイスの検索のためにノード公開鍵を共有し、エンドツーエンドで暗号化されたWireGuard接続を確立できます。
アクセス制御ポリシーでさらに許可されている場合、TailscaleはSSHホスト公開鍵も共有し、SSH接続の一部としてデバイスを認識できます。
鍵が漏洩した場合、ユーザはデバイスの鍵を削除してTailscaleを再インストールし、再認証することで新しいノード鍵とSSHホスト鍵を生成・配布できます。

ユーザアクセスの取り消し

アクセス制御ポリシーにより、どのデバイスとユーザがSSH接続を認可されるかが決まります。
SSHの鍵を削除する必要がある従来の方法とは異なり、ユーザのデバイスへのSSHアクセスを取り消すには、アクセス制御ポリシーを更新してユーザのアクセスを制限するだけです。
アクセス制御ポリシーが保存されると、クライアントは数秒以内に新しいルールに従います。
これにより、ユーザが確立している既存のSSH接続も切断されます。

チェックモード

Tailscale SSH接続において、SSH接続を確立する前にユーザの再認証を要求するよう任意で設定できます。
これにより、ユーザはアイデンティティプロバイダで再度サインインする必要があります。
チェックモードにおける他の接続では、次の12時間または指定したチェック期間が経過するまで、再認証は不要です。

Tailscale SSHの設定

前提条件

Tailscale SSHのサーバコンポーネントが対応しているのは、以下のOSのみです。

Linux
macOSのオープンソース版tailscale + tailscaled CLIデバイス

接続元はTailscaleを実行しているデバイスであれば、プラットフォームを問いません。
Tailscale SSHのサーバコンポーネントはTailscale v1.24以降が必要です。

Tailscale SSHを有効にするには：

接続先のホストでTailscale SSHをアドバタイズする必要があります。
送信元から宛先へのポート22へのアクセスを許可するアクセス制御ポリシーが必要です。
- アカウントのアクセス制御ポリシーを変更していない場合は不要です。デフォルトのアクセス制御ポリシーがtailnet内のすべてのデバイスへのアクセスを許可しています。
- tailnetポリシーファイルにSSHを含める変更が必要な場合があります。tailnetポリシーファイルを変更するには、OwnerまたはNetwork adminである必要があります。
送信元からTailscale SSHを使用して宛先マシンへのSSH接続を許可するアクセス制御ポリシーが必要です。
- アカウントのアクセス制御ポリシーを変更していない場合は不要です。デフォルトのアクセス制御ポリシーのSSHアクセスルールがすべてのデバイスへのSSHアクセスを許可しています。
- tailnetポリシーファイルにSSHポリシーを含める変更が必要です。tailnetポリシーファイルを変更するには、OwnerまたはNetwork adminである必要があります。

ホストでSSHをアドバタイズする

接続先ホストで、TailscaleがそのホストへのTailscaleネットワーク経由のSSH接続を管理することをアドバタイズする必要があります。
以下のコマンドを実行してください。

tailscale set --ssh

tailscale set --sshを実行すると、ホストのTailscale IPへの既存のSSH接続がハングアップする場合があります。

このコマンドにより、ホスト鍵ペアが生成され、公開鍵の半分がクライアントへの配布のためにTailscaleコントロールプレーンに共有されます。
また、tailscaledがTailscale IPアドレスのポート22宛のtailnetからのすべてのトラフィックをインターセプトするよう設定されます。
このSSH初期化はホストごとに一度だけ実行する必要があります。

アクセス制御ポリシーでTailscale SSHを許可する

Tailscale SSHを使用する前に、どのユーザがどのデバイスへSSHできるかをTailscaleに設定する必要があります。
Tailscaleが認証と認可を自動で管理するため、これらの接続を明示的に定義する必要があります。

SSHアクセスルールは、管理コンソールのアクセス制御ページまたはTailscale APIから編集できるtailnetポリシーファイルで定義されます。

接続を許可するには、tailnetポリシーファイルにネットワークアクセスとSSHアクセスの両方を許可するルールが必要です。

送信元から宛先への接続を許可するルール。TailscaleのすべてのWireGuard接続（SSH接続を含む）の鍵配布に使用されます。
送信元から宛先および指定したSSHユーザへのSSH接続を許可するルール。Tailscale SSHにおけるSSH接続の認証に使用されます。

各SSHアクセスルールの形式は以下の通りです。

{
  "action": "check",      // "accept" または "check"
  "src": [送信元リスト],
  "dst": [宛先リスト],
  "users": [SSHユーザリスト],
  "checkPeriod": "20h",  // 任意。checkアクションのみ。デフォルト: 12h
  "acceptEnv": [ "GIT_EDITOR", "GIT_COMMITTER_*", "CUSTOM_VAR_V?" ] // 任意。クライアントからホストへ転送を許可する環境変数のallowlist
},

`action`

接続を受け入れるか、追加の確認を行うかを指定します。

accept: tailnetで既に認証済みのユーザからの接続を受け入れます。
check: checkPeriodの設定に従い、ユーザに定期的な再認証を要求します。

`src`

接続の送信元を指定します。ユーザ、グループ、タグ、user:*@<ドメイン>、またはautogroupを指定できます。

ワイルドカード*のみの指定はできません。

autogroup:memberへのアクセスを付与すると、宛先ノードが共有されている場合、tailnetにノードを持たない外部の招待ユーザにもアクセスが付与されます。

`dst`

接続の宛先を指定します。ユーザ、タグ、またはautogroupを指定できます。
ACLと異なり、ポートは指定できません。使用できるのはポート22のみで、デフォルトで使用されるため指定不要です。
ワイルドカード*のみの指定はできません。

`users`

ホスト上で許可するユーザ名のセットを指定します。
他のSSHクライアントと同様に、Tailscaleはホスト上に既存のユーザアカウントのみを使用し、新しいアカウントは作成しません。

autogroup:nonroot: root以外のすべてのユーザを許可します。
localpart:*@<ドメイン>: ユーザのログインメールが指定<ドメイン>に属する場合に限り、ログインのローカルパートに一致するホストユーザを許可します。Tailscaleはローカルパートに特別な処理を行いません。例えば、ログインがdave+sshuser@example.comの場合、SSHユーザdave+sshuserにマッピングされます。

`checkPeriod`

actionがcheckの場合、確認が必要になるまでの接続許可期間を指定します。
分または時間で指定でき、最短1分、最長168時間（1週間）です。

未指定の場合、デフォルトは12時間です。
alwaysを指定すると、毎回の接続でチェックモードを要求します。常にチェックモードを要求すると、Ansibleなどの短時間に多数のSSH接続を開くツールで予期しない動作が発生する場合があります。

`acceptEnv`

acceptEnvを使用するには、ホストがTailscale v1.76.0以降を実行している必要があります。

クライアントがSendEnvまたはSetEnvを使用してホストに送信できる環境変数名のallowlistを指定します。

値にはワイルドカード文字*と?を使用できます。
*は0文字以上、?は1文字に一致します。

acceptEnv	許可	拒否
`*`	`FOO_A` `FOO_B` `FOO_OTHER` `BAZ`	（なし）
`FOO_*`	`FOO_A` `FOO_B` `FOO_OTHER`	`BAZ`
`FOO_?`	`FOO_A` `FOO_B`	`FOO_OTHER` `BAZ`
`FOO_A`	`FOO_A`	`FOO_B` `FOO_OTHER` `BAZ`

評価の順序

SSHアクセスルールは、最も制限の厳しいポリシーから順に評価されます。

checkポリシー
acceptポリシー

例えば、ユーザalice@example.comにacceptルールでリソースへのアクセスを許可し、かつalice@example.comが所属するgroup:devopsにcheckルールで同じリソースへのアクセスを許可している場合、checkルールが適用されます。

許可される接続の種類は以下に限られます。

ユーザ自身のデバイスへの接続（rootを含む任意のユーザとして）
ユーザからタグ付きデバイスへの接続（rootを含む任意のユーザとして）
ユーザから共有されたタグ付きデバイスへの接続（rootを含む任意のユーザとして）
タグ付きデバイスから別のタグ付きデバイスへの接続（任意のタグ間）。タグ付きデバイスからのSSHアクセスルールはチェックモードにはできません。

最も広いポリシーの例：

{
  "grants": [
    {
      "src": ["*"],
      "dst": ["*"],
      "ip": ["*"]
    }
  ],
  "ssh": [
    {
      "action": "accept",
      "dst": ["autogroup:self"],
      "src": ["autogroup:member"],
      "users": ["root", "autogroup:nonroot"]
    },
    {
      "action": "accept",
      "dst": ["tag:prod"],
      "src": ["autogroup:member"],
      "users": ["root", "autogroup:nonroot"]
    },
    {
      "action": "accept",
      "dst": ["tag:prod"],
      "src": ["tag:logging"],
      "users": ["root", "autogroup:nonroot"]
    }
  ]
}

デフォルトのアクセス制御ポリシーにおけるSSHアクセスルール

デフォルトでは、新規tailnetまたはアクセス制御ポリシーを変更していないtailnetには、実用的かつ保守的なTailscale SSHアクセスルールが設定されています。
接続を容易にするため、Tailscale SSHはデフォルトポリシーが設定されており、rootまたは非rootユーザとしてチェックモードで自分のデバイスにアクセスできます。

"ssh": [
  {
    // すべてのユーザが自分のデバイスに対してTailscale SSHで接続できます
    // チェックモードで、rootまたは非rootユーザとして
    "action": "check",
    "src": ["autogroup:member"],
    "dst": ["autogroup:self"],
    "users": ["autogroup:nonroot", "root"]
  },
]

接続先デバイスでのオプトインは引き続き必要です。

SSH用のアクセス制御ポリシーを変更すると、このデフォルト設定が上書きされ、削除するとtailnet全体でTailscale SSHが無効になります。

`autogroup:nonroot`に関する重要な注意

デフォルトACLのsshルールは、dstフィールドにautogroup:selfを、usersフィールドにautogroup:nonrootを使用しています。
dstフィールドをautogroup:selfからACLタグなどの別の宛先に変更する場合は、usersフィールドのautogroup:nonrootも見直してください。
autogroup:nonrootをusersフィールドに残したままにすると、srcで許可されたすべてのユーザがdstデバイスの任意の非rootユーザとしてSSH接続できてしまいます。

SSHアクセスルールの例

以下は、ユーザが自分のデバイスへのみ、非rootとしてSSH接続できるようにする例です。

{
  "grants": [
    {
      "src": ["*"],
      "dst": ["*"],
      "ip": ["*"]
    }
  ],
  "ssh": [
    {
      "action": "accept",
      "dst": ["autogroup:self"],
      "src": ["autogroup:member"],
      "users": ["autogroup:nonroot"]
    }
  ]
}

以下は、group:sreがtag:prodタグの付いた本番環境デバイスにアクセスできるようにする例です。

{
  "grants": [
    {
      "src": ["group:sre"],
      "dst": ["tag:prod"],
      "ip": ["*"]
    }
  ],
  "groups": {
    "group:sre": ["alice@example.com", "bob@example.com"]
  },
  "ssh": [
    {
      "action": "accept",
      "dst": ["tag:prod"],
      "src": ["group:sre"],
      "users": ["ubuntu", "root"]
    }
  ],
  "tagOwners": {
    "tag:prod": ["group:sre"]
  }
}

ホストのユーザとログインメールを紐付けると便利な場合があります。
例えば、dave@example.comをホストユーザdaveとして認証させることができます。
example.comドメインのすべてのtailnetメンバーが、ログインメールのローカルパートに一致するユーザとしてtag:prodタグの付いた本番環境デバイスにアクセスできるようにする例：

{
  "grants": [
    {
      "src": ["user:*@example.com"],
      "dst": ["tag:prod"],
      "ip": ["*"]
    }
  ],
  "ssh": [
    {
      "action": "accept",
      "dst": ["tag:prod"],
      "src": ["user:*@example.com"],
      "users": ["localpart:*@example.com"]
    }
  ]
}

SSH接続を行う

アクセス制御ポリシーでSSHが許可され、接続先ホストでTailscaleとSSHが設定されていれば、Tailscale SSHを使用できます。

tailnet内のdeviceというホストに接続するには、以下のコマンドを実行します。


ssh device

この例ではMagicDNSのホスト名を使用しています。

MagicDNSのホスト名はマシン名から自動的に生成されます。
別の名前を使用したい場合はマシン名を編集できます。

ローカルユーザと異なるユーザ（例：ubuntu）を指定するには、以下のコマンドを実行します。


ssh ubuntu@device

SSHクライアントによっては、認証なしのSSHサーバへの接続に失敗する場合があります。
その場合、クライアントのユーザ名に+passwordを追加することでパスワード認証をシミュレートできます。


username: ubuntu+password
password: （任意）

この場合、任意のパスワードを入力できます。実際のユーザのパスワードと一致する必要はありません。
ユーザ名に追加するのはユーザのパスワードではなく、リテラル文字列+passwordです。

タグ付きノードで自分と共有されているノードに対しても、宛先ホストでTailscaleとSSHが設定されており、宛先のアクセス制御ポリシーでSSH接続が許可されていれば、SSH接続できます。

ホスト名に加えて、Tailscale IPアドレスをSSH接続先として使用することも可能です。
Tailscale IPアドレスは、デバイスの物理的な場所に関わらず一定です。
Wi-Fiからモバイルネットワークに切り替えるなどのネットワーク変更があっても、Tailscale IPアドレスは変わりません。

例えば、Tailscale IPアドレス（100.64.0.1など）への接続は、以下のコマンドを実行します。


ssh user@100.64.0.1

Tailscale以外のIPアドレスを使用してTailscale SSHサーバへの接続はできません。

既存のSSHクライアントからTailscale SSHへの移行

Tailscale SSHを有効にすると、TailscaleはSSHを有効にしたデバイスのTailscale IPアドレスのポート22をtailnetからのトラフィックに対して引き継ぎ、デバイスへのSSHトラフィックを標準のSSHサーバではなくTailscaleが実行するSSHサーバにルーティングします。
SSHの設定ファイル（/etc/ssh/sshd_config）と鍵ファイル（~/.ssh/authorized_keys）は変更されません。
そのため、Tailscale経由でない同一ホストへのSSH接続は引き続き通常通り機能します。

鍵のローテーション

デバイスで再認証を行うと、新しいノード鍵ペアが生成され、秘密鍵がローカルに保存され、公開鍵がTailscaleに共有されて配布されます。

新しいノード鍵とSSHホスト鍵を生成するには、以下のコマンドを実行します。


tailscale up --ssh --force-reauth

Tailscale SSHの無効化

デバイスでTailscale SSHを無効にする

Tailscale SSHを無効にする前に、デバイスへの別のSSH接続方法を確保してください。
確保しないままにすると、デバイスへのアクセスを失う可能性があります。

デバイス上で--ssh=falseを指定してtailscale setを実行してTailscale SSHを無効にします。


tailscale set --ssh=false

デバイスへの他デバイスからのSSH接続をブロックする

デバイスのTailscale SSHを無効にするには、--ssh=falseでデバイスを再設定します。


tailscale set --ssh=false

Tailscale SSH接続を含む、tailnetからデバイスへのすべての着信接続をブロックするには、以下のコマンドを実行します。


tailscale set --shields-up

ユーザのSSHアクセスを取り消す

ユーザのデバイスへのSSHアクセスを取り消すには、そのユーザのSSHアクセスを指定しているアクセスルールを変更します。
アクセス制御ポリシーの更新はデバイスにほぼリアルタイムでプッシュされ、ユーザのアクセスが取り消されます。
必要に応じて、ユーザのデバイスへの接続は引き続き許可しつつ、Tailscale SSHは使用できないよう設定することも可能です。

これにより、ユーザが確立している既存のSSH接続は切断されます。ユーザには「Access revoked（アクセス取り消し）」というメッセージが表示されます。

ユーザがSSH鍵などTailscale以外でデバイスにアクセスする手段を持っている場合は、それも削除または取り消す必要があります。

tailnet全体でTailscale SSHを無効にする

tailnetからTailscale SSHの機能を完全に削除するには以下の手順を踏みます。

すべてのホストでTailscale SSHをオプトアウトする（tailscale set --ssh=false）
アクセス制御ポリシーからTailscale SSH用のSSHアクセスルールを削除する

Tailscale SSHを使用せずに指定のデバイスへのアクセスを引き続き許可したい場合は、他のアクセスルールを削除または変更する必要はありません。

設定ミスへの対処

Tailscale SSHには、SSHの送信元と宛先の両方を許可・指定するtailnetポリシーファイル上のアクセス制御ポリシーと、宛先デバイスでのTailscale SSHの有効化が必要です。

アクセス制御ポリシーが不足している場合は、管理コンソールのアクセス制御ページのtailnetポリシーファイルで変更できます。tailnetポリシーファイルを変更するにはAdminまたはNetwork adminである必要があります。

デバイスでSSHがアドバタイズされていない場合は、Tailscale経由でデバイスに接続してからtailscale set --sshを実行してください。

チェックモードの設定

SSHチェックモードを使用すると、接続を確立する前にSSH接続の追加確認を要求できます。
チェックモードでは、接続を開始するデバイスでの再認証が必要です。
SSHの初期化によりサインイン用のURLが提供されます。
サインイン試行により、アイデンティティプロバイダの多要素認証（MFA）やその他のリスクベースの認証が発動する場合もあります。

宛先に対して再認証が完了すると、次の12時間はtailnet内のデバイスと再認証なしにアクセスできます。
接続に異なるチェック期間が指定されている場合、ユーザはその期間中そのデバイスのみを再認証なしにアクセスできます。
例えば、チェック期間が10分に設定されている場合、直近10分以内に再認証していなければ、12時間以内に再認証済みであっても再認証を求められます。

チェックモードは任意で、デフォルトでは無効です。
チェックモードはTailscale SSH接続にのみ使用できます。

チェックモードはSSHポリシー設定で制御します。sshルールにはactionフィールドをcheckに設定して含める必要があります。

"ssh": [
  {
    "action": "check",        // "accept" の代わりに "check"
    "src": ["autogroup:member"],
    "dst": ["autogroup:self"],
    "users": ["autogroup:nonroot"],
    "checkPeriod": "5m",      // 任意。分、時間、または "always" で指定
  }
]

チェック期間は分または時間でカスタマイズできます。デフォルトのチェック期間は12時間です。
"always"を指定すると、毎回の接続でチェックモードを要求します。

常にチェックモードを要求する設定にすると、Ansibleなどの短時間に多数のSSH接続を開くツールで予期しない動作が発生する場合があります。

例えば、Aliceがtag:prodタグのデバイスにrootとしてSSH接続する際にチェックモードを要求し、1h後に再認証を要求する一方で、自分のデバイスへの非rootでのSSH接続にはチェックモードを要求しない設定：

{
  "grants": [
    {
      "src": ["*"],
      "dst": ["*"],
      "ip": ["*"]
    }
  ],
  "ssh": [
    {
      "action": "accept",
      "dst": ["autogroup:self"],
      "src": ["alice@example.com"],
      "users": ["autogroup:nonroot"]
    },
    {
      "action": "check",
      "checkPeriod": "1h",
      "dst": ["tag:prod"],
      "src": ["alice@example.com"],
      "users": ["root"]
    }
  ]
}

制限事項

対応デバイス: Tailscale SSHは現在、Tailscaleネットワーク上のデバイスへの接続にのみ使用できます。
Subnet Routerの背後にあるデバイスでTailscaleを実行していない場合は、Tailscale SSHは使用できません。
また、Tailscale SSHは現在、LinuxデバイスおよびmacOSのオープンソース版tailscale + tailscaled CLIバージョンデバイスへの接続のみに対応しています。
接続元はTailscaleを実行しているデバイスであれば、プラットフォームを問いません。
SynologyおよびQNAPデバイスではTailscale SSHを実行できません。
Tailscaleデーモン（tailscaled）を再起動した場合（アップグレード実施時など）、既存のTailscale SSHセッションは終了します。
ポート: Tailscale SSHはSSHにポート22を使用することを前提としています。
現時点では、Tailscale SSHが使用するポートを変更することはできません。
SSHユーザ: SSHアクセスルールはその制限の厳しさに基づいて評価されます。
ある接続にcheckルールとacceptルールの両方が存在する場合、checkルールが適用されます。
つまり、ユーザはacceptルールで許可されたSSHusersも考慮されず、checkルールのSSHusersのみによって制限されます。
SSHテスト: SSHテストを記述して、SSHアクセスルールが想定通りに動作していることを検証できます。
チェックモード: チェックモードはTailscale SSH接続にのみ使用できます。
Tailscale上で実行する通常のSSHやその他のTCP接続には使用できません。
クライアント側のOSユーザ認証: 従来のSSHでは、クライアントマシン上のローカルOSユーザがディスク上のSSH鍵ペアを読み取れる必要があります。
これにより、実質的にSSHを利用できるクライアント側のOSユーザが制限されます。

Tailscaleはローカルの SSH鍵ペアを認証に使用しないため、クライアントマシン上の任意のOSユーザがTailscale経由でSSHサーバに接続できます。
このアクセスの範囲は引き続きTailscaleアクセス制御ポリシーによって制限され、サーバ側で適用されます。

Tailscale SSHが従来のSSHより優れているケース

単一のシステムユーザでワークロードを実行するサーバやコンテナ
従業員のラップトップなど、シングルユーザのマシン
Tailscaleアクセス制御ポリシーで外向きのSSH接続を許可していないマシン

Tailscale SSHが適していないケース

マシン上のOSユーザごとにTailscaleアクセス制御ポリシーのSSHアクセス権限が異なる、マルチユーザのマシン
外向きのTailscale SSHアクセスを持ち、そのマシン上で実行されるコードを信頼していないマシン
リモートユーザが実行できるコマンドを制限するためにauthorized_keysを使用しているマシン

この懸念は、checkPeriodをalwaysに設定したチェックモードを使用することで緩和できます。
これにより、新規接続のたびにSSOベースの承認を求めることができます。

Tailscale SSHがニーズに合わない場合でも、ネットワークレイヤとしてTailscaleを使用した上で、従来のSSHサーバとクライアントを引き続き利用できます。
これにより、サーバをインターネットに公開することなく、標準のSSH環境を利用できます。

Redirect	?
App cache	?
DNS lookup	?
TCP Connection	?
First Byte Download	?
DOMContentLoaded	?
Load	?