SSH AI Chat：一行 ssh 指令聊 AI，鑰匙掛在 GitHub 帳號

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

在終端機敲下 ssh 你的GitHub帳號@chat.agi.li，畫面會先跳出一句歡迎詞 Welcome to the SSH AI Chat server!，還沒在 GitHub 帳號上綁過 SSH 金鑰的人，接著就會收到 Permission denied (publickey)，被擋在門外。SSH AI Chat 這套開源專案把 AI 聊天室做成一台 SSH 伺服器：不用安裝 App、不用開瀏覽器，macOS、Linux 與較新的 Windows 內建的 ssh 指令就是它的客戶端。實際連線測試裡被擋下的那一刻，正好是理解這個工具的起點。它的帳號系統整個外包給 GitHub，進門的鑰匙不在這個網站上，門後的對話資料也由站方經手。鑰匙在哪、資料去了哪、自己架一份要多少工，接下來一次講清楚。

先定位一下產品。SSH AI Chat 是 2025 年 6 月出現在 GitHub 上的開源專案，以 AGPL-3.0 授權釋出，主要語言是 TypeScript，寫到 2026 年 9 月累積約 926 顆星。伺服器端用 Node.js 搭 ssh2 函式庫處理連線，聊天畫面用 React 加 Ink 直接畫在終端機裡，對話資料進 PostgreSQL，沒接外部資料庫時會退回 PGLite，把資料寫進掛載出來的本機目錄。整個服務打包成一個 Docker 映像檔，安裝這件事則被推給絕大多數電腦都內建的 ssh 指令。

被擋在門外才知道：帳號系統借自 GitHub

這個服務不接受密碼登入。實際連線時就算在客戶端指定優先用密碼認證，伺服器照樣只回公鑰認證一個選項。從原始碼 src/auth/index.ts 可以看到完整機制：伺服器收到連線請求後，去抓 github.com/帳號名稱.keys 這個網址，把對方 GitHub 帳號上登記的 SSH 公鑰下載下來，與連線者出示的金鑰比對，數位簽章吻合才放行，結果快取六小時。沒有金鑰可用時，伺服器回的拒絕訊息很直接，內容就是叫你把一組 SSH 金鑰加進 GitHub 帳號，還附上官方說明短連結。

對讀者的意義可以一句話講完：你的 GitHub 帳號就是你的帳號。開發者多半早就綁好了金鑰，對這群人來說進門成本接近零。還沒綁過的人得先做一段前置作業，產生金鑰、加上 GitHub、再回來連線，流程不難，但「免註冊」三個字在這裡有但書，註冊這件事其實被移轉到 GitHub 身上。

這套把 GitHub 當身分提供者的做法，效果類似「用 Google 帳號登入」，差別在於連 OAuth 授權流程都省了，直接拿 SSH 金鑰的簽章當憑證。GitHub 自己也走同一條路：你用 [email protected] 拉程式碼時，驗的就是同一份公鑰清單。SSH AI Chat 等於借用了一條已經鋪好的軌道，順便把「幫使用者保管帳號密碼」這件容易出事的工作整個丟掉。

登入失敗也有節流設計。官方範例設定是十分鐘內失敗十次就會被暫時擋下，程式內建的預設上限其實是六十次；設定範例也對每小時的請求另設上限，範例值是三百次。自架的人可以照自己的使用者規模調整。

用公鑰代替密碼，安全面上有實質好處。SSH 公鑰認證的性質是私鑰從頭到尾不離開你的電腦，伺服器只拿到公鑰與一次性的簽章，沒有密碼可以外洩，也沒有「在陌生網站輸入過密碼」這種風險。反面也值得想：這套機制不會驗證伺服器是誰。任何陌生人都能照 README 架一台一樣的服務，你連過去的瞬間，GitHub 使用者名稱與 IP 位址就交到了對方手上，因為對任何一台這樣的伺服器來說，你的金鑰都能通過驗證。身分機制同時是隱私暴露點，連線前先認清楚自己連的是誰的站台。

進門之後：三欄式聊天畫面與 14 個模型

