کلید SSH اعتبارنامه (credential) دسترسی در پروتکل SSH است. عملکرد آن شبیه به نام کاربری‌ها و کلمات عبور می‌باشد، اما کلیدها عمدتا برای فرآیندهای خودکار و برای پیاده‌سازی ورود یکپارچه (single sign-on) توسط مدیران سیستم و کاربران باتجربه استفاده می‌شوند.

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

SSH (Secure Shell) برای مدیریت شبکه‌ها، سیستم‌ عامل‌ها و پیکربندی‌ها استفاده می‌شود. همچنین درون بسیاری از ابزارهای انتقال فایل و ابزارهای مدیریت پیکربندی استفاده می‌شود. هر شرکت بزرگی، در هر مرکز داده‌ای، از آن استفاده می‌کند.

کلیدهای SSH اتوماسیونی را فعال می‌کنند که خدمات ابری مدرن و سایر خدمات وابسته به کامپیوتر را امکان‌پذیر و مقرون‌به‌ٌصرفه می‌سازد. آن‌ها وقتی به درستی مدیریت می‌شوند، سهولت را فراهم کرده و امنیت را بهبود می‌بخشند.

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

از نظر فنی کلیدها، کلیدهای رمزنگاری شده با استفاده از کلید عمومی سیستم‌های رمزنگاری/رمزگشایی هستند. با این حال، از لحاظ عملکردی، اعتبارنامه احراز هویت هستند و نیاز به مدیریتی همانند آن دارند.

کلیدهای مجاز (Authorized) مشخص می‌کند چه کسی می‌تواند به هر سیستم دسترسی داشته باشد

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

کلیدهای شناسایی (Identity) کاربران را شناسایی کرده و دسترسی را فراهم می‌کنند

کلیدهای شناسایی کلیدهای خصوصی هستتند که کلاینت SSH برای احراز هویت خود وقتی وارد سرور SSH می‌شود، از آن استفاده می‌کند. آن‌ها مشابه کلیدهای فیزیکی هستند که می‌توانند یک یا چند قفل را باز کنند.

کلیدهای مجاز و کلیدهای شناسایی به طور مشترک کلیدهای کاربران نامیده می‌شوند. آن‌ها احراز هویت کاربر را بررسی می‌کنند، برخلاف کلیدهای میزبان (host) که برای احراز هویت میزبان استفاده می‌شوند.

احراز هویت کاربر بر اساس گواهی (Certificate)

گواهی‌های PKI می‌تواند برای احراز هویت هم استفاده شود. در این مورد، کاربر هنوز یک کلید خصوصی دارد اما دارای یک گواهی مربوط به کلید هم هست. این تکنولوژی از Tectia SSH و OpenSSH، با کمی تفاوت، پشتیبانی می‌کند.

کلیدهای احراز هویت دستگاه

کلیدهای Host احراز هویت سرورها

کلیدهای  host برای احراز هویت  hostها مثل کامپیوترها استفاده می‌شوند. هدف آن‌ها جلوگیری از حملات انسانی است.

احراز هویت host بر اساس گواهی‌ یا همان Certificate می‌تواند شیوه بسیار جالبی در سازمان‌های بزرگ باشد و اجازه می‌دهد کلیدهای احراز هویت دستگاه به راحتی مدیریت شده و هر اتصال به صورت امن برقرار شود.

کلیدهای host شناخته شده

یکی از ویژگی‌های منحصربه‌فرد SSH این است که به طور پیش‌فرض، کلید host را در هنگام اولین اتصال به آن، حفظ کرده و به خاطر می‌سپارد. این یک تمایز کلیدی بود که به SSH اجازه می‌داد تا منشأ آن را گسترش دهد، چرا که هیچ زیرساخت کلیدی متمرکزی برای hostها در سال 1995 وجود نداشت، و همچنان امروزه (2017)، با معافیت گواهی SSL برای وب سرورها، وجود ندارد. درنتیجه، سهولت به‌کارگیری یکی از دلایل اصلی بود که باعث موفقیت SSH شد.

