Clash Verge RevのSSH秘密鍵エラー：サービスモード修正

公式issue #8445では、Windows 11のClash Verge Rev v2.5.8でSSH秘密鍵ファイルを使うとTUNを有効にできない事例が報告されています。相対パスではファイルが見つからず、絶対パスに変えるとSAFE_PATHSの制限にかかります。後続のcode 1006は、コアが準備できなかったことを示す上位で通知されるエラーです。

公式v2.5.10には、サービスモードでのSSH秘密鍵ファイルの修正が含まれています。この記事が扱うのは、ファイルをサービスのコアに渡す際の問題です。あらゆるTUN障害の解決や、Windowsの単一報告を基にした三つのシステムでの動作確認を意味するものではありません。

Mihomoのprivate-keyには、秘密鍵の内容またはファイルパスを指定できます。この記事ではファイルパスだけを扱います。パスのエラーを避けるために、秘密鍵全体をサブスクリプション、公開設定、問い合わせ用のスクリーンショットに貼り付けないでください。

サービスのコアは独立した実行ディレクトリを使うため、アプリのディレクトリ内の相対パスをそのまま読めるとは限りません。v2.5.10では、条件を満たすローカルの秘密鍵をサービスの実行ディレクトリに一時配置し、サービスに渡す設定も書き換えます。利用者がサービスのディレクトリへ手作業でファイルを追加する必要はありません。

この修正にも条件があります。ファイルが実在し、パスを解決した後の実際の場所がアプリの実行用設定ファイルの親ディレクトリ内にある必要があります。相対パスはこの親ディレクトリを基準にします。絶対パスも同じ制限を受けるため、ディスク上の任意のファイルを読めるわけではありません。

処理対象は、トップレベルのproxiesとproxy-providersのpayloadにあるSSH項目です。リモートのproviderファイル内の任意のノードまで再帰的に調べる保証はありません。インラインの秘密鍵、WindowsのUNCパスやデバイスパスも、今回の通常のローカルファイルを一時配置する処理の対象外です。

まず現在のProfile、カスタム上書き、元のプロキシモードを保存し、復元できる外部コピーを用意します。秘密鍵ファイルの原本も別に残してください。設定のZIPだけでは、外部のSSHファイルが含まれているとは限りません。バックアップは自分で管理できる場所に保管し、問い合わせには機密情報を除いた別のコピーを使います。

「設定 → Verge詳細設定 → 設定ディレクトリを開く」を開きます。ここがアプリの設定ディレクトリで、実行用設定ファイルの親ディレクトリでもあります。相対パスの基準をprofilesサブディレクトリにしたり、サービスの実行ディレクトリへ手作業でファイルを追加したりしないでください。

開いたディレクトリ内のsshサブディレクトリに、信頼できる秘密鍵のコピーをアクセス制限付きで置きます。自分で管理するProfileまたは永続的な上書きにprivate-key: 'ssh/id_ed25519'と記述し、実際のファイル名に合わせてください。元の秘密鍵は動かさず、元に戻せるように残します。

対象が通常のファイルで、アプリから読み取れること、ディレクトリ外を指すシンボリックリンクではないことを確認します。拡張子を変えて不足したファイルの代わりにしないでください。再生成される実行用YAMLを直接編集せず、秘密鍵を公開リポジトリに追加したり、元のファイル保護を解除したりしないでください。

修正箇所は、Clash Verge Revアプリがサービスの実行用リソースを準備するコードです。Mihomoだけの更新、サブスクリプションの更新、TUNの繰り返し切り替えでは、アプリ全体の更新の代わりになりません。同じ修正が含まれる根拠のある後続の正式版を使っている場合、この記事のためにv2.5.10へ戻す必要もありません。

参考資料にある公式v2.5.10 Releaseから、自分のシステム、チップのアーキテクチャ、従来のインストール方法に合うものへ更新します。今回、当サイトで配信するインストールパッケージは置き換えていません。古いパッケージをダウンロードできても、この修正が含まれる証拠にはなりません。

コアの準備ができ、秘密鍵のパスやSAFE_PATHSのエラーで終了しなくなったことを確認してから、必要な元のSSHノードを選び、新たに実際のリクエストを送ります。クライアントの「接続」画面で今回のリクエストが想定したSSHの出口を通ったか確認し、実際の処理が成功したことも確かめます。

コアが起動しても、SSHへのログインが成功したとは限りません。遅延の数値やTUNスイッチの点灯だけでは、認証、ホスト鍵の検証、実際の通信が正常だと証明できません。その後に認証エラーが出たら、SSHサーバーと認証情報を調べます。host-keyを削除して検証を解除しないでください。

当サイトは、実際のクライアントでこの問題のインストール検証や再現を行っていません。この記事は、公式のユーザー報告、正式リリース、固定したソースコード、SSH設定ドキュメントに基づいています。ウェブサイトの翻訳、ソースレベル、ブラウザーのチェックは、利用する端末での実際の接続確認の代わりにはなりません。

すぐに更新できない場合は、動作を確認済みのSSH以外のノードや元の設定に戻し、作業を再開できます。ただし、古いサービスモードの秘密鍵の問題が修正されたわけではありません。制限を避けるためにディスク全体を読み取り可能にしたり、すべての利用者に書き込み権限を与えたり、鍵をサービスのディレクトリに移すことを恒久的な対処にしたりしないでください。

問い合わせには、オペレーティングシステム、アプリの完全なバージョン、サービスモード、private-keyにファイルと内容のどちらを指定したか、機密情報を除いたディレクトリの関係、最初のエラーを添えます。秘密鍵、パスワード、サブスクリプションのトークン、完全な設定パッケージは送らないでください。