引っ越したらサーバーに繋がらなくなったので、固定IPと鍵認証で「どこでも自動接続」を作った話(要約編)
きっかけ
Hermes Agent(自宅UbuntuサーバーのAIエージェント)の会話ログはObsidianに自動保存され、WindowsのメインPCからはSSHFS-WinでZドライブとしてマウントして読める——という環境が前回までに完成していた。
ところが、サーバーとPCごと別の家(実家)に移動したら、Zドライブに繋がらなくなった。パスワードを入れても反応しない。
原因は単純で、接続先を「IPアドレス直指定」にしていたこと。家が変わればルーターが変わり、サーバーに配られるIPアドレスも変わる。パスワードが間違っているのではなく、そもそも接続先が存在しなくなっていたのだった。
そこで今回は、環境が変わっても壊れない接続を目指して3つの作業をした。
-
サーバーのIPアドレスをDHCP予約で固定する
-
SSHをパスワード認証から鍵認証に切り替える
-
SSHFS-Winのマウントもパスワードレスにする
つまずきポイント①:サブネットマスクの罠
「IPを192.168.8.10に固定したい」という一心で、ルーターのLAN設定でサブネットマスクを/16に広げようとしたら、「WAN IPアドレスとLAN IPアドレスを同じネットワークに入れることはできません」というエラーに阻まれた。
これは/16(255.255.0.0)にすると192.168.x.xの全範囲が自分のLANの縄張りになってしまい、上流ルーターから貰っているWAN側のIP(192.168.1.2)まで飲み込んでしまうのが原因だった。二重ルーター構成では、各ルーターのLAN側は/24のまま、上流と被らない番地(192.168.8.x)を使えばそれで十分。正解は「LAN設定は元に戻して、DHCPサーバーのアドレス予約でMACアドレスに対してIPを固定する」だけだった。
教訓:特定の1台のIPを固定したいだけなら、ネットワーク全体の設計(LAN設定)を触る必要はない。
つまずきポイント②:公開鍵の「O」と「0」
鍵認証の設定では、Windows側で作った公開鍵をサーバーのauthorized_keysに登録する。ここで鍵の文字列をコピペ(実際にはスクリーンショット経由の転記)で登録したところ、何度試してもパスワードを聞かれ続けた。
sshdのデバッグログを掘っていくと「鍵は提示されているが、サーバー側が拒否している」ことまでは分かる。権限も設定も全部正常。最後にフィンガープリント(鍵のハッシュ値)を両側で比較したら——全く別の鍵だった。
原因は転記時の文字化け。O(オー)と0(ゼロ)のように見た目がそっくりな文字が、どこかで入れ替わっていた。鍵は1文字違えば完全に別物になる。
解決策は「目視・手打ちを一切やめて、scpで公開鍵ファイルそのものを転送する」こと。これで一発で通った。
教訓:鍵や証明書の類は、絶対に目でコピーしない。ファイルごと転送する。
つまずきポイント③:SSHFS-Winの隠れ仕様
生のSSHが鍵認証で通るようになっても、SSHFS-Win(Zドライブのマウント)はパスワードを要求し続けた。net useのオプションを変え、鍵の形式を変え、何度試しても「アクセスが拒否されました」。
最終的に判明した仕様はこうだった。
-
鍵認証には
\\sshfs\ではなく\\sshfs.k\という別の接続プレフィックスを使う -
そして
.kは、~/.ssh/id_rsaという決め打ちのファイル名の鍵しか読まない
つまり、鍵の中身が何であれ(今回はed25519形式)、ファイル名がid_rsaでないと認識されない。ed25519鍵をid_rsaという名前でコピーして置いたら、次の1行であっさりマウントできた。
net use Z: \\sshfs.k\******@192.168.*.**
教訓:ツールが読む「決め打ちのファイル名」がないか、公式の仕様を先に確認する。 推測でオプションをこねくり回すより、ドキュメントとGitHub Issueを読む方が早い。
結果
-
サーバーは実家のネットワークでは常に192.168.*.**(DHCP予約)
-
SSH・VS Code Remote・SSHFS-Winのすべてがパスワードレスに
-
PCを起動すればZドライブが自動で繋がり、そのままObsidianが開ける
残タスクは自宅側ルーター(GL-SFT1200)での同じDHCP予約のみ。これでサーバーを2拠点どちらに置いても、何も設定せずに同じ体験が得られる。
Written with StackEdit.
0 件のコメント:
コメントを投稿