کلیدهای host حفظ شده، کلیدهای host شناخته شده نامیده می‌شوند و در فایلی به نام known_hosts در OpenSSH ذخیره می‌شوند. تا زمانی که کلید host تغییری نداشته باشد، استفاده از این رویکرد بسیار آسان بوده و امنیت نسبتا خوبی را فراهم می‌کند. با این حال، در سازمان‌های بزرگ و زمانی که کلید تغییر می‌کند، حفظ فایل‌ hostهای شناخته‌شده می‌تواند بسیار وقت‌گیر شود. در این مورد، استفاده از گواهی‌ها برای کلیدهای host توصیه می‌شود. Tectia SSH از گواهی‌های X.509 استاندارد برای hostها پشتیبانی می‌کند. OpenSSH فرمت گواهی‌ اختصاصی خودش را دارد. مزیت گواهی‌های مبنی بر استاندارد این است که آن‌ها می‌توانند توسط هر مرجع صدور گواهی دیجیتال (CA) صادر شوند، در حالی که هیچ CA قابل اعتمادی برای کلیدهای OpenSSH وجود ندارد.

کلیدهای Session

کلید Session در SSH یک کلید رمزنگاری شده است که برای رمزگذاری اکثریت داده‌ها در یک اتصال استفاده می‌شود. کلید Session در طول اتصال مذاکره می‌کند و سپس با الگوریتم رمزنگاری متقارن و الگوریتم کد احراز هویت پیام، برای محافظت از داده‌ها استفاده می‌شود.

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

احراز هویت بر اساس کلید در SSH احراز هویت کلید عمومی نامیده می‌شود. پیکربندی آن توسط end userها در تنظیمات پیش‌فرض آسان است. از سوی دیگر، سازمان‌های امنیتی باید سیاست‌های روشنی را برای شرایط و پایان دادن دسترسی بر اساس کلید برقرار کنند.

نحوه راه‌اندازی احراز هویت کلید عمومی برای OpenSSH

کلیدهای SSH معمولا در فایل authorized_keys در زیرپوشه ssh. در پوشه home کاربر پیکربندی شده‌اند. معمولا مدیر سیستم ابتدا کلیدی را با استفاده از ssh-keygen ایجاد می‌کند و سپس آن را به عنوان کلید مجاز در سرور با استفاده از ابزار ssh-copy-id نصب می‌کند. همچنین صفحه اختصاصی در پیکربندی کلیدهای مجاز برای OpenSSH را مشاهده می‌کند.

ما استفاده کردن از عبارات عبور (passphrases) برای همه کلیدهای شناسایی که برای دسترسی تعاملی استفاده می‌شوند را توصیه می‌کنیم. استفاده کردن از عبارات عبور برای دسترسی خودکار خوب است، اما این کار اغلب عملی نیست.

ذخیره کلیدها در ssh-agent برای ورود یکپارچه (SSO)

SSH همراه با برنامه‌ای به نام ssh-agent می‌آید که می‌تواند کلیدهای خصوصی رمزگشایی شده کاربر را در حافظه نگه دارد و از آن‌ها برای احراز هویت ورودها استفاده کند. agent همچنین می‌تواند برای دسترسی کلیدها در یک کارت هوشمند یا در یک ماژول امنیتی سخت‌افزاری (HSM) استفاده شود.

اتصال به SSH agent را می‌توان به سرور ارسال کرد، به طوری که SSo به واسطه آن سرور کار می‌کند. این ویژگی باید با دقت استفاده شود، زیرا به سرور اجازه می‌دهد تا گواهی کاربر از agent اصلی استفاده کند. با این حال، ارسال agent می‌تواند ویژگی بسیار آسانی برای کاربران باتجربه در محیط‌های بحرانی امنیتی باشد.

برای فعال کردن ارسال agent، AllowAgentForwarding را به yes در etc/ssh/sshd_config/ روی سرور و ForwardAgent را به yes در فایل پیکربندی کلاینت etc/ssh/ssh_config/ تنظیم کنید.

اندازه‌های توصیه‌شده کلید

توصیه می‌کنیم اندازه‌های کلید را مطابق با NIST SP 800-57 انتخاب کنید. اندازه پیش‌فرض کلید توسط ابزار ssh-keygen مورد استفاده قرار می‌گیرد که معمولا قدرت قابل قبولی دارد. درحقیقت، از آنجایی که پروتکل هرگز کلیدهای عمومی‌ای که برای احراز هویت کاربر قابل قبول هستند را آشکار نمی‌سازد، الگوریتم‌ها برای کلیدهایی که به اندازه آن‌ها بحرانی نیستند، مثل گواهی‌های PKI، استفاده می‌شوند.

