TailscaleでMac miniにSSHできなくなった日

最近、Tailscale経由でMac miniにSSHできなくなった。

Mac miniは、常時起動している自分用の開発環境として使っている。
家の外からでもTailscale経由で安全にSSHできるようにしていて、iPhoneやAndroidからも入れるようにしていた。

ちょっとしたログ確認や設定変更くらいなら、スマホからSSHして済ませられる。
そのくらいには、日常的に使っていた環境だった。

Photo: Blue Ethernet Cable by Open Grid Scheduler / Grid Engine — CC0 1.0 (license) via Openverse

ところが、ある日突然つながらなくなった。

最初に疑ったのはTailscaleだった。
ちょうど最近macOSをアップデートした記憶もあったので、

「macOSアップデートでTailscaleかSSH周りが壊れたのでは？」

と思った。

でも、調べていくと、話はそんなに単純ではなかった。

22番ポートは開いていた

まず、Mac mini側でSSHが待ち受けているか確認した。

sudo lsof -nP -iTCP:22 -sTCP:LISTEN

結果を見ると、*:22 (LISTEN) になっていた。

つまり、SSHサーバ自体は起動している。
22番ポートも開いている。

この時点で、少なくとも「SSHが起動していない」とか「ポートが閉じている」という話ではなさそうだった。

Tailscale経由でMac miniに到達できていないというより、SSHの認証フェーズで落ちている可能性が高い。

ここでようやく、

「ネットワークではなく、認証っぽい」

と切り分けられた。

sshdの設定も普通だった

次に、sshdの設定を確認した。

sudo sshd -T | grep -E 'passwordauthentication|kbdinteractiveauthentication|usepam|pubkeyauthentication|allowusers|denyusers|authenticationmethods'

結果はこんな感じだった。

usepam yes
pubkeyauthentication yes
passwordauthentication yes
kbdinteractiveauthentication yes
authenticationmethods any

パスワード認証も、keyboard-interactiveも有効。
公開鍵認証も有効。
AllowUsers や DenyUsers で明示的に塞がれているわけでもなさそうだった。

sshdの設定だけを見ると、かなり普通に見える。

それなのに、ssh -vvv で見ると、認証フェーズに入ったあとに切られる。

このあたりから、だんだん

「これはTailscaleではないな」

という気持ちになってきた。

怪しかったのはユーザー名

自分は昔から、Mac miniに対して yoshiki というユーザー名でSSHしていた。

でも、改めて確認してみると、macOS上の正式なユーザー名は oohashiyoshiki だった。

id yoshiki
id oohashiyoshiki

確認すると、どちらも同じUIDを指していた。

つまり、yoshiki という完全に別のユーザーがいるわけではない。
oohashiyoshiki というユーザーに対して、何らかの別名として yoshiki が解決されているような状態だった。

ここがかなり気持ち悪かった。

id yoshiki では存在するように見える。
でも、macOSのユーザーレコードを見ると、正式には oohashiyoshiki が本体っぽい。
SSHでは yoshiki として認証しにいって、途中で切られる。

「存在するけど、ログインユーザーとしては微妙」

みたいな状態になっていた。

Unixっぽい感覚だと、id で引けるなら大丈夫そうに見える。
でもmacOSの場合、DirectoryServiceやログイン許可の仕組みが絡むので、そこまで単純ではなかった。

さらにSSH禁止グループに入っていた

もう一つ大きかったのが、ユーザーの所属グループを見たときにこれが出ていたことだった。

com.apple.access_ssh-disabled

名前の通り、SSHアクセスを無効にするためのACLっぽい。

ここで、かなり原因に近づいた感じがあった。

SSHサーバは動いている。
22番ポートも開いている。
認証方式も有効になっている。

でも、ユーザーがSSH禁止側のグループに入っていたら、当然ログインはできない。

しかも、個別ユーザーとして入っているというより、NestedGroupsとして何かのグループごと ssh-disabled 側に入っているようにも見えた。

たぶん、macOSの

「システム設定 > 一般 > 共有 > リモートログイン」

の裏側で管理されているものだと思う。

このあたりで、ようやく問題の輪郭が見えてきた。

