#ssh

最初に思ったのは、これは「AIツールが危ない」という話というより、開発者が日常的に信じている配布経路そのものが壊されるのが一番きつい、ということだった。Claude Code みたいに、使う側からするとかなり自然に入れてしまう拡張機能が、Cursor の marketplace 側で差し替えられていたわけで、悪意あるコードが紛れ込む余地がある場所がこんなに身近なのかと少しぞっとした。 それと、攻撃の中身が派手な情報窃取ではなく、host reconnaissance と SSH の reverse tunnel だったのも印象に残った。要するに、まずは「このPCは何者か」を集めて、入れるなら恒久的に入るための足場を作る。こういう地味な動きは、いかにも実戦的だと思う。派手に壊すより、開発者端末を静かに踏み台にする方がずっと厄介だ。 Cursor が急いで marketplace を止めて鍵を全部回した、という対応はかなり真っ当だと思う一方で、記事を読む限り、単に拡張機能を消せば終わりではないのも嫌なところだ。persistence script が残るので、後から SSH key

LinuxのSSHログインは、鍵認証を使っていれば安全、という感覚を持ちやすい。ところが今回の話は、その前提をかなり嫌な形で崩している。musl libc を使う環境の OpenSSH で、2016年から一部の「本来はパスワードを受け付けないアカウント」に、長い文字列なら通ってしまう穴があったという。しかも Alpine Linux だけでなく、OpenWrt、Buildroot、Yocto、そして多くの Docker イメージにも関係する話だ。単なる珍しいバグではなく、普段の運用に紛れ込んで見逃されやすいタイプの不具合として読むべきだと思う。 元記事が伝えているのは、OpenSSH が musl Linux 上で動いているとき、ある条件のアカウントに対して「長いパスワード入力」が誤って受け入れられていた、という話だ。対象は root、鍵認証だけにしている deploy 用ユーザー、LDAP ユーザー、そして Alpine の AWS/Azure 公式イメージにあるデフォルトユーザーのように、そもそも通常のパスワードログインを想定していないアカウントだ。記事によれば、こうしたアカウント

最初に思ったのは、こういう事故は「AIが危ない」というより、「配布の信頼をどこまで自動で信用しているか」が危うい、ということだった。Cursor の marketplace に、見た目は Anthropic の Claude Code 拡張が普通に並んでいて、しかもそれを入れた瞬間に SSH backdoor を仕込まれる。開発者向けツールの世界では、コードを書くための拡張そのものが攻撃入口になるんだなと、改めて嫌な感じがした。 それにしても、この記事で少し救われるのは、攻撃コードに雑さがあって、Windows と macOS の両方で SSH の有効化に失敗しがちだった点だと思う。もちろん「助かった」で済む話ではないし、情報収集や persistence は通っているので油断はできない。でも、こういう実害の大きい攻撃でも、実装ミスで全部は成功しないことがあるのは少し意外だった。逆に言うと、攻撃者は完璧なプロではなくても、配布経路さえ取れればかなりのところまで行けてしまう。 あと引っかかったのは、これが単なる malware ではなく、拡張機能の名前と配布場所を使った supply c

まず思ったのは、これが「コードの中身が悪かった」というより、「正規の配布経路そのものが汚された」話だということです。そこがいやに生々しい。開発者は拡張機能を入れるとき、ある程度は信頼しているはずで、しかも今回は auto-update が効いていた。つまり、ユーザーが何か変なファイルを自分で拾ったわけではなく、いつもの更新がそのまま侵入経路になっている。便利さと危うさが同じ場所にある感じがして、かなり嫌なニュースだと思いました。 それでも少し気になったのは、被害の説明が「最大5,000台」とかなり具体的なのに、肝心の侵入経路はまだ分かっていないことです。どこでアカウントが乗っ取られたのかが不明だと、似たような事故はまた起きる。しかも記事を読む限り、単にバックドアを入れたというより、SSH key を足して reverse SSH tunnel を張り、ホスト情報や環境変数の名前まで集めようとしていた。要するに、開発者のマシンを足がかりにして cloud credentials や API token を探る、かなり実務的な攻撃です。コードの雑なバグで一部は失敗したらしいですが、それで安

開発者向けの拡張機能は、便利なぶん一度入り込まれると厄介です。今回Phorionが報告したのは、Cursor Marketplaceに載っていた公式のClaude Code for VS Code拡張のバンドルにバックドアが仕込まれていた、という話でした。しかも影響はmacOSだけに限られず、LinuxやWindowsにもまたがります。単なる「悪い拡張があった」ではなく、IDEの権限でローカルファイルや開発環境にすぐ触れられる点が重い。だからこそ、今この件を整理しておく意味があります。 Phorionの説明によると、問題の拡張はCursor Marketplace上の「Claude Code for VS Code」拡張バンドルに含まれていました。対象として挙げられているのは Claude Code for VSCode 2.1.313 です。Cursorはこのリリースをマーケットプレイスから削除し、さらにNPMとVSCode版の2.1.313も各レジストリから引き下げたとされています。 仕組みはかなり露骨です。拡張の`extension.js`の先頭に、即時実行される関数が差し込まれ