امروزه برای کلیدهای RSA، احتمالا 2048 بیت انتخاب خوبی است. با این حال، در حال حاضر بسیاری از رمزگذارها توصیه می‌کنند به کلیدهای ECDSA سوئیچ کنید و فکر می‌کنند که پیشرفت در فاکتورهای عدد صحیح بزرگ ممکن است کلیدهای RSA را آسیب‌پذیر سازد. توصیه ما برای ECDSA استفاده از کلیدهای 521 بیتی است، حتی کلیدهای 384 یا 256 بیتی احتمالا ایمن باشند.  استفاده از کلیدهای کوچکتر هیچ مزیت کاربردی ندارد.

موقعیت کلید شناسایی

کلیدهای شناسایی معمولا در پوشه ssh. کاربر ذخیره می‌شوند، به عنوان مثال، ssh/ssh_id_rsa. نام فایل پیش‌فرض کلید شناسایی با id_<algorithm> شروع می‌شود. هنگام ایجاد کلید خصوصی، می‌توانید هر نام فایل و هر مکانی را مشخص کنید، و نام مسیر را با گزینه i– برای SSH  کلاینت ارائه دهید. مثلا، ssh -i /home/ylo/secure/my-key ec2-user@awshost.domain.my از یک کلید خصوصی از فایل my-key برای احراز هویت استفاده خواهد کرد.

مکان پیش‌فرض کلید شناسایی همچنین می‌تواند در etc/ssh/ssh_config/ یا فایل ssh/config. کاربر با استفاده از گزینه IdentityFile پیکربندی شود.

مکان کلید مجاز

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

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

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

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

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

در اصل، انتقال کلیدهای SSH به مکانی در روت آسان است:

1. پوشه مناسبی در روت ایجاد کنید، مثل etc/ssh/keys/، که کلیدهای مجاز در آن ذخیره شوند.

2. در این پوشه یک زیرپوشه برای هر کاربر ایجاد کرده و هر فایل authorized_keys را به etc/ssh/keys/<user>/authorized_keys/ منتقل کنید.

3. درنهایت، تنظیمات AuthorizedKeysFile /etc/ssh/keys/%u/authorized_keys را به etc/ssh/sshd_config/ تغییر دهید.

در عمل، این کار همیشه ساده نیست، به ویژه در محیط‌های بزرگ‌تر. نام کاربری‌ها ممکن است از پوشه‌هایی مثل Active Directory یا LDAP بیاید. بسیاری از سازمان‌ها دارای نسخه‌های متفاوتی از OpenSSH هستند، ازجمله سیستم‌های بسیار قدیمی یا SSH سفارشی که با مسیرهای داخلی غیراستانداردی ساخته شده‌اند. توصیه می‌کنیم از ابزارهای مدیریت کلید مانند Universal SSH Key Manager برای مخفی کردن این پیچیدگی‌ها در محیط‌های بزرگ استفاده کنید. این ابزارها همچنین می‌توانند جریان کار شرط‌ دادن، خاتمه دادن و تأییدیه را برای کلیدها و هشدارهای مربوط به تغییرات غیرمجاز ساخته شده توسط کاربران روت را پیاده‌سازی کنند.

محدودیت OpenSSH در تعداد کلیدهای خصوصی

سرور OpenSSH  دارای یک ویژگی است (ما آن را باگ می‌نامیم) که تست‌ها را محاسبه می‌کند که آیا کلید خاصی می‌تواند برای احراز هویت به عنوان تلاشی برای احراز هویت استفاده شود. در نتیجه این کار، اگر کاربر بیش از پنج کلید را در ssh. استفاده کند، تنها برخی از آن‌ها کار می‌کنند. این امر اغلب باعث می‌شود احراز هویت مبنی بر کلید شکست بخورد. راه‌حل این است که کلید خصوصی با گزنیه  i- به صراحت مشخص شود. روشی است که سشن MaxAuthTries را روی سرور تنظیم می‌کند، اما این راه‌حل کامل نیست و برای افزایش تعداد تلاش جهت تأیید کلمه عبور نامطلوب است.

کلیدهای SSH چه شکلی هستند

