احراز هویت SSH با FIDO | ایمن‌سازی دسترسی سرور با کلیدهای امنیتی

پشتیبانی OpenSSH از کلیدهای FIDO

OpenSSH از نسخه ۸.۲ (منتشرشده در فوریه ۲۰۲۰) پشتیبانی رسمی از کلیدهای امنیتی FIDO را اضافه کرد. این پشتیبانی دو نوع کلید جدید را معرفی کرد که هر کدام ویژگی‌های خاصی دارند.

نوع کلید ed25519-sk

این نوع کلید بر پایه الگوریتم Ed25519 عمل می‌کند و پسوند «sk» مخفف Security Key است. Ed25519-sk از منحنی بیضوی Curve25519 استفاده می‌کند که امنیت بالا و عملکرد سریعی دارد. این نوع کلید گزینه پیشنهادی برای اکثر سناریوها محسوب می‌شود، زیرا هم امنیت رمزنگاری قوی‌تری ارائه می‌دهد و هم اندازه کلید و امضای کوچک‌تری دارد.

نوع کلید ecdsa-sk

این نوع کلید از الگوریتم ECDSA بر پایه منحنی NIST P-256 استفاده می‌کند. سازگاری وسیع‌تری با کلیدهای امنیتی قدیمی‌تر دارد، اما از نظر امنیتی محض، Ed25519-sk ترجیح داده می‌شود. برای سازمان‌هایی که از کلیدهای امنیتی نسل‌های قبلی FIDO استفاده می‌کنند، ecdsa-sk ممکن است تنها گزینه عملی باشد.

تفاوت کلیدهای discoverable و non-discoverable

یکی از مفاهیم مهم در کلیدهای FIDO SSH، تفاوت بین کلیدهای Resident (Discoverable) و Non-Resident (Non-Discoverable) است. کلیدهای Non-Resident (پیش‌فرض) به این صورت عمل می‌کنند که یک فایل کلید (Handle) روی سیستم کاربر ذخیره می‌شود و کلید امنیتی بدون این فایل قادر به تولید امضا نیست. کلیدهای Resident اما کاملاً درون حافظه کلید امنیتی ذخیره می‌شوند و کاربر می‌تواند بدون نیاز به فایل خارجی، از هر سیستمی به سرور متصل شود. کلیدهای Resident برای مدیرانی که از سیستم‌های مختلف به سرورها متصل می‌شوند بسیار کاربردی هستند، اما ظرفیت ذخیره‌سازی کلیدهای امنیتی محدود است و باید این محدودیت در نظر گرفته شود.

معماری احراز هویت SSH با FIDO چگونه کار می‌کند؟

درک معماری فنی احراز هویت SSH با FIDO برای پیاده‌سازی صحیح و عیب‌یابی ضروری است. این معماری شامل سه مرحله اصلی است: ثبت کلید، احراز هویت و تأیید حضور فیزیکی.

[تصویر ۲ در اینجا قرار می‌گیرد]

فرآیند ثبت کلید (Registration)

فرآیند ثبت کلید FIDO برای SSH با اجرای دستور ssh-keygen آغاز می‌شود. وقتی مدیر سیستم دستور تولید کلید را اجرا می‌کند، نرم‌افزار OpenSSH از طریق کتابخانه libfido2 با کلید امنیتی ارتباط برقرار می‌کند. کلید امنیتی یک جفت‌کلید رمزنگاری جدید تولید می‌کند: کلید خصوصی در عنصر امن (Secure Element) دستگاه ذخیره می‌شود و کلید عمومی به سیستم کاربر برگردانده می‌شود. در مورد کلیدهای Non-Resident، یک Key Handle رمزگذاری‌شده نیز ایجاد می‌شود که برای مراجعات بعدی به کلید خصوصی استفاده می‌شود. کاربر سپس کلید عمومی تولیدشده را در فایل authorized_keys سرور مقصد قرار می‌دهد.

فرآیند احراز هویت (Authentication)

هنگام اتصال SSH، یک فرآیند چالش-پاسخ (Challenge-Response) اجرا می‌شود. کلاینت SSH درخواست اتصال را به سرور ارسال می‌کند و سرور یک چالش رمزنگاری تصادفی تولید و ارسال می‌کند. کلاینت SSH این چالش را به کلید امنیتی FIDO ارسال می‌کند. کلید امنیتی از کاربر می‌خواهد حضور فیزیکی خود را تأیید کند (لمس دکمه یا اسکن بیومتریک). پس از تأیید، کلید امنیتی چالش را با کلید خصوصی امضا می‌کند و پاسخ امضاشده به سرور ارسال می‌شود. سرور با استفاده از کلید عمومی ذخیره‌شده، صحت امضا را تأیید می‌کند. اگر تأیید موفق باشد، دسترسی اعطا می‌شود.

