ChatGPT Desktop bị tố forward SSH agent sang máy remote, key của anh em có bị lấy mất không

Chiều 09/11/2026 giờ VN, tức 08:17 UTC, một bài đăng ngắn trên Hacker News tố ChatGPT Desktop forward SSH agent sang máy remote. Điểm số leo từ 72 lên 185 trong một ngày. Quyền dùng key từ máy remote có thể đã mở ra, và đó mới là chỗ cần khóa lại ngay.

• Key SSH không rời khỏi máy local, thứ bị mở ra là quyền dùng key để ký xác thực từ máy remote.
• PR #28131 đã đóng mà không merge, và hành vi mặc định của app tháng 11/2026 chưa ai kiểm chứng thực nghiệm.
• Khóa nhanh nhất là ForwardAgent no cho Host * trong ~/.ssh/config.

Ngày 9 tháng 11, một bài đăng Hacker News tố ChatGPT Desktop forward SSH agent sang máy remote

Tiêu đề này lan nhanh, hình như vì nó chạm đúng nỗi sợ của mọi người dùng ChatGPT Desktop với máy remote.

DenGorbachev đăng 3 câu lúc 08 giờ 17 UTC, điểm số leo từ 72 lên 185 trong một ngày

Mình đọc lại bài đăng 50422628 của DenGorbachev, chỉ có ba câu: agent trên remote có thể xác thực bằng SSH credentials local, ví dụ push lên repo private GitHub. Bằng chứng duy nhất là link discussion r3410013180 trong PR #28131.

Tuần 03-09/11, Apiiro báo cáo Claude Code để mặc định “Don’t Ask Again” làm rò rỉ key qua các repo. Check Point công bố bypass ChatGPT Lockdown Mode ngày 05/11, OpenAI nói đã sửa từ 18/09. Cơ mà, mình đối chiếu thread thì không có người OpenAI nào xuất hiện, bài đăng không có ảnh chụp, log hay bước tái hiện nào. Tối khoảng 18:30 UTC ngày 09/11, thread có 20 bình luận cấp 1, 60 bình luận tổng cộng.

PR openai/codex #28131 mở giữa tháng 6 và đóng ngày 29 tháng 6 vì stale bot 14 ngày

Mình đọc lại PR “[codex] Refresh SSH agent for app-server proxy” của abhinav-oai: mở ngày 13 tới 14/06/2026, ghi “Fixes #22567”, đóng ngày 29/06/2026 bởi github-actions vì không có cập nhật hơn 14 ngày, không merge, kèm lời mời mở lại hoặc mở PR mới. Không có tranh luận bảo mật nào trong PR. Codex sáp nhập vào ChatGPT Desktop từ tháng 07/2026.

Tài liệu Remote connections của OpenAI im lặng hoàn toàn về agent forwarding

Mình đọc docs Remote connections thì thấy app chỉ đọc alias host cụ thể từ ~/.ssh/config, resolve bằng OpenSSH. Host nào chỉ có pattern thì app bỏ qua. Config mẫu gồm Host devbox, HostName devbox.example.com, User you, IdentityFile ~/.ssh/id_ed25519, không có dòng ForwardAgent nào.

Docs cũng dặn giữ remote host như SSH bình thường, dùng tài khoản least-privilege và VPN/mesh thay vì expose transport ra mạng chung, cơ mà docs không nhắc tới agent forwarding ở đâu.

PR #28131 từng đề xuất nút opt-in forward SSH agent rồi bị đóng mà không merge

Bằng chứng duy nhất bài đăng dẫn ra nằm ở PR tháng 6, mình phải mổ đúng PR này trước khi bàn tiếp đấy.

Nút opt-in –forward-ssh-agent làm mới symlink forwarded-ssh-agent.sock cạnh control socket

PR thêm opt-in codex app-server proxy --forward-ssh-agent: proxy kiểm tra socket agent thừa hưởng, rồi làm mới nguyên tử symlink forwarded-ssh-agent.sock đặt cạnh control socket. Không có agent dùng được thì để nguyên link cũ.

