درون معماری Gemini CLI؛ کنترل دستورات سرور از طریق لایه MCP

تصور کنید همکاری دارید که می‌تواند تمام خرابی‌های سرور شما را رفع کند، اما هرگز اجازه ندارد کلیدهای ورودی ساختمان را لمس کند. این دقیقاً همان امنیتی است که اکنون در مدیریت زیرساخت‌های ابری با هوش مصنوعی محقق شده است.

دادن دسترسی مستقیم به یک عامل (Agent) — شبیه دستیاری که می‌تواند به جای شما کارهای پیچیده را انجام دهد — به سرورهای عملیاتی، معمولاً به معنای تحویل یک کلید SSH باز است؛ کابوسی امنیتی که به طور پیش‌فرض دسترسی کامل به سیستم را فراهم می‌کند. اگر کلیدی در مسیر ~/.ssh یا یک ssh-agent فعال باشد، ابزار خط فرمان می‌تواند دستور ssh prod را اجرا کند، چه شما قصد داده باشید و چه نه. گوگل در Gemini CLI این مشکل را با بهره‌گیری از پروتکل زمینهٔ مدل (Model Context Protocol یا MCP) حل کرده است تا مدل به جای نگهدارنده کلید، در نقش یک درخواست‌کننده عمل کند.

این تغییر در حالی رخ می‌دهد که توسعه‌دهندگان از رابط‌های سادهٔ چت به سمت عامل‌های خودمختاری می‌روند که باید سرویس‌ها را ری‌استارت کنند، لاگ‌ها را دنبال کنند یا استقرارها (Deploy) را روی سرورهای زنده اجرا نمایند. همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، جداسازی دسترسی از اعتبارنامه‌ها تنها راه کاهش ریسک در مقیاس است. این رویکرد مشابه راهکاری است که ProxyKey برای مدیریت امن APIها به کار گرفت تا دسترسی عامل‌ها بدون افشای کلیدها میسر شود. در حالی که پیش‌تر پوشش ما بر تلاش‌های گوگل در زمینه اصالت رسانه‌ها با SynthID متمرکز بود، اکنون تمرکز بر امنیت عملیاتی در گردش‌کار توسعه‌دهندگان است. این رویکرد اجازه می‌دهد توسعه‌دهنده بدون نگرانی از افشای کلیدهای حساس، قدرت اتوماسیون هوش مصنوعی را در محیط‌های حساس به کار بگیرد.

به نقل از گزارشی در dev.to که در ۷ اکتبر ۲۰۲۶ منتشر شد، این یکپارچگی بر پایه Termalin است؛ یک کلاینت SSH که به عنوان یک سرور MCP عمل می‌کند. به جای اینکه Gemini CLI مستقیماً دستور ssh prod را اجرا کند، با Termalin ارتباط می‌گیرد و این برنامه در نقش یک متولی امن عمل می‌کند. راه‌اندازی این ساختار برای هر میزبان حدود ۲۰ دقیقه زمان می‌برد. این مدل پیاده‌سازی در حالی توسعه می‌یابد که چالش‌های تبدیل سرورهای MCP به ابزارهای تجاری همچنان یکی از مباحث داغ در میان توسعه‌دهندگان است.

پیش‌نیازها و زمینه

برای اجرای این گردش‌کار، شما به اپلیکیشن دسکتاپ Termalin (نسخه رایگان کافی است) و نصب Gemini CLI روی همان ماشین نیاز دارید. توصیه می‌شود برای اولین اجرا، از یک میزبان کم‌ریسک شروع کنید تا با نحوه تعامل عامل با سیستم آشنا شوید.

اگر نمی‌خواهید از MCP استفاده کنید، Termalin گزینه ساده‌تری دارد: یک تب ترمینال محلی که می‌توانید Gemini CLI را مستقیماً داخل اپلیکیشن و در کنار جلسات SSH خود اجرا کنید. با این حال، تنها در حالت MCP است که Gemini از طریق متولی عمل می‌کند تا کلیدها دور از دسترس باقی بمانند و هرگز به محیط اجرای مدل نفوذ نکنند.