تمام این مراحل در کسری از ثانیه انجام می‌شود و تجربه کاربری بسیار روانی ایجاد می‌کند. تنها تفاوت محسوس با کلیدهای SSH سنتی، لحظه‌ای است که کاربر باید دکمه کلید امنیتی را لمس کند.

نقش تأیید حضور فیزیکی کاربر (User Presence)

تأیید حضور فیزیکی (User Presence Verification) مهم‌ترین مزیت امنیتی FIDO SSH نسبت به کلیدهای سنتی است. حتی اگر مهاجم کنترل کامل سیستم کاربر را در دست داشته باشد، بدون دسترسی فیزیکی به کلید امنیتی و لمس آن، قادر به احراز هویت نخواهد بود. این ویژگی حملات Remote را به‌شدت محدود می‌کند.

OpenSSH دو سطح تأیید حضور را پشتیبانی می‌کند. سطح اول User Presence (UP) است که فقط نیاز به لمس فیزیکی دکمه کلید دارد. سطح دوم User Verification (UV) است که علاوه بر لمس، نیاز به تأیید بیومتریک (مانند اثر انگشت) یا ورود PIN دارد. سطح دوم امنیت بیشتری ارائه می‌دهد و برای محیط‌های با حساسیت بالا توصیه می‌شود. با فعال‌سازی verify-required، حتی اگر کسی کلید امنیتی فیزیکی را سرقت کند، بدون اثر انگشت صاحب آن یا PIN، قادر به استفاده از آن نخواهد بود.

پیش‌نیازهای ایمن‌سازی SSH با کلیدهای FIDO

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

نسخه OpenSSH و سیستم‌عامل

پشتیبانی از FIDO SSH نیازمند OpenSSH نسخه ۸.۲ یا بالاتر است. اکثر توزیع‌های مدرن لینوکس (Ubuntu 20.04 به بعد، Fedora 32 به بعد، Debian 11 به بعد) این نسخه را به‌صورت پیش‌فرض ارائه می‌دهند. برای بررسی نسخه OpenSSH نصب‌شده روی سیستم، کاربر می‌تواند دستور مربوطه را در ترمینال اجرا کند. در سمت سرور نیز باید OpenSSH Server نسخه ۸.۲ یا بالاتر نصب باشد. ویندوز ۱۰ (نسخه ۱۹۰۳ به بعد) و macOS (نسخه‌های اخیر) نیز از FIDO SSH پشتیبانی می‌کنند، هرچند ممکن است نیاز به نصب ابزارهای تکمیلی باشد.

انتخاب کلید امنیتی FIDO مناسب

انتخاب کلید امنیتی مناسب تأثیر مستقیمی بر امنیت و تجربه کاربری دارد. کلید امنیتی باید از پروتکل FIDO2/CTAP2 پشتیبانی کند (کلیدهایی که فقط U2F دارند، قابلیت‌های محدودتری خواهند داشت). پشتیبانی از الگوریتم Ed25519 ترجیح داده می‌شود. داشتن قابلیت Resident Key برای سناریوهای پیشرفته ضروری است. تأیید بیومتریک (اثر انگشت) روی خود کلید، لایه امنیتی اضافی فراهم می‌کند. اتصال USB-A، USB-C، NFC یا ترکیبی بر اساس نیاز سازمان انتخاب می‌شود.

کلیدهای امنیتی FIDO2 که نشانه ارائه می‌دهد، تمام این الزامات را پوشش می‌دهند و برای استفاده در محیط‌های سازمانی ایرانی بهینه‌سازی شده‌اند.

پیکربندی کتابخانه libfido2

کتابخانه libfido2 رابط ارتباطی بین OpenSSH و کلید امنیتی FIDO است. در اکثر توزیع‌های لینوکسی، این کتابخانه از مخازن رسمی قابل نصب است. پس از نصب، کاربر باید مطمئن شود که دسترسی مناسب به دستگاه USB برقرار است. در سیستم‌های لینوکسی معمولاً نیاز به اضافه کردن قوانین udev برای دسترسی غیر root به کلید امنیتی وجود دارد. بدون این پیکربندی، فقط کاربر root قادر به ارتباط با کلید امنیتی خواهد بود.

