VSCodeのSSHエージェントはバナナです (2025)

もしみんなが君みたいだったら、AIの安全性はそんなに大きな懸念にはならないだろうね。デフォルトの人間の行動は「火をつけて忘れる」って感じだから、すぐにおかしくなることがあるんだ。

「リモートシステム上のファイルを編集するためのツールは、リモートシステム上のファイルを編集できる。」

うん、これはリモートツールを使ったリモート編集にとって正しいアーキテクチャだよ。すごくうまく機能する。（SSH接続が切れたときの再接続に関する長年のバグはあるけど、それはアーキテクチャのせいじゃない。）

記事で述べられている不安定さについては、何も変わってないよ。問題は、リモートホストがプロトコルを通じてローカルホストを制御できることだ。

Linuxユーザーとして、VSCodeのSSHが嫌いだった。管理が難しくなるイライラする点がたくさんあるんだよね。例えば、MotDを表示しないから、ユーザーに重要なメッセージを伝えられない。セッションも再利用しない（デフォルトではね。ちなみに、sshもそうだけど）。ユーザーから数ヶ月にわたって開いたセッションが何十も残ってることもあった。人を強制的にログアウトさせるスクリプトを書かなきゃいけなかったよ… プラグインが単なるラッパーで、ユーザーがsshを知っていることが前提ならまだしも、プラグインはその全てを抽象化して「リモートマシンでVSCodeを使う」ツールになってる。だから、認証情報を扱うだけじゃダメで、そうしないと人々はただのsshだと思ってしまう。

VSCodeの理念は軽量で、Notepad++にターミナルが付いたようなものであるべきだった。開発者たちが本筋を見失ってるよ。機能が豊富なSSHエージェントが欲しいならVisual Studioを勧めてほしい。開発者のトレンドがVSCodeを超強化して、拡張機能でピカピカに見えるけど、これは逆効果だよ。全体の目的を台無しにしてる。

それが出てから毎日使ってるよ。最初は、重いクライアントプロジェクトでDockerがMacを遅くするのに疲れたからなんだけど、今はファイル編集ができる簡単なSSHクライアントとして使ってる。vimやnanoはあんまり好きじゃないんだ。同じIDEに全てをまとめられるのは、俺にとっては大きい。

低スペックの512MB RAMのVPSサーバーでは使えないよ。誰かがファイル操作のためにノードランタイム全体をバンドルするのがいいアイデアだと思ったから。

私はVSCodium（VSCodeのクロム系バージョン）を使ってて、この拡張を入れてるよ: https://github.com/jeanp413/open-remote-ssh エディタ（とその拡張）、プロジェクト、エージェントハーネスをコンテナ内で動かして、その拡張を使ってエディタを手に入れてる。これは主に、悪意のある拡張や依存関係、ロゲエージェントから自分の資格情報やデータを守るためなんだけど、開発環境をどのマシンにもすぐに移行できるっていう利点もある（家ではLinux、仕事ではmacOSを使ってる）。podmanをインストールして、VSCodiumをインストールして、SSH拡張を追加して、イメージをビルドして、ユーティリティシェルスクリプトを追加すれば（コンテナ内に出入りするのを素早くするため）、完了。どうやらマイクロソフトは一部のVSCode APIを独占的にしてるから、自社の拡張しか使えないらしい（セキュリティ上の理由でらしいけど）。だから、この特定の拡張はVSCodiumでしか動かないんだよね。この記事が指摘してるような脆弱性に対しても脆弱なのかな。