Vấn đề này có thật từ lâu, tạm lấy tmux làm ví dụ: tiến trình chạy lâu cache SSH_AUTH_SOCK từ lúc khởi động, sau reconnect đường dẫn đó không còn tồn tại nên agent gãy theo.

Câu trả lời của abhinav-oai về SSH_AUTH_SOCK khi app-server khởi động

Review tự động của chatgpt-codex-connector ngày 14/06/2026 chỉ ra refresh không được quan sát trong đường daemon tích hợp, vì command_env không đặt SSH_AUTH_SOCK. Mình đọc câu trả lời của abhinav-oai thì thấy app Codex sẽ khởi động app-server với SSH_AUTH_SOCK trỏ tới symlink ổn định ~/.codex/app-server-control/forwarded-ssh-agent.sock. Lệnh đi kèm là SSH_AUTH_SOCK=~/.codex/app-server-control/forwarded-ssh-agent.sock nohup codex app-server --listen unix://.

Từ PR opt-in tháng 6 không suy ra được app tháng 11 forward mặc định

Mình đếm được ba bước nhảy logic chưa chứng minh. Bước một, từ PR opt-in tháng 6 sang app hiện tại đang forward agent. Bước hai, từ app-server khởi động với SSH_AUTH_SOCK trỏ tới socket đã forward sang app tự bật ForwardAgent cho mọi SSH host. Bước ba, từ agent xác thực được bằng credential local sang key bị lấy mất.

PR không merge cũng không chứng minh app không forward, cơ chế có thể đã vào code bằng đường khác, tới giờ chưa ai kiểm chứng được hành vi mặc định. Mọi người tự kiểm tra trên remote bằng echo $SSH_AUTH_SOCK và ssh-add -l, rồi thử ssh -T [email protected] từ remote, vì chưa ai làm thực nghiệm này.

Ai ngồi trên máy remote cũng đóng dấu được bằng key của mình

Rủi ro thật nằm ở quyền dùng key từ máy remote, con dấu đã đặt lên bàn máy đó rồi đấy.

SSH agent chỉ ký ở máy local, sshd trên máy remote tạo socket và đặt SSH_AUTH_SOCK

Đối chiếu docs thì ssh-agent giữ private key trong bộ nhớ máy local, không ghi ra đĩa, không cho export, key chỉ dùng để ký message xác thực.

Bật forwarding bằng ssh -A hoặc ForwardAgent yes thì SSH mở thêm channel nền, chuyển tiếp yêu cầu agent về máy local. sshd trên remote tạo một Unix socket và đặt SSH_AUTH_SOCK trỏ tới đó. Forwarding chỉ chạy với URL SSH, không chạy với HTTPS. Phía server mặc định cho phép, vì AllowAgentForwarding mặc định là yes.

Root trên máy remote dùng được mọi identity đang load trong agent suốt phiên còn sống

Man page OpenSSH cảnh báo một chuyện, kẻ vượt qua được quyền file trên remote thì truy cập được local agent qua kết nối đã forward. Điển hình là root, hoặc kẻ đã chiếm được máy. Hắn không lấy được key material, nhưng dùng được mọi identity đã load trong agent để xác thực thay mình, không chỉ key kết nối tới host đó.

Phía mình không có log hay thông báo nào khi key bị dùng qua socket đã forward. Không log, không báo động. VPS riêng chỉ mình mình có root thì rủi ro thấp hơn nhiều so với host chia sẻ hay máy người khác. viccis kể trên Hacker News, hồi làm pentest, agent forwarding là món quà từ thiên đường khi ngồi trên máy Linux.

App-server chạy detached có thể kéo dài cửa sổ rủi ro hơn một phiên ssh -A thông thường

Cửa sổ rủi ro thì dài bằng phiên SSH còn mở, tạm tính là vậy. App-server chạy lâu, detached, bám theo reconnect, nên cửa sổ này có thể kéo dài hơn một phiên SSH thông thường.

Git push lên repo private từ máy remote bằng identity của anh em là khả thi về mặt kỹ thuật

Agent trên remote có SSH_AUTH_SOCK trỏ tới agent đã forward thì git push lên repo private bằng identity mình là khả thi về mặt kỹ thuật. Đây là phần đúng trong claim của DenGorbachev.