کلید مجاز می‌تواند این چنین باشد:

ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTY
AAABBBN+Mh3U/3We4VYtV1QmWUFIzFLTUeegl1Ao5/QGtCRGAZn8bxX9KlCrrWISIjS
YAwCajIEGSPEZwPNMBoK8XD8Q= ylo@klar

کلید شناسایی می‌توانداین چنین باشد:

-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIJWbvSW7h50HPwG+bWR3DXgQ6YhOxYbe0ifr1rRUvsUuoAoGCCqGSM49
AwEHoUQDQgAE34yHdT/dZ7hVi1XVCZZQUjMUtNR56CXUCjn9Aa0JEYBmfxvFf0qU
KutYhIiNJgDAJqMgQZI8RnA80wGgrxcPxA==
-----END EC PRIVATE KEY-----

نحوه کار احراز هویت در  SSH چگونه است؟

اتصال اولیه در SSH شامل:

مذاکره با نسخه‌های پروتکل مورد استفاده

مذاکره با الگوریتم‌های رمزنگاری و سایر گزینه‌های مورد استفاده

مذاکره با کلید سشن one-time برای رمزگذاری سایر سشن‌ها

اعتبارسنجی سرور host با استفاده از کلید host

اعتبارسنجی کاربر با استفاده از کلمه عبور، احراز هویت کلید عمومی یا سایر ابزار

پس از این کارها، داده‌ها می‌توانند مبادله شوند، ازجمله داده‌های ترمینال، گرافیک‌ها و فایل‌ها.

احراز هویت کلید عمومی

مکانیسم احراز هویت بر اساس کلید در SSH احراز هویت کلید عمومی نامیده می‌شود. اساسا برخی از داده‌های مربوط به session با استفاده از کلید شناسایی خصوصی امضاء می‌شوند. پس از آن امضاء به سرور ارسال می‌شود که بررسی می‌کند اگر کلید برای امضاء استفاده می‌شود به عنوان کلید مجاز پیکربندی شده است. سپس سرور با استفاده از کلید عمومی در کلید مجاز، امضای دیجیتال را تأیید می‌کند. کلید شناسایی هرگز به سرور ارسال نمی‌شود.

مسأله اساسی در احراز هویت کلید عمومی این است که اجازه می‌دهد یک سرور به سرورهای دیگر دسترسی داشته باشد بدون اینکه کلمه عبور را تایپ کند. دلیل این ویژگی قدرتمند این است که به طور گسترده برای انتقال فایل‌ها (با استفاده از پروتکل SFTP) و مدیریت پیکربندی استفاده می‌شود. این موضوع نیز معمولا توسط مدیران سیستم برای SSO استفاده می‌شود.

کلیدهای SSH چقدر رایج هستند و خطر آن‌ها چیست

کلیدهای SSH به شدت رایج هستند و به طور گسترده مورد استفاده قرار می‌گیرند. بسیاری از سازمان‌های بزرگ برای بیست سال آن‌ها را بدون هیچ کنترلی انباشته‌اند. شرکت Fortune 500 دارای چندین میلیون کلید دسترسی برای سرورهایش می‌باشد. در یک مورد مشتری، ما 500 برنامه و 15000 سرور را بررسی کردیم، و 3000000 کلید مجاز و 750000 جفت کلید منحصربه‌فرد یافتیم. این سازمان همچنین دارای بیش از پنج میلیون ورود روزانه با استفاده از کلیدها بود. کلیدها برای انجام معاملات مالی، به‌روزرسانی پیکربندی‌ها، انتقال داده‌های ثبت وقایع، انتقال فایل‌ها، ورودهای تعاملی توسط مدیران سیستم و بسیاری اهداف دیگر مورد استفاده قرار گرفته بود.

اکثر شرکت‌های سرمایه‌گذاری بزرگ صدها هزار و یا حتی میلیون‌ها کلید را تولید می‌کنند. این کلیدها قابل دسترس هستند و برای کل شرکت ریسک محسوب می‌شود.

چطور کلیدهای SSH را کاملا حذف کنیم.

PrivX On-Demand Access Manager می‌تواند برای از بین بردن کامل کلیدهای SSH از سرورها استفاده شود و ورود session و کنترل دسترسی عمومی را در بین شرکت‌ها ایجاد کند. همچنین اکثر بارهای اجرایی در مدیریت کلید را حذف می‌کند، درحالیکه همچنان مزایایی همچون تنظیمات خودکار و SSO را ارائه می‌دهد.