راهنمای گام‌به‌گام پیکربندی SSH با FIDO

این بخش فرآیند عملیاتی پیکربندی احراز هویت SSH با FIDO را به‌صورت مرحله‌به‌مرحله شرح می‌دهد. هر مرحله با توضیحات کافی ارائه شده تا حتی مدیران سیستمی که برای اولین بار با FIDO کار می‌کنند، بتوانند آن را پیاده‌سازی کنند.

تولید جفت‌کلید FIDO برای SSH

نخستین گام، تولید جفت‌کلید FIDO SSH است. کاربر باید کلید امنیتی FIDO2 را به سیستم متصل کند و سپس دستور تولید کلید را اجرا نماید. برای تولید کلید از نوع ed25519-sk، از پارامتر مربوطه در ssh-keygen استفاده می‌شود. سیستم از کاربر می‌خواهد کلید امنیتی را لمس کند تا حضور فیزیکی تأیید شود. پس از لمس، دو فایل ایجاد می‌شود: فایل کلید خصوصی (که در واقع حاوی Key Handle است، نه خود کلید خصوصی) و فایل کلید عمومی.

برای تولید کلید Resident (Discoverable) پارامتر اضافی مربوطه به دستور افزوده می‌شود. با فعال‌سازی گزینه verify-required، سیستم در هر بار استفاده علاوه بر لمس، اثر انگشت یا PIN نیز درخواست می‌کند. انتخاب بین این حالت‌ها بستگی به سطح امنیت مورد نیاز و راحتی کاربر دارد.

انتقال کلید عمومی به سرور

پس از تولید جفت‌کلید، کلید عمومی باید به فایل authorized_keys سرور مقصد اضافه شود. این کار با استفاده از ابزار ssh-copy-id یا کپی دستی محتوای فایل کلید عمومی انجام می‌شود. فرمت کلید عمومی FIDO SSH مشابه کلیدهای سنتی است، فقط نوع کلید متفاوت خواهد بود (مثلاً sk-ssh-ed25519 به‌جای ssh-ed25519). سرور بدون نیاز به تغییر خاصی قادر به شناسایی و پذیرش این نوع کلیدها خواهد بود، مشروط بر اینکه نسخه OpenSSH Server از ۸.۲ بالاتر باشد.

تنظیمات sshd_config برای پذیرش کلیدهای FIDO

در سمت سرور، فایل پیکربندی sshd_config باید به‌گونه‌ای تنظیم شود که از کلیدهای FIDO پشتیبانی کند و ترجیحاً روش‌های ناامن‌تر غیرفعال شوند. مهم‌ترین تنظیمات شامل غیرفعال‌سازی احراز هویت مبتنی بر رمز عبور، فعال‌سازی احراز هویت مبتنی بر کلید عمومی و تعیین مسیر فایل authorized_keys است. برای امنیت بیشتر، محدود کردن الگوریتم‌های مجاز به انواع sk (Security Key) نیز توصیه می‌شود. پس از اعمال تغییرات، سرویس SSH باید مجدداً راه‌اندازی شود.

نکته مهم: قبل از غیرفعال کردن احراز هویت رمز عبور، حتماً باید اطمینان حاصل کنید که اتصال با کلید FIDO به‌درستی کار می‌کند. در غیر این صورت ممکن است دسترسی به سرور را کاملاً از دست بدهید. نگه‌داشتن یک نشست SSH فعال به‌عنوان نشست پشتیبان در حین انجام تغییرات، رویکرد محتاطانه‌ای است.

تست اتصال و عیب‌یابی

پس از انجام تنظیمات، اتصال باید آزمایش شود. هنگام اتصال، سیستم از کاربر می‌خواهد کلید امنیتی را لمس کند. اگر اتصال موفق بود، پیکربندی به‌درستی انجام شده است. در صورت بروز خطا، چند نکته عیب‌یابی مفید وجود دارد: اجرای ssh با پارامتر verbose اطلاعات تشخیصی مفصلی ارائه می‌دهد. بررسی لاگ‌های سرور در مسیر مربوطه نیز کمک‌کننده است. اطمینان از نصب صحیح libfido2 و دسترسی مناسب به دستگاه USB از طریق ابزارهای تشخیصی fido2-token ضروری است. همچنین باید مطمئن شد که فایروال سمت سرور پورت SSH را مسدود نکرده باشد.