Phe lo ngại đòi duyệt từng lần ký, phe phản biện nói forwarding là tính năng SSH chuẩn

Hai phe trong thread chia đôi rõ rệt, mọi người đọc kỹ sẽ thấy mỗi phe đều có điểm đúng.

arghwhat đòi duyệt từng lần ký, recsv-heredoc nói ma sát trong bảo mật là điều tốt

arghwhat trả lời recsv-heredoc: tự động forward agent sang máy lạ là cân bằng sai, ít nhất khi chưa thể lọc và duyệt từng yêu cầu ký riêng lẻ. recsv-heredoc nói trong bảo mật, ma sát là điều tốt.

Cơ mà ma sát quá mức cũng có giá của nó. siva7, hgoel và aleksskoz nhắc ma sát quá mức gây mệt mỏi xác nhận. Người dùng mệt rồi thì bấm đồng ý mù. NIST từng mất cả thập kỷ mới nhận ra bắt đổi mật khẩu liên tục làm tăng hành vi không an toàn. Giải pháp là xác nhận đúng chỗ, từng lần ký quan trọng, còn lại cho qua.

carterschonwald bênh forwarding là nền tảng của jump host rồi tự đồng ý chỉ khi người dùng tự chọn

carterschonwald nói đây là tính năng SSH bình thường, để dùng key mà vẫn giữ key ở local, là nền tảng của các setup hạ tầng an toàn như jump host, có điều nó dành cho người dùng hoặc script. Mình thừa nhận đây là phản biện mạnh nhất, đúng về mặt kỹ thuật.

Điểm yếu nằm ở đây: khi bị vặn “chỉ khi BẠN chọn nơi agent được truy cập”, carterschonwald đồng ý ngay, tức phe này thừa nhận cần lựa chọn có ý thức.

yfontana, mbreese và aweiher hỏi PR đóng không merge thì chứng minh được gì

Mình thấy yfontana hỏi thẳng, hình như cũng là câu nhiều người trong thread đang nghĩ, PR đã đóng, không merge thì chứng minh được gì. aweiher mỉa mai PR 5 tháng tuổi chưa từng merge chứng minh được gì ngoài việc 90% người trên Hacker News chỉ đọc tiêu đề. mbreese nói đây khó gọi là smoking gun, vì toàn bộ quy trình là opt-in, rồi hỏi có bằng chứng nào khác cho thấy Codex lạm dụng SSH agent không.

Tới 10/11/2026, chưa có bằng chứng nào như vậy. Câu chuyện nằm ở thiết kế mặc định và minh bạch, chưa có vụ lạm dụng nào được chứng minh.

iriririr vặn lại giao máy cho agent rồi sốc vì credential bị đọc

iriririr nói người dùng chạy một chương trình để eval lệnh nhận từ remote service, rồi sốc vì credential đọc được bị đọc. Phản biện này đúng về nguyên tắc phân tầng, vì giao máy cho agent thì agent đọc được thứ máy đó đọc được. Nhưng câu hỏi thật nằm ở chỗ khác, người dùng có được báo trước không, có lựa chọn không, và có thấy được khi nào key bị dùng hay không.

simoncion gợi ý tự vệ khác: đừng chạy agent bằng tài khoản daily-driver. causal nhắc nhiều người dùng bản desktop full-access trước, mãi sau mới phát hiện cloud sandbox miễn phí. viccis phản bác cloud của OpenAI tốn token gấp khoảng 3 lần, claim này chưa kiểm chứng.

Khóa forwarding trong 5 phút rồi mới tính tới deploy key và YubiKey

Phần mọi người làm được ngay trong ngày nằm ở đây, rẻ nhất và nhanh nhất trước.

Khóa ForwardAgent no cho Host * trong ~/.ssh/config, chỉ bật cho host tin cậy

Mình bắt đầu từ bước 5 phút: thêm vào cuối ~/.ssh/config khối Host trusted-server với HostName server.example.com và ForwardAgent yes, rồi khối Host * với ForwardAgent no. OpenSSH mặc định ForwardAgent no, GitHub Docs cảnh báo không dùng Host * với ForwardAgent yes, ssh -A chỉ bật cho một phiên duy nhất.