Tailscaleではなく、macOS側のRemote Login設定。
もっと言うと、SSHの入口は開いているけど、そのユーザーが入っていい状態ではなかった。

ここでやらかした

原因を追っているうちに、

「じゃあ oohashiyoshiki と yoshiki が混在しているのが悪いのでは？」

と思った。

そして、勢いでホームディレクトリをリネームしてしまった。

sudo mv /Users/oohashiyoshiki /Users/yoshiki

これは、やってはいけなかった。

macOSのユーザーレコード上では、まだホームディレクトリが /Users/oohashiyoshiki を向いている。
でも、実体は /Users/yoshiki に移動してしまった。

すると、macOSが新しく /Users/oohashiyoshiki を作ってしまい、ホームディレクトリが分裂した。

確認すると、こんな状態になっていた。

/Users/oohashiyoshiki  ← 新しく作られたっぽいホーム
/Users/yoshiki         ← 元のホーム本体

この瞬間はかなり焦った。

「SSHできない」から始まった話なのに、気づいたらホームディレクトリを分裂させている。
だいぶ嫌な汗が出た。

ただ、幸いにも元のホームは消えていなかった。
/Users/yoshiki に残っていたので、戻せばよかった。

いったん元に戻すのが正解だった

この手の作業では、いきなり「理想の状態に直す」のではなく、まず「元の安全な状態に戻す」のが大事だった。

やるべきことは、いったんこうだった。

cd /Users
sudo mv /Users/oohashiyoshiki /Users/oohashiyoshiki.broken-$(date +%Y%m%d%H%M%S)
sudo mv /Users/yoshiki /Users/oohashiyoshiki
sudo chown -R oohashiyoshiki:staff /Users/oohashiyoshiki

つまり、

• 新しくできてしまった /Users/oohashiyoshiki は退避する
• 元のホーム本体だった /Users/yoshiki を /Users/oohashiyoshiki に戻す
• 所有者を oohashiyoshiki:staff に戻す

という流れ。

この時点で、yoshiki に統一したい気持ちは一旦捨てる。
まずはMac miniに普通にログインできる状態を復旧する。

こういうとき、つい「せっかくだから綺麗に直そう」と思ってしまう。
でも、焦っているときのリネーム作業はだいたい危ない。
まずは壊す前の状態に戻す。
そこから改めて考えるべきだった。

学び

今回の学びはかなり多かった。

まず、TailscaleでSSHできないからといって、Tailscaleが悪いとは限らない。

今回は、Tailscaleそのものの問題というより、

• macOSのRemote Login
• sshdの認証設定
• macOSユーザー名
• SSHアクセス許可ACL
• ホームディレクトリ

が絡んだ問題だった。

次に、macOSのユーザー名変更は雑にやってはいけない。

特に、ログイン中のユーザーのホームディレクトリを直接 mv するのは危険。
やるなら、一時的な管理者ユーザーを作って、そこから正式な手順で変更するべきだった。

そして、id username でユーザーが解決できることと、SSHログインできることは同じではない。

今回のように、id yoshiki では解決できるのに、SSHでは認証に失敗することがある。
macOSのDirectoryServiceやRemote LoginのACLが絡むと、単純なUnixユーザーの感覚だけでは見落とす。

このへんは、普段Linuxサーバを触っている感覚のままmacOSを見ると、普通に罠にハマる。

今後の方針

まずは、正式ユーザー名である oohashiyoshiki を使ってSSHを復旧する。

iPhoneやAndroidのSSH設定も、いったん全部こうする。

User: oohashiyoshiki
Host: yoshiki-macmini
Port: 22

そのうえで、あとから落ち着いて yoshiki に統一する。

そのときは、必ず一時管理者ユーザーを作る。
ログイン中のユーザー自身を直接リネームしない。
ホームディレクトリとユーザーレコードをセットで変更する。

今回、かなり焦ったけど、最終的には原因の方向性が見えた。

Tailscaleが壊れたと思ったら、実はmacOSのユーザー管理とSSH ACLの話だった。

こういう地味なトラブルほど、あとから振り返ると一番学びがある。
派手な障害ではないけど、自分の開発環境をちゃんと持つなら、こういう足元の理解がけっこう大事だなと思った。