سناریوهای پیشرفته استفاده از FIDO در SSH

فراتر از پیکربندی پایه، سناریوهای پیشرفته‌ای وجود دارند که مدیران سیستم باتجربه می‌توانند از آن‌ها بهره ببرند. این سناریوها امنیت، انعطاف‌پذیری و قابلیت مدیریت را به سطح بالاتری ارتقا می‌دهند.

استفاده از چندین کلید امنیتی (Backup Key)

اتکا به یک کلید امنیتی واحد ریسک بزرگی ایجاد می‌کند: اگر کلید گم یا خراب شود، دسترسی به سرورها قطع خواهد شد. بهترین رویکرد، ثبت حداقل دو کلید امنیتی برای هر سرور است. کلید دوم به‌عنوان پشتیبان (Backup) در مکان امنی نگهداری می‌شود. فرآیند ثبت کلید دوم مشابه کلید اول است: جفت‌کلید جدیدی تولید و کلید عمومی آن نیز به فایل authorized_keys سرور اضافه می‌شود. برخی سازمان‌ها حتی یک کلید سوم را در صندوق امانات نگهداری می‌کنند تا در سناریوهای فاجعه‌آمیز (Disaster Recovery) قابل استفاده باشد.

ترکیب FIDO با Certificate Authority داخلی

برای سازمان‌های بزرگ، مدیریت فایل‌های authorized_keys روی صدها سرور کابوسی اداری است. ترکیب FIDO SSH با یک SSH Certificate Authority (CA) داخلی این مشکل را حل می‌کند. در این مدل، به‌جای توزیع کلیدهای عمومی روی تک‌تک سرورها، CA گواهی‌نامه‌ای برای کلید عمومی FIDO کاربر صادر می‌کند و سرورها فقط به CA اعتماد می‌کنند. این رویکرد مدیریت متمرکز، ابطال سریع دسترسی و اعمال سیاست‌های دسترسی مبتنی بر نقش را ممکن می‌سازد.

احراز هویت SSH بدون رمز عبور در محیط‌های ابری

استفاده از FIDO SSH در محیط‌های ابری الگوهای خاص خود را دارد. اتصال به سرورهای ابری معمولاً از طریق اینترنت صورت می‌گیرد و سطح تهدید بالاتری دارد، بنابراین FIDO SSH اهمیت مضاعفی پیدا می‌کند.

پیکربندی در AWS EC2

برای استفاده از FIDO SSH با اینستنس‌های EC2، باید AMI مورد استفاده OpenSSH 8.2+ داشته باشد. کاربر کلید عمومی FIDO را از طریق user-data یا بعد از اولین ورود به authorized_keys اضافه می‌کند. Security Group مربوطه باید پورت ۲۲ را فقط از IPهای مجاز اجازه دهد. ترکیب FIDO SSH با AWS Systems Manager Session Manager لایه امنیتی اضافی ایجاد می‌کند.

پیکربندی در سرورهای لینوکسی ایران

مدیران سیستم در ایران با چالش‌های خاصی مواجه هستند. تأخیر شبکه و فیلترینگ ممکن است بر فرآیند دریافت بسته‌های به‌روزرسانی OpenSSH تأثیر بگذارد. استفاده از مخازن داخلی (Mirror) برای به‌روزرسانی نرم‌افزار توصیه می‌شود. خوشبختانه خود فرآیند احراز هویت FIDO SSH به ارتباط اینترنتی نیاز ندارد و تماماً بین کلاینت و سرور صورت می‌گیرد. بنابراین حتی در شبکه‌های داخلی ایزوله نیز قابل استفاده است.

مدیریت متمرکز کلیدهای FIDO SSH در سازمان

وقتی تعداد کاربران و سرورها افزایش می‌یابد، مدیریت دستی کلیدهای FIDO SSH عملی نخواهد بود. سازمان‌ها به یک رویکرد متمرکز و خودکار نیاز دارند.

چالش‌های مقیاس‌پذیری

