Tailscale SSHは、SSH鍵をサーバーに配らずに、tailnetのログイン情報でLinuxサーバーへ入れるようにするTailscaleの機能です。サーバー側でtailscale set --sshを1回実行し、tailnetのポリシーファイルに「誰が・どのサーバーに・どのOSユーザーで」入れるかを書けば使えます。この記事では2026年10月時点のクライアントv1.102系を前提に、有効化の手順、grantsとsshルールの書き方、チェックモードとセッション録画、そして公開SSHを残したまま導入して失敗する例と、踏み台サーバーやSession Managerとの選び分けまでを設定例付きで扱います。
まとめ：Tailscale SSHは鍵配布をやめる手段で公開SSHの閉鎖までが導入作業
Tailscale SSHを有効にすると、tailnetから来るポート22への接続をtailscaledが引き受け、WireGuardのノード鍵とIdPのログインで本人を確かめます。authorized_keysの配布や退職者の鍵の削除は不要になり、権限の剥奪はポリシーファイルの編集だけで済みます。
ただし、通常のsshdはそのまま動き続けます。インターネット側のポート22を閉じなければ、鍵で入れる経路が残り、管理対象が二重になります。採用してよいのは、対象がLinuxサーバー中心で、全員がTailscaleクライアントを入れられる組織です。Windowsサーバーが多い、Ansibleで短時間に大量の接続を張る、録画を契約なしで必須にしたい、という条件では他の方式を選んでください。
Tailscale SSHの仕組みとWireGuardのノード鍵によるポート22の処理
Tailscale SSHの公式ドキュメントによると、有効化したサーバーではTailscale IP宛てのポート22だけをTailscaleが受け持ちます。社内LANや公開IPから来るSSHには関与しません。
OpenSSHの公開鍵認証との違いはSSHの認証段階をTailscaleが省く点
通常のSSHは、クライアントの秘密鍵とサーバーのauthorized_keysを突き合わせて本人を確かめます。この認証の仕組みの基本を確認できる関連記事は、SSH接続の仕組みと公開鍵認証の解説です。Tailscale SSHでは、接続元の端末とユーザーがWireGuardの段階で判明しているため、SSHプロトコルの認証はnone方式で通過します。
サーバーのホスト鍵もTailscaleの制御サーバーが配るので、初回接続で「unknown host」の確認が出ません。暗号化はSSH自体とWireGuardの二重です。SCPとSFTPも新しめのSSHクライアントなら動きます。
サーバー側はLinuxとmacOSのオープンソース版tailscaledに限られる
SSHの受け側になれるのは、LinuxとmacOSのオープンソース版tailscale＋tailscaledだけです。サーバー機能にはv1.24以降が必要です。WindowsサーバーとSynology・QNAPのNASは受け側になれません。接続する側は、Tailscaleが動く端末ならOSを問いません。
サブネットルーターの奥にある、Tailscaleを入れていない機器にもTailscale SSHでは入れません。ポートも22固定で、変更する設定はありません。
Tailscale SSHのサーバー設定とtailscale set –sshの実行手順
作業は、サーバーをtailnetに参加させる、SSHを有効にする、ポリシーを書く、の順です。ポリシーは次の章で扱います。
インストールからtailscale set –sshまでのコマンドと実行時の注意
サーバーは個人のアカウントではなくタグで登録します。担当者が退職しても、サーバーの所有者が宙に浮かないためです。TailscaleのCLIリファレンスどおり、--advertise-tagsを使うには、実行者がポリシーのtagOwnersに載っている必要があります。
# Linuxサーバー側（Ubuntu・Debian・RHEL系の公式インストーラ）
curl -fsSL https://tailscale.com/install.sh | sh
# タグを付けてtailnetに参加する（tag:prodはポリシーのtagOwnersに定義しておく）
sudo tailscale up --advertise-tags=tag:prod
# Tailscale SSHを有効にする（ホスト鍵を作り、制御サーバーへ公開鍵を渡す）
sudo tailscale set --ssh
# 状態を確認する
tailscale status
tailscale versiontailscale set --sshを実行すると、そのサーバーのTailscale IPへ張っていた既存のSSHはハングします。作業は公開IP側のSSHかクラウドのシリアルコンソールから行ってください。無効化はtailscale set --ssh=falseです。/etc/ssh/sshd_configとauthorized_keysは書き換えられません。
sshとtailscale sshの2つの接続方法と端末モード別の選択基準
接続する側は、普段のsshコマンドでそのまま入れます。MagicDNSの名前でもTailscale IPでも構いません。
# 通常のsshクライアントで入る
ssh ubuntu@prod-web-01
# Tailscale経由でホスト鍵を照合しながら入る
tailscale ssh ubuntu@prod-web-01tailscale sshが必要になるのは、接続元の端末がuserspace-networkingモードで動いていて、通常のsshコマンドでは直接つながらない場合です。このコマンドはローカルのtailscaledを経由するProxyCommandを組み、制御サーバーが配ったホスト鍵と照合します。App Store版のようなサンドボックス化されたmacOSアプリではtailscale sshが使えないため、通常のsshを使います。
tailnetポリシーファイルにgrantsとsshの2種類のルールを書く設定例
接続が通るには、ネットワークの到達（grantsでポート22）とSSHの許可（sshセクション）の両方が要ります。初期状態のポリシーは全端末に自分の端末へのSSHをチェックモードで許しますが、サーバーをタグで登録した時点で自分で書く必要があります。
運用グループからタグ付きサーバーへの接続を許すHuJSONの全文
次の例は、SREグループにtag:prodのサーバーへのSSHだけを許し、rootでのログインを禁じる設定です。書式はポリシーファイルの構文リファレンスに従っています。
{
"groups": {
"group:sre": ["[email protected]", "[email protected]"]
},
"tagOwners": {
"tag:prod": ["group:sre"]
},
"grants": [
// ネットワーク到達：SREから本番サーバーのポート22だけ
{ "src": ["group:sre"], "dst": ["tag:prod"], "ip": ["22"] }
],
"ssh": [
{
"action": "check",
"src": ["group:sre"],
"dst": ["tag:prod"],
"users": ["autogroup:nonroot"]
}
],
"sshTests": [
{
"src": "[email protected]",
"dst": ["tag:prod"],
"check": ["ubuntu"],
"deny": ["root"]
}
]
}srcとdstに裸の*は書けません。dstにポート番号も書けず、22が暗黙で使われます。ポリシーを保存すると、数秒で各端末に反映され、許可を外したユーザーの既存セッションも切れます。
usersとautogroup:nonroot・localpartのroot除外設定
usersには、サーバー上に既にあるOSユーザー名を書きます。Tailscaleがユーザーを作ることはありません。autogroup:nonrootはroot以外の全ユーザー、localpart:*@example.comはログインメールの@より前と同じ名前のユーザーを指します。
手元の端末で使う場合でも、rootをusersに入れるのは避けてください。checkとacceptの両方のルールに該当する接続は、checkのルールが優先され、usersもcheck側の指定だけで判定されます。同じ組み合わせにルールを重ねると、想定より狭くも広くもなるため、1つのsrc・dstの組には1ルールを原則にします。
sshTestsでポリシー変更時に意図しない許可を検出する記述
上の例のsshTestsは、aliceがtag:prodへubuntuで入るとチェックが掛かり、rootでは拒否される、という期待を書いたものです。SSHテストは全プランで使えます。ポリシー変更時に評価され、1つでも外れると保存そのものが拒否されます。
誰かが急いでusersにrootを足しても、テストが残っていれば保存の段階で止まります。権限の緩和をレビューなしで通さない仕組みとして、最初のポリシーと同時に書いておく価値があります。
チェックモードとセッション録画で本番サーバーの操作を監査する設定
鍵をやめただけでは「誰がいつ何をしたか」は残りません。本番サーバーでは、再認証と録画を組み合わせて監査の材料を作ります。
checkPeriodの既定12時間と長さの変更にPremiumが必要な制約
"action": "check"にすると、接続前にIdPでの再ログインを求めます。一度認証を通過した後、チェックモードの接続を再認証なしで使える期間は、既定では12時間です。checkPeriodは1分から168時間まで、または毎回確認するalwaysを指定できます。
Tailscaleの料金ページのFAQによると、チェックモード自体は全プランで使えますが、既定の12時間から変えるにはPremiumかEnterpriseが必要です。alwaysはAnsibleのように短時間で多数の接続を張るツールと相性が悪い、と公式が注意しています。自動化用のアカウントはタグ付きの別ルールに分け、acceptで通すのが現実的です。
tsrecorderのDocker実行とenforceRecorderによる録画漏れ防止
セッション録画の公式手順では、録画の受け側としてtsrecorderのコンテナをtailnetに参加させます。録画はasciinema形式で、ホストのディスクかS3互換ストレージに保存されます。
# タグtag:session-recorderを付けた認証キーを管理画面で発行しておく
export TS_AUTHKEY=<your-auth-key>
docker pull tailscale/tsrecorder:stable
docker run --name tsrecorder --rm -it \
-e TS_AUTHKEY=$TS_AUTHKEY \
-v $HOME/tsrecorder:/data \
tailscale/tsrecorder:stable \
/tsrecorder --dst=/data/recordings --statedir=/data/state --uiあとはポリシーのsshルールに"recorder": ["tag:session-recorder"]を足します。既定ではレコーダーに届かなくても接続は通る「fail open」の動作です。録画のない操作を許したくない本番では"enforceRecorder": trueを加え、レコーダー停止時は接続を拒否させます。
録画されるのは画面に出た出力で、キー入力そのものは残りません。画面に表示した秘密情報は録画に入るため、録画ファイルの置き場所とWeb UIのポート443へのアクセスもポリシーで絞ります。
Tailscale SSHの本番採用条件と踏み台・Session Managerとの比較
Tailscale SSHが向くのは、Linuxサーバーが複数のクラウドや拠点に散らばり、鍵の配布と回収が手作業になっているチームです。逆に、条件が1つ合わないだけで運用が二重になる場面もはっきりしています。
公開SSHを閉じずに導入して新旧の鍵管理が二重になる失敗パターン
最も多い失敗は、Tailscale SSHを有効にしたあともセキュリティグループやファイアウォールでポート22をインターネットに開けたままにすることです。sshdは動き続けるため、古い鍵でも入れる経路が残り、退職者の鍵の削除という元の作業がなくなりません。
導入の完了条件は、Tailscale経由で入れることを確認した後に、公開IP側のポート22を閉じることです。保守用の緊急経路として、クラウドのシリアルコンソールか別のアカウントを1つ残しておきます。tailscaledの更新や再起動で既存のTailscale SSHセッションは切れるため、更新作業そのものは別経路から行う手順にしておくと安全です。
Windowsサーバーや大量の自動接続が多い環境で見送る判断
次のどれかに当てはまるなら、Tailscale SSHは主経路にしません。
- 保守対象にWindowsサーバーが多い（受け側になれない）
- Ansibleなどで数百台に同時接続し、全接続にチェックモードを掛けたい
- Tailscaleを入れられない機器やアプライアンスにSSHで入る必要がある
- AWSのEC2だけで完結し、IAMで権限管理を済ませたい
AWSだけの環境なら、エージェント経由でポートを開けずに入れるSession Managerの使いどころのほうがIAMと監査ログにそのまま乗ります。Tailscaleを入れられない機器が多い場合は、踏み台サーバーの構成と採用判断で経路を1か所に集めるほうが管理しやすくなります。複数クラウドとオンプレミスにまたがる保守経路をどの方式で組むかは、ネットワーク全体の設計と一体で判断すべき事項です。クラウドとネットワークのインフラ構築支援では、保守経路の方式選定から構築までを請け負っています。
料金プラン別のSSH機能差とPersonalの5ホスト上限・録画の扱い
2026年10月3日時点の料金ページでは、Personalが6ユーザーまで0ドル、Standardが1ユーザーあたり月8ドル、Premiumが月18ドルです。SSHに関係する差は次のとおりです。
| 機能 | Personal | Standard | Premium |
|---|---|---|---|
| Basic Tailscale SSH | 5ホストまで | 利用可 | 利用可 |
| チェックモード | 既定12時間 | 既定12時間 | 長さを変更可 |
| localpart照合 | 不可 | 不可 | 利用可 |
| SSHテスト | 利用可 | 利用可 | 利用可 |
セッション録画の扱いは資料によって表記が違います。録画の公式ドキュメントは「PersonalとEnterpriseで利用可」と書き、料金ページの比較表は録画をPrivileged Access Management（営業経由のプラットフォーム拡張）に分類しています。StandardやPremiumの業務tailnetで録画を必須にするなら、契約前に提供条件を確認してください。
Tailscale SSHの導入設定と保守運用についてよくある質問
導入前の検討でよく出る疑問に、公式ドキュメントと変更履歴の記述に沿って答えます。
Tailscale SSHを有効にしても普通のSSHは使えますか？
使えます。Tailscale SSHが引き受けるのは、Tailscale IP宛てのポート22への接続だけです。sshd_configとauthorized_keysは変更されないため、社内LANや公開IP経由のSSHは従来どおり鍵で通ります。この性質のため、Tailscale側で入れることを確認した後に公開側のポート22を閉じる作業を、導入手順に含めてください。
WindowsサーバーにTailscale SSHで入れますか？
入れません。Tailscale SSHのサーバー機能はLinuxとmacOSのオープンソース版tailscaledだけが対象です。Windowsからの接続元としては使えるため、Windows PCからLinuxサーバーへ入る用途には問題ありません。Windowsサーバーの保守は、tailnet内でRDPやOpenSSH for Windowsへ通常の通信として接続し、ポリシーのgrantsでポートを絞る形になります。
Tailscale SSHで接続できないときは何を確認しますか？
まずtailscale statusで両端末がtailnetに参加しているかを見ます。次に、grantsでポート22が許可されているか、sshルールのusersに使うOSユーザーが含まれているかを確認します。サーバー側でtailscale set --sshを実行していない、OSユーザーが存在しない、MagicDNSの名前が引けない、の3つも典型的な原因です。名前で失敗する場合はTailscale IPで試すと切り分けられます。
Tailscale SSHの脆弱性情報はどこで確認できますか？
Tailscaleの変更履歴に、版ごとの修正と関連するセキュリティ情報の番号が載ります。2026年はv1.98.10でUnixソケット転送の権限の問題（TS-2026-004）、v1.102.1で子プロセスへの環境変数の受け渡しの問題（TS-2026-010）が修正されました。最新は2026年9月10日のv1.102.4です。ソースはGitHubのtailscaleリポジトリで公開されています。
Tailscale SSHと自前のheadscaleは組み合わせられますか？
組み合わせられます。制御サーバーを自社で動かすheadscaleも、公式の機能一覧でTailscale SSHを対応済みとしています。ただし、ポリシーの解釈やSaaSの管理画面に依存する機能はheadscale側の実装に従うため、チェックモードや録画を使う前に、使う版の対応範囲を確かめてください。制御サーバーを自前にする判断はheadscaleの構築手順と採用判断で詳しく比較しています。
関連記事
- Tailscaleの安全性は大丈夫？暗号化の仕組み・脆弱性リスク・料金・使い方を解説【2026年最新】：Tailscale全体の暗号化の仕組みと料金プランを確認できます。
- headscaleの使い方：Tailscale互換サーバーの構築手順と0.29系の変更点・採用判断：制御サーバーを自社で持つ場合の構築手順です。
- SSH接続とは？仕組み・公開鍵認証・ポート22から安全な運用設定まで実装者向けに解説：Tailscale SSHが置き換える公開鍵認証の基本です。
- 踏み台サーバーとは？仕組み・SSH多段接続・AWS構築と採用判断【2026年版】：Tailscaleを入れられない機器へ入る経路の代替案です。
- ゼロトラストネットワーク（ZTNA）とは？VPNとの違いと製品選定・導入判断を解説：端末と利用者単位でアクセスを絞る設計の考え方を整理しています。