سازوکار امنیتی

• متولی کلیدها: احراز هویت در محیط اپلیکیشن Termalin باقی می‌ماند. شما یک بار قفل را باز می‌کنید و Termalin از طرف عامل امضا می‌کند. عامل هرگز فایل کلید را نمی‌بیند، نمی‌خواند یا نگه نمی‌دارد و بدین ترتیب درِ پشتی ~/.ssh کاملاً بسته می‌شود.
• فهرست میزبان‌ها: دسترسی عامل به طور پیش‌فرض غیرفعال است. در بخش Settings $ \rightarrow $ MCP باید آن را فعال کرده و میزبان‌های خاصی را تیک بزنید. Termalin فهرستی از میزبان‌ها را می‌نویسد که شامل ورودی‌های احراز هویت مخصوص عامل است؛ برای عامل، هیچ سروری خارج از این لیست وجود خارجی ندارد.
• سیاست‌های دسترسی: کاربران برای هر میزبان یک سیاست تعیین می‌کنند: دسترسی کامل (Full access)، لیست سفید از دستورات مجاز (Allowlist)، یا مسدود (Blocked). برای سیستم‌های حساس، استفاده از یک ساختار «حداقل امتیاز» (Least-privilege) با استفاده از لیست سفید توصیه می‌شود.

جزئیات پیاده‌سازی

مرحله اول شامل فعال‌سازی دسترسی عامل و تعیین سیاست در Termalin است. مرحله دوم، ثبت سرور در تنظیمات Gemini است. Gemini CLI سرورهای MCP را از شیء mcpServers در فایل ~/.gemini/settings.json (برای همه پروژه‌ها) یا فایل محلی پروژه در مسیر .gemini/settings.json می‌خواند.

برای اتصال، ورودی زیر را که به باینری bundled اشاره می‌کند، به تنظیمات اضافه کنید:

{ "mcpServers": { "termalin": { "command": "<path>/termalin-mcp" } } }

پس از بازراه‌اندازی CLI یا بارگذاری مجدد سرورهای MCP، عامل مجموعه‌ای از ابزارها را به دست می‌آورد. با اجرای دستور /mcp در Gemini می‌توانید اتصال و ابزارهای در دسترس را مشاهده کنید که شامل موارد زیر است:

• hosts_list برای مشاهده لیست میزبان‌ها و ssh_exec برای اجرای دستورات
• session_open و session_exec برای ایجاد و مدیریت جلسات پایدار
• قابلیت‌های خواندن و نوشتن از طریق SFTP
• هدایت پورت‌ها (Port forwards)

کاربرد در دنیای واقعی

به جای دموهای ساده، می‌توانید یک کار واقعی به عامل بسپارید: «استقرار در staging-1 تمام شد اما بررسی سلامت (Health check) مدام قطع و وصل می‌شود. دلیلش را پیدا کن و رفعش کن.» Gemini ابتدا hosts_list را فراخوانی می‌کند، staging-1 را شناسایی کرده، یک جلسه باز می‌کند و وضعیت سرویس، ۱۰۰ خط آخر لاگ و تفاوت‌های پیکربندی (Config diff) را استخراج می‌کند. سپس بر اساس سیاست‌های شما، یک اصلاحیه پیشنهاد داده و آن را اعمال می‌کند.

این فرآیند به دلیل شفافیت، حس امنیت می‌دهد. با فعال کردن گزینه "Agent in Terminal" در تنظیمات، Gemini در تب‌های ترمینال خود اپلیکیشن کار می‌کند (از طریق terminal_open و terminal_run). این تب‌ها با علامت عامل مشخص شده‌اند و در شبکه نظارتی (Watch grid)، تمام جلسات باز در کنار کاشی‌های درخشان عامل نمایش داده می‌شوند. لازم به ذکر است فراخوانی‌های بدون رابط گرافیکی (Headless) مانند ssh_exec و session_* مستقیماً از سرور MCP اجرا می‌شوند بدون اینکه تب جدیدی باز کنند.