سازمانی با ۵۰ مدیر سیستم و ۲۰۰ سرور، در حالت ساده باید ۱۰,۰۰۰ ورودی authorized_keys مدیریت کند. هر بار که کارمندی اضافه یا حذف می‌شود، یا کلید امنیتی جایگزین می‌شود، تمام سرورهای مرتبط باید به‌روزرسانی شوند. بدون ابزار مدیریت متمرکز، این فرآیند مستعد خطا، وقت‌گیر و از نظر امنیتی ریسک‌دار است. کلیدهای قدیمی و منقضی‌شده که هنوز روی سرورها باقی مانده‌اند، یکی از رایج‌ترین آسیب‌پذیری‌ها در سازمان‌ها محسوب می‌شوند.

نقش سامانه IAM در مدیریت کلیدهای SSH

یک سامانه مدیریت هویت و دسترسی (IAM) مشکلات مقیاس‌پذیری را از ریشه حل می‌کند. سامانه IAM به‌عنوان منبع واحد حقیقت (Single Source of Truth) برای هویت کاربران و مجوزهای دسترسی عمل می‌کند. وقتی کاربر جدیدی اضافه می‌شود، سامانه IAM به‌صورت خودکار کلید عمومی FIDO او را به سرورهای مجاز توزیع می‌کند. هنگام خروج کارمند، غیرفعال کردن حساب در IAM فوراً دسترسی SSH او را در تمام سرورها قطع می‌کند. امکان تعریف سیاست‌های دسترسی مبتنی بر نقش (RBAC)، محدودیت زمانی و ثبت کامل رویدادها نیز از قابلیت‌های کلیدی IAM است.

راهکار نشانه (Neshane) برای احراز هویت FIDO SSH سازمانی

نشانه، محصول شرکت رهسا و ارائه‌شده از طریق neshane.co، یک پلتفرم جامع مدیریت هویت و دسترسی است که احراز هویت بدون رمز عبور مبتنی بر FIDO را در هسته خود جای داده است. این راهکار با ارائه ابزارهای متنوع احراز هویت و قابلیت‌های مدیریت متمرکز، پیاده‌سازی FIDO SSH در مقیاس سازمانی را عملی و قابل مدیریت می‌سازد.

قابلیت‌های نشانه در ایمن‌سازی دسترسی سرور

نشانه امکاناتی را فراهم می‌کند که فراتر از پیکربندی ساده FIDO SSH است. مدیریت متمرکز چرخه عمر کلیدهای FIDO (ثبت، توزیع، چرخش و ابطال) از طریق یک داشبورد واحد انجام می‌شود. یکپارچه‌سازی با SSO (Single Sign-On) سازمانی به مدیران امکان می‌دهد تا با یک فرآیند احراز هویت واحد به تمام سرویس‌ها دسترسی داشته باشند. پشتیبانی از توکن‌های FIDO، اپلیکیشن نشانه موبایل و کارت‌های RFID/NFC انعطاف‌پذیری لازم برای سناریوهای مختلف سازمانی را تأمین می‌کند. سامانه نشانه همچنین از احراز هویت چندعاملی بدون گذرواژه پشتیبانی می‌کند که امن‌ترین شیوه احراز هویت شناخته‌شده است.

یکپارچه‌سازی نشانه با زیرساخت SSH موجود

یکی از مزایای کلیدی نشانه، قابلیت یکپارچه‌سازی با زیرساخت SSH موجود سازمان بدون نیاز به تغییر بنیادین است. نشانه می‌تواند به‌عنوان SSH Certificate Authority عمل کند و گواهی‌نامه‌های SSH مبتنی بر FIDO صادر نماید. امکان تعریف سیاست‌های دسترسی گرانولار (مثلاً کدام کاربران به کدام سرورها با چه سطح دسترسی‌ای مجازند) در نشانه فراهم است. تمام ورودها و خروج‌ها ثبت و قابل ممیزی هستند و با سامانه‌های SIEM سازمان یکپارچه می‌شوند. این یکپارچه‌سازی به سازمان‌ها اجازه می‌دهد بدون اختلال در عملیات جاری، به‌تدریج به احراز هویت SSH با FIDO مهاجرت کنند.

بهترین شیوه‌های امنیتی برای SSH با FIDO

پیکربندی فنی تنها بخشی از معادله است. رعایت بهترین شیوه‌های امنیتی تضمین می‌کند که سرمایه‌گذاری سازمان در FIDO SSH به حداکثر بازدهی برسد.

سیاست‌های ذخیره‌سازی کلید (Key Storage)

