Tailscale SSH が認証できないときに確認すること

Tailscale には、 Tailscaleの認証情報を元にsshの認証・認可を行う Tailscale SSH という仕組みが存在する

適切にTailscale のACLを設定したつもりが、以下のようにTailscale SSHの認証が蹴られてしまう場合がある。ここで確認すべきことをメモしておきたい。

Permission denied (tailscale)

basis

Tailscale SSH の How-to から引用・翻訳すると、 Tailscale SSHを利用するには以下を正しく設定する必要がある。

Tailscale SSH のサーバーコンポーネントは、以下でのみ利用可能です。

Linux

macOS (オープンソース tailscale + tailscaled)

接続先から Tailscale SSH をアドバタイズします

送信元がポート 22 で宛先に接続できるようにする Tailnet ポリシー ACL が存在することを確認します。

これには、SSH を含めるように Tailnet ポリシーファイルを変更する必要がある場合があります。テールネットポリシーファイルを変更するには、管理者またはネットワーク管理者である必要があります。

Tailscale SSH を使用して送信元が宛先マシンに SSH 接続できるようにする SSH ポリシー ACL が存在することを確認します。

これには、Tailnet ポリシーファイルを変更して SSH ポリシーを含める必要があります。テールネットポリシーファイルを変更するには、管理者またはネットワーク管理者である必要があります。

特に 4 にハマりポイントがある 。ひとまず順を追って説明していく。

1. Tailscale SSH のサーバーコンポーネント

記載の通り

2. 接続先から Tailscale SSH をアドバタイズする

sshサーバとなるノードで、以下のコマンドを実行する必要がある。これは自動では実行されるものではない。ユーザが明示的にタイプする必要がある。

tailscale up --ssh

3. 送信元がポート 22 で宛先に接続できる Tailnet ポリシー ACL が存在する

sshクライアント → sshサーバに対する 22/tcp へのアクセスがACLで許可されている必要がある。 tag で指定するならば、例えば以下のようなACLが必要になる。

    "acls": [
         {
            // Allow ssh
            "action": "accept",
            "src":    ["tag:ssh-client"],
            "dst":    ["tag:ssh-server:22"],
         },
    ]

4. Tailscale SSH を使用して送信元が宛先マシンに SSH 接続できるようにする SSH ポリシー ACL が存在する

ここが冒頭で述べたハマりポイント 。

マニュアルでは以下のような例が示されている。

    "ssh": [
        {
            "action": "check",
            "src": ["autogroup:member"],
            "dst": ["autogroup:self"],
            "users": ["root", "autogroup:nonroot"]
        },
    ]

ここで注意する点が3つある。

SSHポリシー ACL と Tailnet ポリシー ACL はそれぞれ別の存在
- Tailnet SSHを利用するには、SSHポリシー ACLを記述する必要がある。これは前項のTailnet ポリシー ACLとは別に記述するもので、必ず両方とも必要になる。セクション名が acl ではなく ssh になっていることからも自明だが、これに気づかないと時間を無駄にする
actionは accept でいい
- 例では check になっているが、単純に ssh 接続するだけなら action は accept でよい
src/dstに autogroup や group を利用できるのは tagを付与されていないノード(への|からの)接続のみ である
- tagを設定したノードは group 情報が剥がされたような状態 にあり、 group 情報に基づくACLはマッチしない
- 従って tagを設定したノード(への|からの)アクセスに対する制御は、必ずtagを用いて記述する必要がある

ひとつ前の章のように、 tag: ssh-server tag: ssh-client といった ACL tag を付与したノードからTailscale SSHを利用する場合、このサンプルではACLがマッチしないのだ。したがって冒頭のようにあえなく Permission denied (tailscale) と蹴られる羽目になる。

今回の場合は、以下のようなルールを用意する必要がある。srcもdstも、タグを付与されたノードからアクセスするのならばtagで指定する必要がある。

    "ssh": [
        {
            "action": "accept",
            "src":    ["tag:ssh-client"],
            "dst":    ["tag:ssh-server"],
            "users":  ["autogroup:nonroot", "root"],
        },

    ],

出典は以下のフォーラムから。

SUPPORT QUESTIONS: Permission denied (tailscale)

bronson Oct 2022

I had a similar issue. Finally realized that, when you tag a machine, the owner gets removed (surprising)! Therefore, if you have tagged any hosts (as I see you have done), you also need to name the tags. "tagOwners" doesn't seem to affect anything. (also surprising)

Since Tailscale doesn't seem to allow wildcards like "tag:*", as far as I can tell, you need to name every tag in every dst. (further surprise)
    {
        "action": "accept",
        "src":    ["autogroup:members"],
        "dst":    ["autogroup:self", "tag:production", "tag:staging", "tag:ci", "tag:wildcat"],
        "users":  ["autogroup:nonroot", "root"],
    },
Brief aside: I'm finding the SSH section unnecessarily complex and laborious to use... which is the first time I've said that about Tailscale! But, now that I've named all my tags in the "dst" section, I can SSH successfully.

https://forum.tailscale.com/t/permission-denied-tailscale/2898