通過認證後，終端機會變成一個文字介面聊天室。從官方 README 收錄的截圖看，畫面分成三欄：左欄選模型，中欄是對話區與輸入框，右欄是歷史記錄，支援用數字鍵快速換模型、用快捷鍵開新對話或切換介面語言，介面語言截圖裡看得到簡體中文與英文兩種。

Pin

畫面細節看得出這是為鍵盤操作設計的介面。照官方說明與截圖，進場會先看到一段 ASCII 藝術字的專案標題，按 ESC 進入閒置模式後，n 開新對話、i 進輸入模式、數字鍵直接跳選模型，介面另備語言切換與說明頁，離開用 Ctrl+C。頁尾放著專案的 GitHub 與贊助連結，歷史記錄欄會出現一條系統自動建立的初始對話。沒有滑鼠點按的空間，所有操作回到按鍵層，這對熟終端機的人是加分，對習慣圖形介面的人就是門檻。

Pin

模型清單值得單獨看。截圖顯示當時的選單有 14 個選項，涵蓋 DeepSeek-V3 與 R1、Gemini-2.5-Flash 與 Pro、Grok-3-mini、Mistral 兩款、Claude-Sonnet-4、Claude-Opus-4、GPT-4.1 系列、OpenAI o3-mini 與 o4-mini、Qwen3-8B。要留意這是 README 收錄當下的樣子，截圖沒標日期，公共實例今天的實際清單要登入才看得到。對照原始碼會發現模型完全由站方在環境變數裡配置，走 OpenAI 相容格式，也就是說清單內容隨時可換，沒有任何對外承諾。有支援思考鏈的模型另外標記，讓推理過程攤在畫面上，這對想看模型怎麼想的讀者是有感的功能。

比較少被提到的是它內建了 MCP 工具鏈。從 src/ai/mcp.ts 看，伺服器預設連上兩個 MCP 端點：一個是 Exa，提供網頁搜尋、程式碼檢索與網頁爬取；另一個是 DeepWiki。模型可以邊聊邊呼叫這些工具查資料，讓它離單純聊天室更遠一步，接近住在終端機裡的助理。對 MCP 生態有興趣的讀者，可以參考先前介紹過的 12306-MCP-Server：把火車票查詢做成 MCP 工具，同樣是把外部資料源接進模型對話的思路。

你的對話去了哪：三個流向

用公共實例之前，值得把資料流向想清楚。從原始碼逐層看，至少有三個去處。

對話本身存在伺服器端。資料表結構裡，使用者資料表只記 GitHub 使用者名稱與公鑰，對話資料表則把每段對話的標題與完整訊息內容存成資料庫記錄，站方看得到你聊了什麼。對話標題還是由一個系統模型自動下的，設定範例用 Qwen3-8B。

連線行為會進分析服務。追蹤模組把事件送進 Umami，欄位包含 IP 位址、終端機視窗尺寸、事件路徑，GitHub 使用者名稱則被編進來源欄位一起送出，設定範例預填了一組現成的 Umami 站點。伺服器端的日誌也記下每一次連線的 IP、使用者名稱與認證方式，這在原始碼裡是預設行為。就算對話內容不敏感，連線這個行為本身也被記錄。

內容會流經模型端點與工具服務。模型端點由站方配置，前面提到的 Exa 與 DeepWiki 也是站方指定，你的提問與模型回應都會經過這些第三方服務。公共實例的模型由誰付費、API 金鑰怎麼來，從外部完全看不出來，這一點也沒有官方揭露可查。

把三個流向攤開後，這個專案的定位其實很清楚：公共實例是設計示範，自架才是本體。它對隱私的處理沒有藏，但也沒有替你把關，敏感內容本來就不該貼進別人的聊天室。

自己架一份要多少工

部署面真的不重。一個 Docker 容器就是全部，映像檔放在 ghcr.io，接上連接埠就能跑。門檻在 .env：AI_MODELS 是必填，沒設的話程式一啟動就直接結束；每個模型要給型號、端點網址與 API 金鑰，格式走 OpenAI 相容。官方範例配的是 DeepSeek-V3、DeepSeek-R1、Gemini-2.5-Flash 與 2.5-Pro。換句話說模型選擇權完全在你手上，接自家代理、接任何相容服務都行，想要先試端點連通性，可以搭配 LLM API 測試工具 先驗一把再寫進設定。