ذخیره‌سازی امن کلیدها حیاتی‌ترین جنبه FIDO SSH است. کلید خصوصی واقعی همیشه باید درون عنصر امن کلید سخت‌افزاری FIDO باقی بماند و هرگز استخراج نشود. فایل‌های Key Handle (برای کلیدهای Non-Resident) باید با مجوزهای محدود روی سیستم کاربر ذخیره شوند. رمزگذاری دیسک (Full Disk Encryption) روی سیستم کاربر از دسترسی غیرمجاز به فایل‌های Handle جلوگیری می‌کند. کلیدهای امنیتی پشتیبان باید در مکان فیزیکی امن و جداگانه‌ای نگهداری شوند. ثبت شماره سریال و اطلاعات هر کلید امنیتی در یک سیستم مدیریت دارایی (Asset Management) نیز توصیه می‌شود.

سیاست‌های چرخش و ابطال کلید

کلیدهای FIDO SSH باید مشمول سیاست‌های چرخش (Rotation) منظم باشند. هرچند کلیدهای FIDO به دلیل ماهیت سخت‌افزاری، نسبت به کلیدهای نرم‌افزاری کمتر در معرض نشت هستند، چرخش دوره‌ای هر ۱۲ تا ۲۴ ماه توصیه می‌شود. ابطال فوری کلید در صورت گم شدن، سرقت یا خروج کارمند باید در کمتر از یک ساعت قابل اجرا باشد. یک سامانه IAM مانند نشانه، ابطال کلید را به فرآیندی ساده و خودکار تبدیل می‌کند.

نظارت و ثبت رویدادهای دسترسی

هر تلاش موفق و ناموفق اتصال SSH باید ثبت و نظارت شود. لاگ‌های SSH Server حاوی اطلاعات ارزشمندی هستند: نوع کلید استفاده‌شده، آدرس IP مبدا، زمان اتصال و نتیجه تلاش. ارسال این لاگ‌ها به یک سامانه SIEM (Security Information and Event Management) و تعریف قوانین هشدار برای رفتارهای مشکوک (مانند تلاش‌های ناموفق مکرر، اتصال از IPهای غیرمعمول یا اتصال در ساعات غیرکاری) از اقدامات ضروری است. ترکیب این نظارت با قابلیت‌های تحلیل رفتار کاربر (UBA)، سطح تشخیص تهدیدات را به‌شدت ارتقا می‌دهد.

مقایسه روش‌های مختلف احراز هویت SSH

برای درک بهتر جایگاه FIDO SSH در میان سایر روش‌های احراز هویت، مقایسه‌ای جامع ارائه می‌شود. احراز هویت مبتنی بر رمز عبور ساده‌ترین روش است اما پایین‌ترین سطح امنیت را ارائه می‌دهد؛ در برابر فیشینگ، Brute Force و سرقت اعتبارنامه آسیب‌پذیر است و برای محیط‌های تولیدی توصیه نمی‌شود.

کلید SSH سنتی (RSA/Ed25519) سطح امنیتی بالاتری دارد و در برابر Brute Force مقاوم است، اما کلید خصوصی به‌صورت فایل روی دیسک ذخیره می‌شود و در صورت نفوذ به سیستم کاربر قابل سرقت است. این روش تأیید حضور فیزیکی ندارد.

احراز هویت مبتنی بر گواهی‌نامه (SSH Certificate) مدیریت متمرکز بهتری فراهم می‌کند و امکان تعیین تاریخ انقضا و محدودیت‌های دسترسی را ارائه می‌دهد، اما همچنان کلید خصوصی نرم‌افزاری است.

احراز هویت SSH با FIDO بالاترین سطح امنیت را ارائه می‌دهد. کلید خصوصی هرگز از سخت‌افزار خارج نمی‌شود، تأیید حضور فیزیکی الزامی است و مقاومت ذاتی در برابر فیشینگ وجود دارد. ترکیب FIDO با SSH Certificate Authority بهترین حالت ممکن از هر دو جهت (امنیت سخت‌افزاری و مدیریت متمرکز) را فراهم می‌سازد.

احراز هویت مبتنی بر Kerberos/GSSAPI برای محیط‌های Enterprise با Active Directory مناسب است اما پیچیدگی بالایی دارد. در نهایت، هر سازمان باید بر اساس سطح حساسیت، تعداد کاربران و زیرساخت موجود، روش مناسب را انتخاب کند. FIDO SSH به‌تنهایی یا در ترکیب با Certificate Authority، امن‌ترین و مدرن‌ترین رویکرد موجود است.