Giới hạn: cấu hình này chỉ chặn SSH client, nếu app tự bật forwarding độc lập với ~/.ssh/config thì nó có thể không chặn được app, và chuyện đó vẫn chưa kiểm chứng được.

Cấp deploy key chỉ đọc cho từng repo thay vì cho máy remote mượn agent

GitHub deploy key là SSH key cấp quyền cho một repository duy nhất. Phần public gắn vào repo thay vì tài khoản cá nhân, phần private nằm trên server, mặc định chỉ đọc, có thể bật ghi khi thêm key. Mỗi repo cần một key riêng. Với automation phức tạp hơn, GitHub App đáng cân nhắc, token ngắn hạn và giới hạn theo repo cùng quyền đã chọn.

Mình cân nhắc trade-off này kỹ: key ghi dài hạn trên server cố định có thể tệ hơn forwarding ngắn hạn có kiểm soát, nên quyết định dựa trên vai trò và tuổi thọ của host, phạm vi credential, và kế hoạch thu hồi.

Bitwarden hỏi xác nhận mỗi lần dùng key, Secretive và macOS Tahoe bắt Touch ID

SSH Agent của Bitwarden desktop lưu key trong vault mã hóa, bật tùy chọn “Ask for authorization when using SSH agent” thì mỗi lần dùng key hiện hộp thoại xác nhận. Anh em trỏ SSH_AUTH_SOCK tới socket Bitwarden để SSH client giao tiếp.

Trên macOS, bản .dmg dùng ~/.bitwarden-ssh-agent.sock, bản Mac App Store dùng ~/Library/Containers/com.bitwarden.desktop/Data/.bitwarden-sshagent.sock. Tính năng này dùng được mọi hệ điều hành.

Lưu ý thêm một chỗ, agent thử từng key trong vault, không chọn key theo từng host, workaround là IdentityFile trong SSH config. UndividedDev kể cài xác thực vân tay cho SSH key qua Secretive mới nhận ra các công cụ này thử làm đủ thứ mà không hỏi rõ. Hộp thoại phê duyệt không ngờ tới chính là chuông báo động, theo matthewcm.dev.

Secretive, app macOS mã nguồn mở của Max Goedjen, lưu key trong Secure Enclave nên key không export được, ở mức Require Authentication thì bắt Touch ID mỗi lần dùng key. Socket là ~/Library/Containers/com.maxgoedjen.Secretive.SecretAgent/Data/socket.ssh, cài bằng brew install --cask secretive.

Native macOS Tahoe 26 dùng sc_auth create-ctk-identity -l ssh-key -k p-256-ne -t bio rồi ssh-add -K -S /usr/lib/ssh-keychain.dylib, mỗi lần dùng hiện prompt Touch ID. Giới hạn: máy Mac hỏng thì identity mất theo, chỉ tạo được key p-256. causal cảnh báo: Touch ID và 1Password không ngăn agent bị forward, nên mình vẫn phải kiểm tra từng lệnh nếu không tin agent.

YubiKey chạm vật lý, ssh-add -c và ssh-add -t 3600, destination constraints từ OpenSSH 8.9

YubiKey với SSH U2F bắt mình chạm vật lý vào key mới ký và xác thực được, theo TacticalCoder trên Hacker News. Đây là kinh nghiệm cá nhân của TacticalCoder, chưa kiểm chứng độc lập, chỉ dùng làm ví dụ mitigation.

Ba lệnh có sẵn thì dùng ngay được. ssh-add -c bắt xác nhận mỗi lần dùng key. ssh-add -t 3600 giới hạn key còn sống 1 giờ. ssh-add -x khóa agent bằng mật khẩu, ssh-add -X mở khóa.

Destination constraints từ OpenSSH 8.9+ gắn ràng buộc đích cho key, cần cả client lẫn server remote hỗ trợ, nhưng không ngăn được kẻ có quyền truy cập SSH_AUTH_SOCK remote forward tiếp socket rồi dùng nó trên host khác (chỉ tới đích được phép). Vincent Bernat kết luận dù có ràng buộc vẫn nên tránh forwarding.

ProxyJump đi qua bastion mà không mở agent, và nó không thay deploy key khi push GitHub