基礎設施也能再省。沒有外接 PostgreSQL 與 Redis 也跑得動，資料落在 data 目錄對應的本機檔案，只是重新啟動後快取類資料會掉；README 的部署範例把記憶體上限設在 4GB，repo 內附的 compose 檔目前是 1GB，連接埠則對應到標準的 22。要不要開放成公開伺服器是環境變數裡的開關，預設關閉，關著的時候站台走白名單制，只有列名的 GitHub 帳號進得來，限流數值與黑名單同樣是設定檔層級的決定。這組預設對內部使用相當友善：先關起門給團隊用，要對外開放再打開開關並補上限流。README 的部署段落建議用特定主機商並附了推薦連結，那屬於作者的聯盟行銷，挑機器時自己比價就好。

授權要單獨記一筆。AGPL-3.0 對自己用、公司內部用都沒有額外義務；如果改了程式碼又對外提供服務，這個授權要求你對網路使用者提供對應原始碼。想拿它做二次開發或包成對外服務的人，這條要先看懂。

轉手、停更，還有兩個都活著的網域

時間軸先攤開。專案 2025 年 6 月建立，同年 12 月 7 日從原作者 ccbikai 的帳號轉移到現在的維護者 miantiao-me 手上，十三天後的 12 月 20 日是最後一次程式碼更新，到 2026 年 9 月已經約八個半月沒有新 commit。專案沒有打包過正式 release，Docker 映像檔直接從程式碼庫產出。四個開放 issue 裡，一則是 2026 年 5 月更新的連線問題回報，另外三則是 2025 年 6 月留下的終端機相容性建議、Vim 式導航與快捷鍵功能請求，都還沒有被處理。維護節奏偏慢是觀察得到的事實，自架的人要有自己顧的心理準備，遇到問題先看 issue 與程式碼，等官方修的期望要放低。

網址也有個小坑。專案首頁現在寫的網域是 chat.agi.li，官方 README 的截圖裡還看得到舊網域 chat.aigc.ing，實際測試兩個網域到 2026 年 9 月都還活著，回應同樣的歡迎訊息與版本識別字串 SSH-2.0-SSH AI Chat/0.1.0，跑的是同一套軟體。看到不同教學寫不同網址時，先別急著判斷哪篇過期。

終端機相容性要對齊期待。README 宣稱在 macOS 的 iTerm2 與 Ghostty 上驗證過，Linux 與 Windows 標註為等待回饋，Windows 使用者要有遇到畫面顯示異常的心理準備，這部分目前只有官方說法，還沒有第三方驗證。

公共實例拿來即用，自架換資料主導權

長時間待在終端機裡的開發者是公共實例的天然使用者。本來就有 GitHub 帳號與金鑰，連線成本接近零，把它當成順手的查詢視窗很合理，只要記得別貼敏感內容。若你已經在手機上遠端控制過 AI 代理，像先前介紹過的 Port22：用手機遠端操控 Mac 上的 AI 代理，SSH AI Chat 提供的是另一個方向：不控制代理，只把聊天視窗放進多數機器都有的終端機裡。

對隱私要求高、想指定模型、或要讓資料落地在自己基礎設施的人，自架才是正解。一個容器加一份 .env，換到的是對話資料與模型端點的主導權；不過 MCP 工具端點（Exa、DeepWiki）是寫死在程式裡的，追蹤設定範例也預填了現成的 Umami 站點，講究隱私的人自架後要再清一輪設定。帶團隊或課堂集體使用的情境，自架加白名單，比逐一發帳號密碼省事，成員只要有 GitHub 帳號就能進場。想要網頁版多人聊天體驗的讀者，ParallelChat 這類多模型網頁聊天工具 是另一條路線，兩者可以按使用場景分工。

SSH AI Chat 值得帶走的一點，也許不是 AI 聊天本身，而是它示範了 SSH 這個老協定的另一種用法：當多數機器都內建客戶端，散布軟體的成本可以低到一行指令。至於要不要把鑰匙交給 GitHub、把對話交給站方，那就是每個使用者自己的取捨了。