向きが逆でもいい
Tailscaleの記事では「出先から自宅のパソコンへ」という向きで書きました。スマホから母艦につないで、寝ながら開発する、という話です。
ですが同じ仕組みは、逆向きにも、横向きにも通ります。
- 母艦のMac miniから、持ち出し用のMacBook Airへ
- MacBook Airから、置きっぱなしのミニPCへ
自分のデバイス同士が「同じ家の中にいる」状態になるだけなので、どっちがどっちを呼んでもいい。 ここに気づくと、使い道が一段増えます。
何をしたか
先日、こういうことがありました。
MacBook Airのほうでzコマンド（cdを打つのが面倒になったらで紹介したzoxide）のTab補完が働かない。直し方はMac mini側で作業していたエージェントとの会話で判明していて、~/.zshrcに数行足せば済む。
普通なら、エージェントに手順を書いてもらって、それを自分でMacBook Airに貼り付けます。 それでもいいのですが、こう頼んでみました。
Tailscaleでそっちに入って、直しておいて
結果、エージェントがやったのはこれだけのことです。
- Tailscale経由でMacBook Airに接続できるか確認
~/.zshrcをバックアップ- 設定を追記
- 文法チェック
- 向こうでシェルを起こして、実際に
z+Tabを打って、意図した場所に移動できることを確認 - 検証に使った一時ファイルを削除
5番が肝です。「たぶん動くはずです」ではなく、向こう側で動かして確かめてから報告してくる。 手順書を受け取って自分で貼る場合との違いはここにあります。うまくいかなかったときに気づくのが、自分ではなくエージェントになる。
詰まるのは「届くか」ではなく「入れるか」
このとき最初に返ってきたのは、こういう報告でした。
- Tailscaleの到達性 … OK（往復6ミリ秒）
- SSHの入口（22番ポート） … 開いている
- ログイン … 失敗
Permission denied (publickey,password,keyboard-interactive)ネットワークは最初から通っていて、止まっていたのは認証だけだったわけです。
この切り分けの順番は、覚えておくと毎回効きます。
| 確認すること | 分かること |
|---|---|
相手が一覧に表示されているか（tailscale status） |
そもそもオンラインか |
| 22番ポートが開いているか | 相手が接続を受け付ける設定になっているか（Macなら「リモートログイン」がON） |
| ログインできるか | 鍵かパスワードの問題 |
上の2つが通っていれば、ネットワークやTailscaleを疑うのはやめていいということです。「繋がらない」と一括りにすると、関係ないところを延々と触ることになります。
ちなみに上のエラーメッセージの(publickey,password,keyboard-interactive)は「この3つの方法なら受け付けますよ」という案内であって、失敗した理由の説明ではありません。ユーザー名を間違えたときも同じ文言が表示されるので、これだけでは原因を絞れない、というのも知っておくと悩まずに済みます。
SSHの鍵を使う設定にしてあるかどうかで、任せられる範囲が変わる
ここが、この記事でいちばん書きたかったところです。
パスワードでログインする設定のままだと、エージェントには頼めません。 パスワードを渡すわけにはいかないからです。渡さない限り、エージェントは入口の前で止まります。
鍵（公開鍵認証）にしてあれば、頼めます。 エージェントは手元にある鍵を使って、パスワードを一度も見ることなく向こうへ接続できます。
つまりSSH鍵の設定は、「パスワードを打つのが面倒だから」の話ではなくて、「作業を人以外に任せられる形にしておく」という話でもあります。自動化やエージェントが絡んだ瞬間に、この差が表面化します。
やることは、接続される側で1行です。手元の公開鍵（.pubで終わるファイルの中身）を、向こうの~/.ssh/authorized_keysに書き足します。
mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo 'ssh-ed25519 AAAA...ここに公開鍵の中身... you@example.com' >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys公開鍵のほうは、人に見せても構わないものです（秘密鍵は絶対に渡しません）。この区別が曖昧ならSSHの肝を先に読んでおくと安心です。chmodが付いているのは、権限が緩いとSSHが鍵を無視するためで、ここは省略できません。
落とし穴：似た名前のマシンが2台あると
今回いちばん時間を溶かしかけたのが、これです。
Mac mini側の~/.ssh/configには、すでにairという接続先が登録されていました。が、それが指していたのは別のMacBook Airで、しかも2日前からオフラインでした。同じ人が同じような名前のマシンを2台持っていると、普通に起こります。
Host air
HostName 100.99.45.67 ← こっちは前の機体（オフライン）名前で呼べるのは便利ですが、その名前が今どの機体を指しているかは、自分で確かめないと分かりません。 tailscale statusを見ると、各デバイスのアドレスと、オンラインかどうか、最後に見かけたのがいつかが並びます。
100.86.12.34 my-macbook-air macOS active; direct ...
100.99.45.67 my-macbook-air-1 macOS offline, last seen 2d ago古いエントリは、削除するより別名で足すほうが安全です。削除すると、そのうち戻ってきた機体に繋げなくなります。
Tailscale SSHという別解（ただしMacでは）
Tailscaleには、鍵の管理そのものを省く「Tailscale SSH」という機能があります。鍵を配らなくても、Tailscaleのアカウントで認証が済む仕組みです。
魅力的なのですが、接続される側がMacだと基本的に使えません。 公式ドキュメントでは、サーバー側の対応が「Linux」と「macOSのオープンソース版（tailscaledのCLI版）」に限られると明記されています。App Storeからインストールした普通のMac版は、接続する側にはなれても、接続される側にはなれません。
Mac同士でやるなら、素直にSSH鍵を置く。これが今のところの答えです。
任せる前に決めておくこと
便利ですが、別のパソコンを触らせるということなので、線引きだけ先に決めておくのが良いと思います。
- 相手は自分の持ち物に限る。 借り物や貸与品は、そもそも規則の確認が先です（Tailscaleの記事にも書いたとおり、ネットワークに関わる道具なので勝手にインストールしてよいとは限りません）
- 設定ファイルは触る前にバックアップさせる。
~/.zshrcのような、壊れると次からシェルが立ち上がらなくなるファイルは特に。今回も~/.zshrc.bak-20260810を残してあります - 何をどう変えたか、報告させる。 向こうで起きたことは自分の画面に映りません。追記した内容そのものを見せてもらうのがいちばん確実です
- 一時ファイルを片付けさせる。 検証用のファイルが相手のマシンに残りがちです
どれも「エージェントだから」という話ではなく、自分がリモートで作業するときにやるべきことと同じです。相手が自分でなくなったぶん、口に出して指示する必要があるだけ、と考えると分かりやすいと思います。
まとめ
Tailscaleは「出先から自宅へ」の道具として紹介されがちですが、実態は自分のデバイス同士をつなぐ回線なので、向きは自由です。
そして繋がった先は、自分が手で作業する場所であると同時に、エージェントに任せられる場所でもあります。その境目にあるのが鍵認証です。パスワードのままだと自分しか接続できない。鍵にしておくと、頼める。
2台目のパソコンが「たまに持ち出す、設定が古いままのマシン」になりがちなら、繋いで、任せてしまうのは悪くない手です。