ProxyJump với cờ -J, có từ OpenSSH 7.3 năm 2016, cho SSH client kết nối xuyên qua bastion tới host đích. Bastion chỉ chuyển tiếp lưu lượng TCP, không xác thực thay mình, agent không chạm tới bastion.

Ví dụ ssh -J bastion.example.com cloud.computer.internal, hoặc trong config dùng Host *.computer.internal với ProxyJump bastion.example.com. ProxyJump giải quyết bài toán đi qua bastion, không giải quyết bài toán agent trên remote cần push lên GitHub.

OpenAI cần công tắc duyệt từng lần ký, anh em cần khóa forwarding ngay hôm nay

Chuyện này chưa có bằng chứng app forward mặc định, nhưng thiết kế hiện tại đủ lý do để khóa lại trước, OpenAI nợ người dùng một công tắc rõ ràng hơn im lặng trong docs.

OpenAI nên cho duyệt từng lần ký theo đề xuất của arghwhat, nói rõ trong docs Remote connections về agent forwarding, và phản hồi chính thức về hành vi của app tháng 11/2026. Vụ bản Claude Code trên chợ extension của Cursor bị chèn cửa hậu SSH cho thấy rủi ro SSH không chỉ nằm ở forwarding.

Mọi người kiểm tra trên máy mình rồi chia sẻ trải nghiệm thật: SSH_AUTH_SOCK trên remote trỏ đi đâu, ssh-add -l liệt kê những identity nào, ssh -T [email protected] từ remote có qua được hay không, mọi người thử rồi kể lại nhỉ. Mọi thứ đúng tới 10/11/2026, nếu OpenAI lên tiếng thì bài này cần cập nhật.

Nguồn tham khảo

• Hacker News, bài đăng 50422628: https://news.ycombinator.com/item?id=50422628
• GitHub, PR openai/codex #28131: https://github.com/openai/codex/pull/28131
• OpenAI, tài liệu Remote connections: https://learn.chatgpt.com/docs/remote-connections
• dev.to jamilxt, SSH Agent Forwarding vs Dedicated Keys: https://dev.to/jamilxt/ssh-agent-forwarding-vs-dedicated-keys-a-safer-setup-for-remote-ai-coding-agents-1472
• GitHub Docs, Using SSH agent forwarding: https://docs.github.com/en/enterprise-cloud@latest/authentication/connecting-to-github-with-ssh/using-ssh-agent-forwarding
• Smallstep, SSH agent explained: https://smallstep.com/blog/ssh-agent-explained/
• Vincent Bernat, Safer SSH agent forwarding: https://vincent.bernat.ch/en/blog/2020-safer-ssh-agent-forwarding
• Safeguard.sh, Is SSH agent forwarding safe: https://safeguard.sh/resources/blog/is-ssh-agent-forwarding-safe-what-the-openssh-manual-warns
• Bitwarden, SSH agent: https://bitwarden.com/help/ssh-agent/
• PostHog Handbook, Security: https://posthog.com/handbook/engineering/security
• nmattia, Setting up SSH keys with Touch ID: https://nmattia.com/posts/2026-10-19-setting-up-ssh-keys-touch-id/
• AIWeekly, HN post flags ChatGPT Desktop forwarding SSH agent: https://aiweekly.co/alerts/hn-post-flags-chatgpt-desktop-forwarding-ssh-agent-to-codex
• Claude Reads HN: https://thevibeworks.github.io/claude-reads-hn/
• LWN, OpenSSH destination constraints: https://lwn.net/Articles/880458/
• dev.to mahafuz, SSH agent forwarding vs ProxyJump: https://dev.to/mahafuz/ssh-agent-forwarding-vs-proxyjump-why-agent-forwarding-is-dangerous-and-what-to-use-instead-1no6
• jmmv.dev, SSH agent forwarding and tmux: https://jmmv.dev/2023/11/ssh-agent-forwarding-and-tmux-done.html
• matthewcm.dev, Protecting SSH keys off disk in a password manager: https://www.matthewcm.dev/notes/protecting-ssh-keys-off-disk-in-a-password-manager/
• Algolia HN API, item 50422628: https://hn.algolia.com/api/v1/items/50422628