この記事を読んでまず思ったのは、「拡張機能ひとつでここまで綺麗に侵入経路ができるのか」という怖さでした。しかも、ただの不審な野良配布ではなく、正規の Claude Code 拡張が Cursor Marketplace 上でやられている。ここがいちばん嫌なところです。利用者から見ると“信頼して入れるもの”なので、警戒の起点がそもそも薄い。 特に印象に残ったのは、攻撃の形がかなり実用的だという点です。単にファイルを書き換えるだけではなく、SSH key を置いて、外向きの tunnel を張って、さらに再起動後も戻ってくる。要するに「一度入ったら長く居座る」設計です。しかも IDE の権限で動くので、ソースコードやローカルファイルに即アクセスできる。開発者向けツールは便利さの裏で、そのまま攻撃面にもなるんだなと改めて思いました。 それと、記事が面白かったのは、macOS の `systemsetup -getremotelogin` の扱いで攻撃がつまずくかもしれない、という細かい実装上のズレまで見ているところです。攻撃コードって、派手な話に見えても、こういう「権限が足りずに想定どおり動

まず切り分けたいのは、このエラーが「セッションの再開に失敗している」話なのか、「再開先のセッションに deferred tool の印が残っていない」話なのかです。今回の症状クラスタでは、どちらも `claude --resume <id>` で同じエラーに見えます。 issue [#77313](https://github.com/anthropics/claude-code/issues/77313) では、バックグラウンドの deferred agents を使う `Task` tool と plan-mode approvals を組み合わせたセッションが、途中で中断されると `claude --resume <id>` が再接続できなくなり、その状態が恒久的に続くと報告されています。報告者は macOS の Apple Silicon 環境で再現し、`ssh` の素の対話シェルでも terminal multiplexer 経由でも同じ挙動だったと書いています。SSH 接続枯渇ではないことも確認済みでした。 一方、issue [#80954](https://github.

このエラーは、少なくとも報告上は 2 つのまったく違う場面で出ています。ひとつは SSH でリモートフォルダに入るとき、もうひとつは Claude Desktop の Code タブで Cowork VM を作るところです。どちらも最終的には同じ文言ですが、引き金は同一とは限りません。 まず自分のケースに近いかを切り分けると、[#64425](https://github.com/anthropics/claude-code/issues/64425) は「同じホストでもホスト名の書き方で成否が変わる」例でした。`root@frigate.ahfp` や `root@pve.ahfp` では失敗し、`frigate.ahfp.local` や `orangepi@wait-room-kiosk.ahfp` では成功しています。つまり、少なくともこの報告では “接続先そのもの” より “ホスト名の表記” に症状が結びついています。 一方で [#64867](https://github.com/anthropics/claude-code/issues/64867) は Windows

この記事を読んで最初に思ったのは、「LLMそのもののコストより、周辺の面倒さのほうが先に限界を作るんだな」ということだった。Claude Codeみたいなツールって、つい“賢いCLI”くらいの感覚で見てしまうけれど、実際にはローカルテストやlocalhostサーバー、ファイルのやりとりまで含めると、意外なくらいPCを使う。10個、20個と並列に走らせるなら、もうノートPCの気合いではどうにもならない、という感覚はかなり腑に落ちた。 面白かったのは、そこで高価なマシンを買う話に飛ばず、CPUを借りるという発想に寄せていたことだ。GPUが要るのはモデル側であって、エージェントを動かすだけならCPUで足りる、という切り分けは実用的だと思う。しかも「買うより借りるほうが安い」というだけでなく、24時間動かしっぱなしにできるのが大きい。自分の手元のMacを閉じたら止まる、熱でつらい、というあたりはかなり生々しい。クラウドの話というより、日常のPC運用の限界の話として読めた。 一方で、Remote Server + SSH で全部うまくいく、というほど単純でもない。ローカルの画像をどう渡すか、re

まず自分のケースかどうかを切り分けます。今回の issue 群では、どちらも Claude Code から SSH を投げたときに `exit code 255` で失敗しています。ただし、同じ 255 でも中身は違います。 ```text Error: Exit code 255 Connection timed out during banner exchange Connection to UNKNOWN port 65535 timed out ``` 一方、[#77678](https://github.com/anthropics/claude-code/issues/77678) では、背景が違います。issue の要約では、Claude Code の Bash tool で SSH を呼ぶと `No user exists for uid 501` が出て、standalone の `claude` CLI では同じコマンドが動くと報告されています。つまり、同じ SSH 失敗でも、こちらはネットワーク到達性というより実行環境側の問題に見えます。 `#68497` のほう

Claude Code で `Permission denied` が出る話は、今回の issue 群だと 2 つの顔があります。ひとつは SSH 越しのセッションが再起動後におかしくなるケース、もうひとつは MCP 経由でページ操作が拒否されるケースです。どちらも同じ文言に見えますが、症状の出方はかなり違います。 SSH 側は [#72335](https://github.com/anthropics/claude-code/issues/72335) です。報告では、デスクトップアプリで SSH セッションを使っていると、再起動後に過去のセッション履歴が空白になったり、SSH セッションの fork/branch が失敗したりします。報告されている根本原因は、過去セッションを開くときにデスクトップアプリが 2 つの SSH 処理を走らせ、そのうち byte-sync は SSH config のエイリアスを使う一方、tail 側が raw IP に接続してしまう、というものです。こちらは issue 本文が途中で切れているため、tail 側の接続先の詳細は分かりません。少なくとも