SSH鍵管理という悪夢の終わり
かつての私は、月曜日の朝といえば新しい開発者に公開鍵を催促することに時間を費やしていました。新しいメンバーが加わるたびに、数十台もの本番環境やステージング環境েরサーバーにそれらの鍵を手動で配布しなければなりませんでした。また、外部パートナーのプロジェクトが終了すれば、すべての authorized_keys ファイルから彼らのアクセス権を細心の注意を払って削除する必要がありました。これは手作業でミスが起きやすく、モダンなDevOpsのワークフローとは程遠い、苦痛な作業でした。
半年前に,私はインフラ全体を Tailscale SSH に移行しました。目的は明確です。個別の鍵を排除し、ポート22をパブリックインターネットから隠すことでした。本番環境で半年運用してみた結果、その効果は絶大でした。公開IPへのブルートフォース攻撃を心配する必要はもうありません。単純に、ハッカーがスキャンできる公開SSHポートが一つも残っていないからです。
ポート22の脆弱性を超えて
従来のSSHは、到達可能なIPアドレスと暗号鍵ペアに依存しています。これはベストプラクティスに従えば安全ですが、「可視性」という大きな欠陥があります。標準的なクラウドVPSで /var/log/auth.log を確認すれば、世界中のボットネットから毎日5,000回以上のログイン試行失敗が記録されているのがわかるでしょう。これは不必要なノイズであり、リスクでもあります。
Tailscale SSH は、このロジックを逆転させます。ファイル（鍵）を検証する代わりに、あなたのアイデンティティ（身元）を検証します。Tailscale は WireGuard をベースに構築されており、デバイス間に「Tailnet」と呼ばれるプライベートなメッシュネットワークを作成します。接続しようとすると、Tailscale は Google、Microsoft、Okta などのプロバイダーで認証されたあなたのアイデンティティが、その特定のマシンへのアクセス権限を持っているかを確認します。アイデンティティが一致すれば、接続は暗号化され、安全なトンネルを通じてルーティングされます。
ここが重要なポイントです。サーバーのSSHデーモンは、パブリックインターフェースで待機する必要すらありません。ファイアウォール（UFW、iptables、AWSセキュリティグループなど）を設定して、ポート22へのすべての着信トラフィックをブロックできます。Tailscale サービスが実行されている限り、どこからでも安全に接続できます。
環境のセットアップ
セキュリティは強固な基盤から始まります。従来のSSHから移行するとはいえ、初期セットアップや緊急時のローカルアクセスのために、強力なrootまたはsudoパスワードは依然として必要です。サーバー構築の際、私は toolcraft.app/ja/tools/security/password-generator のパスワードジェネレーターを使用しています。これは完全にブラウザ内で動作し、データがマシン外に出ることはないため、32文字の高エントロピーな文字列を生成する信頼できる方法です。
ステップ1：サーバーに Tailscale をインストールする
まず、対象のマシンで Tailscale エージェントを実行します。ほとんどの Linux ディストリビューションでは、次のシンプルなスクリプトを使用できます。
curl -fsSL https://tailscale.com/install.sh | shステップ2：認証とSSHの有効化
次に、ノードを Tailnet に参加させます。--ssh フラグを使用して、Tailscale にこのマシンのSSHトラフィックを処理するように指示します。
sudo tailscale up --sshこれを実行した後、表示されたURLにアクセスしてブラウザでマシンを認証します。これでサーバーはプライベートネットワークの一部になりました。--ssh フラグは、Tailscale デーモンに Tailscale インターフェース（通常は 100.x.y.z）での接続をリッスンするよう指示し、標準の sshd を事実上バイパスします。
アクセス制御リスト（ACL）の定義
Tailscale SSH が有効になると、セキュリティロジックはローカルのサーバーファイルから中央集権的な管理コンソール（Admin Console）へと移行します。すべては JSON ベースのアクセス制御リスト（ACL）で管理されます。ここで、誰がどのリソースにアクセスできるかを正確に定義します。
私たちの本番環境の設定では、ユーザーを group:admin や group:dev などのカテゴリーにグループ化しています。以下は、私がアクセス管理に使用している設定の簡略版です。
{
"groups": {
"group:admin": ["[email protected]"],
"group:dev": ["[email protected]", "[email protected]"]
},
"ssh": [
{
"action": "accept",
"src": ["group:admin"],
"dst": ["tag:production", "tag:staging"],
"users": ["root", "ubuntu", "admin"]
},
{
"action": "check",
"src": ["group:dev"],
"dst": ["tag:staging"],
"users": ["ubuntu"],
"checkPeriod": "12h"
}
]
}"action": "check" 機能は画期的です。これにより、SSH接続が許可される前に、ユーザーにブラウザでの多要素認証（MFA）チェックを強制できます。これは、膨大なカスタム設定なしでは標準のSSH鍵では実現できないレベルのセキュリティを提供します。
表玄関を閉める
Tailscale 経由で接続できることを確認したら、ポート22をロックしましょう。Ubuntu で UFW を使用している場合は、次のコマンドを実行します。
sudo ufw deny 22/tcp
sudo ufw reloadAWS や DigitalOcean を使用している場合は、セキュリティグループのポート22のインバウンドルールを削除します。これで、サーバーはインターネット上の絶え間ないSSHスキャナーのノイズから姿を消しました。
日常のワークフロー：検証とモニタリング
サーバーへの接続は非常にスムーズになりました。ローカルマシンで秘密鍵ファイルを管理したり、IPアドレスを覚えたりする必要はありません。サーバーの Tailscale ホスト名を使用するだけです。
tailscale ssh ubuntu@prod-db-01パスワードや鍵のパスフレーズを求められることはありません。すでにラップトップで Tailscale にログインしているため、私のアイデンティティは証明済みだからです。認証されていないデバイスから接続しようとしても、ネットワークレイヤーで接続が拒否されます。
中央集権的な監査
この数ヶ月で最も驚いたのは、ログの質の高さです。Tailscale の管理コンソールでは、フリート全体のすべてのSSH接続のリアルタイムレコードを確認できます。どのユーザーが、どのターゲットマシンに、どの認証方法で接続したかが一目でわかります。
サーバー自体でも、who や last といった標準コマンドは引き続き機能します。Tailscale はシステムのログイン記録と統合されているため、既存の監査スクリプトが壊れることはありません。高度なセキュリティが必要な環境向けに、Tailscale は「セッションレコーディング」も提供しています。これは入力されたすべてのコマンドと受信したすべてのレスポンスをキャプチャし、後で確認できるように安全なストレージバケットにストリーミングします。
信頼性と「非常用（Break-Glass）」シナリオ
同僚からはよく、Tailscale がダウンしたらどうなるのかと聞かれます。調整サーバーに到達できなくなったとしても、既存の接続は維持されます。Tailscale は分散型アーキテクチャを採用しているため、全面的なダウンは極めて稀です。
しかし、念のため緊急用のローカルユーザー（Break-Glass user）は保持しています。AWS Systems Manager や DigitalOcean のリカバリコンソールなど、クラウドプロバイダーのウェブコンソール経由でのみアクセス可能な高エントロピーなパスワードを使用しています。これにより、自社のハードウェアからロックアウトされることは決してありません。
ゼロトラストへの転換
アイデンティティベースのSSHへの移行は、境界セキュリティに対する私の考え方を根本から変えました。ポート22の周りに厚い壁を築く「城と堀」戦略は捨て去りました。その代わりに、ユーザーの場所に関係なく、すべての接続をアイデンティティによって検証するゼロトラストモデルを採用しています。
もしあなたが ~/.ssh/authorized_keys の管理に疲れ果てているなら、ぜひこれを試してみてください。最初のサーバーをセットアップするのにかかる時間は20分ほどです。一度鍵のないアクセスを体験すれば、二度と手動管理には戻りたくなくなるはずです。
