VSCodeのSSHエージェントはひどすぎる
(fly.io)-
VSCodeとリモート編集
- VSCodeには、SSHを通じてリモート編集をサポートする機能がある。
- 多くのユーザーがVSCodeとLLM（大規模言語モデル）を使ってコード生成を行っている。
- LLMが誤ったコードを生成することは「ハルシネーション」と呼ばれ、これに対処するには「エージェント」設定によってLLMと実行環境のあいだのループを閉じることが重要である。
- この過程は、LLMがコードを生成し、エージェントがコードを実行してエラーを出し、その結果をLLMにフィードバックして繰り返す形で進む。
-
開発環境での問題点
- このような反復的な開発プロセスが開発者のノートPC上で発生するのは望ましくない。
- LLMはシステム構成にも影響を与えうるため、この種の作業はクリーンな状態のLinuxインスタンスで行うのが望ましい。
-
EmacsとTramp
- Emacsは、Trampという便利なElispを通じてリモート編集システムをサポートしている。
- Trampは、SSHセッションを通じてBourneシェルのコマンドを実行できる対話的な環境に接続できる。
-
VSCodeのアプローチ
- VSCodeにもTrampに似た機能があるが、Trampとは異なり、リモート接続先に対して全面的に入り込もうとする。
- Bashスニペットステージャーを実行してエージェントをダウンロードし、Nodeのバイナリのインストールまで行う。
- エージェントはポートフォワーディングされたSSH経由で動作し、WebSockets接続を通じてVSCodeフロントエンドとつながる。
- この接続の基盤プロトコルは、ファイルシステムを探索し、任意のファイルを編集し、独自のシェルPTYプロセスを起動し、永続性を持つことができる。
-
セキュリティ上の懸念
- 開発サーバーでVSCodeをリモート編集用途として無造作に使うと、機密情報やインフラ保護に問題を引き起こしかねない。
- 特に実運用環境（プロダクション）で問題が発生した際にVSCodeのリモート編集を使うのは非常に危険だという懸念がある。
-
結論
- Fly.ioの内部では、Fly MachineとVSCodeを直接接続するために、このような複雑なエージェント方式が必須というわけではない。
- ただし、ブログ執筆の目的でVSCodeのリモート接続方式を調べることになり、その過程で以上のような事実が分かった。
1件のコメント
Hacker Newsの意見
1か月ほどソフトウェアについて長文を書こうとしていた。Kurtはブログに記事を書かないので気にしている。短い文章を書くことにした。30分以内に書けそうだと思った
VSCodeの動作を知れば知るほど、その場しのぎで維持されているように見える。SSH拡張だけ見ても、ワークスペースURIには2つの形式がある
このセキュリティ問題が理解できない。SSHでマシンに接続してソケットをフォワードできるなら、他のこともできるはずだ
ネットワークサーバーを運用していて、学生たちがOpenSSHクライアントを理解していないのが大きな問題になっている
VSCodeのSSH編集機能はよく動く。リモートマシンでvim、nano、microを使わなくなった
リモートコード実行が可能だと知った。開発ツールに対する誤った信頼は、しばしば後悔につながる
「SSHエージェント」という用語は紛らわしい。通常は認証トークンをキャッシュするデーモンを意味する
sshfsを勧める人は、VSCode SSH Remote環境の利点を理解していない
開発サーバーでVSCodeのリモート編集を許可するのは不安だ。プロダクションサーバーではなおさらだと思う
ローカルのVSCodeインスタンスがシンクライアントになり、リモートインスタンスが重い処理を担う