یکپارچگی با ابر و CI/CD

در محیط‌هایی که دسکتاپ محلی در دسترس نیست — مانند کارهای CI یا محیط‌های Sandbox ابری — باینری محلی قابل دسترسی نیست. در این موارد، نسخه Termalin Pro (یا دوره آزمایشی ۱۴ روزه) یک نقطه اتصال (Endpoint) میزبانی‌شده در آدرس https://termal.in/api/v1/mcp ارائه می‌دهد.

برای استفاده از این قابلیت، یک کلید API در پنل وب می‌سازید، آن را به سرورهای خاصی محدود می‌کنید، سطح دسترسی (فقط خواندنی یا لیست سفید) و تاریخ انقضا تعیین می‌کنید. سپس عامل بدون نیاز به کلید، به سرورهای ثبت‌شده در Connector متصل شده و هر اجرا را با یک گواهینامه کوتاه‌مدت (Short-lived certificate) احراز می‌کند.

مرزهای عملیاتی

بر اساس مستندات، کلیدهای شما هرگز وارد محیط Gemini نمی‌شوند. لغو دسترسی تنها با یک کلیک در تنظیمات انجام می‌شود و نیازی به چرخش کلیدها (Key rotation) در کل شبکه نیست. اگرچه دسترسی Full در محیط عملیاتی ممکن است، اما این حالت یک شل (Shell) کامل فراهم می‌کند و باید با دقت و آگاهی کامل فعال شود.

علاوه بر این، Gemini به طور پیش‌فرض جلسات خود را باز می‌کند؛ پیوستن به یک جلسه موجود نیازمند تایید جداگانه است. همچنین کارهای عامل در تب‌های ترمینال برای اهداف حسابرسی (Auditing) قابل ضبط هستند؛ البته تنها خروجی‌ها ضبط می‌شوند و هرگز ضربات روی کیبورد (Keystrokes) ثبت نمی‌گردند.

این معماری پروفایل ریسک DevOps مبتنی بر هوش مصنوعی را تغییر می‌دهد. با جداسازی «اجازه اجرای دستور» از «اعتبارنامه‌ی دسترسی به سرور»، شعاع تخریب (Blast radius) یک عامل دچار توهم (Hallucination) — یعنی وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد — به سیاست‌های پیش‌تعیین‌شده کاربر محدود می‌شود. این استراتژی مدیریت دسترسی، مشابه رویکردی است که گوگل در مدیریت امن دستگاه‌های هوشمند Google Home برای کنترل شخص ثالث به کار گرفته است.

هفته اول استفاده از این سیستم را مانند پذیرش یک همکار سریع اما تازه‌وارد مدیریت کنید: شبکه نظارتی (Watch grid) را باز نگه دارید و به Gemini کارهایی با وضعیت «پایان» (Done-state) مشخص بدهید. این معامله ارزشش را دارد: Gemini دسترسی واقعی به سرورهای شما پیدا می‌کند و شما تنها چیزی را که پس از خروج هرگز باز نمی‌گردد — یعنی کلیدها — در اختیار خود نگه می‌دارید.

گام بعدی شما

• اگر از Gemini CLI استفاده می‌کنید، ابتدا Termalin را نصب کرده و روی یک سرور تست (Staging) با سیاست «لیست سفید» آن را آزمایش کنید.
• در تنظیمات MCP، دسترسی‌ها را به صورت حداقلی (Least-privilege) تعریف کنید تا ریسک اجرای دستورات ناخواسته به صفر برسد.
• برای محیط‌های CI/CD، از Endpointهای میزبانی‌شده برای حذف کامل کلیدهای SSH از متغیرهای محیطی (Env vars) استفاده کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.