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

ساچور شell (SSH) یک پروتکل امنیتی معمول است که دارای طیف وسیعی از کاربردهای مختلف است. مشهورترین برنامه آن به کاربران امکان می دهد دسترسی ایمن به رایانه ها و سرورهای از راه دور, اما همچنین می تواند برای تونل زنی ، حمل و نقل پورت ، انتقال پرونده های ایمن و موارد دیگر مورد استفاده قرار گیرد.

در این راهنما ، ما پوشش خواهیم داد آنچه SSH است ، چه چیزی برای آن استفاده می شود ، تاریخچه پروتکل ، جزئیات فنی آن است, به همان خوبی مسائل امنیتی که باید مورد توجه قرار گیرد.

SSH از سه پروتکل جداگانه تشکیل شده است: لایه حمل و نقل ، لایه تأیید اعتبار و لایه اتصال. اینها در کنار هم ، به تأیید هویت طرف مقابل در ارتباط ، ارائه محرمانه از طریق رمزگذاری ، و بررسی صحت اطلاعات می پردازند. اکنون SSH معمولاً به عنوان SSH-2 اختصاصی یا به عنوان تکرار منبع باز ، OpenSSH اجرا می شود..

استفاده از SSH

SSH یک پروتکل همه کاره است. ساختار و ویژگی های امنیتی آن اجازه می دهد تا از چندین روش استفاده شود ، مانند دسترسی از راه دور ، انتقال پورت ، تونل زنی و انتقال پرونده های ایمن.

دسترسی از راه دور

دسترسی از راه دور راهی را برای کاربران فراهم می کند از دستگاه خود وارد یک رایانه یا سرور دیگر شوید. این برای دسترسی به پرونده های محلی دستگاه مورد نظر یا انجام خدمات روی آن استفاده می شود ، همه بدون اینکه از نظر جسمی در آنجا حضور داشته باشند.

برنامه هایی مانند Telnet و rlogin نیز از این قابلیت برخوردار هستند ، اما فاقد ویژگی های امنیتی SSH هستند. اقدامات رمزگذاری و تأیید صحت درگیر در SSH به کاربران امکان می دهد به شیوه ای محافظت شده ، حتی از طریق یک شبکه واسطه بالقوه خطرناک ، به یک سرور یا رایانه دیگر متصل شوند..

دسترسی از راه دور با SSH معمولاً به گونه ای انجام می شود كه كارمندان بتوانند از راه دور كار كنند ، یا اینكه به بخش IT اجازه می دهد وظایف خود را بدون نیاز به مراجعه فیزیكی به دستگاه انجام دهد. این می تواند برای مدیریت از راه دور ، مدیریت زیرساخت شبکه ، برای تنظیم اتوماسیون ، ایجاد پشتیبان و موارد دیگر استفاده شود.

پورت حمل و نقل

حمل و نقل پورت برای انتقال درخواست از یک آدرس و شماره پورت به مجموعه دیگر استفاده می شود. این برنامه از آدرس آدرس شبکه (NAT) برای هدایت پورت ها بین یک شبکه محلی و یک کامپیوتر از راه دور استفاده می کند و به شما امکان می دهد از خارج از شبکه به دستگاهی دسترسی پیدا کنید..

حمل و نقل بندر به سه روش مختلف قابل انجام است:

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

تونل زدن

پروتکل های تونلینگ از کپسوله سازی برای انتقال داده ها بین شبکه ها استفاده می کنند. تونل ها می توانند مستقر شوند تا پروتکل های غیر بومی از طریق شبکه هایی اجرا شوند که به طور عادی از آنها پشتیبانی نمی کنند. یکی دیگر از کاربردهای رایج برای تأمین امنیت از طریق شبکه ناامن.

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

SFTP

پروتکل انتقال فایل SSH (FTP) ، که گاه به عنوان پروتکل امن انتقال پرونده نیز شناخته می شود ، روشی ایمن برای دسترسی ، انتقال و مدیریت فایل ها فراهم می کند. این یک جایگزین مطمئن برای FTP است ، و از پروتکل SSH برای ارسال ایمن ، ارسال و مدیریت پرونده ها استفاده می کند.

SCP

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

بستر، زمینه & برنامه هایی که از SSH استفاده می کنند

اختصاصی SSH یا OpenSSH در کلیه سیستم عاملهای اصلی قابل استفاده است. این در سیستم عامل های مبتنی بر یونیکس مانند OpenBSD ، macOS ، Linux و Solaris در دسترس است ، در حالی که کاربران Windows می توانند از SSH از طریق PowerShell استفاده کنند.

تاریخچه SSH

SSH در سال 1995 در دانشگاه صنعتی هلسینکی توسط تاتو یلنن در پاسخ به حمله پوزه با رمز عبور به شبکه این دانشگاه توسعه داده شد. این هدف با ارائه جایگزین پروتکل هایی مانند FTP ، TELNET ، rsh و رولین, که از محرمانه بودن یا تأیید اعتبار کاربران به روشی مطمئن اطمینان حاصل نکرده است.

SSH در سال 1995 به صورت رایگان در دسترس عموم قرار گرفت و مورد استقبال خوبی قرار گرفت. در طول تصویب سریع آن ، Ylönen تأسیس امنیت ارتباطات SSH تا پایان همان سال به منظور ادامه توسعه و تجاری سازی SSH.

در سال 1995 ، Ylönen همچنین یک پیش نویس اینترنتی مهندسی اینترنت (IETF) منتشر کرد پروتکل SSH-1 را مستند کرد. محدودیت ها به زودی در پروتکل یافت می شوند ، و بدون اینکه روی سازگاری به عقب تأثیر بگذارد ، قابل حل نیست. راه حل نسخه جدید پروتکل بود و SSH-2 توسط شرکت Ylönen در سال 1996 راه اندازی شد.

SSH-2 دارای الگوریتم های جدیدی بود که باعث شد IETF یک کارگروه با هدف استاندارد سازی پروتکل ایجاد کند. این گروه به نام SECSH لقب گرفتند ثانیهاوه شell ، و اولین پیش نویس اینترنتی خود را برای SSH-2 در 1997 منتشر کرد.

نرم افزار SSH-2 در سال 1998 منتشر شد ، اما به دلیل محدود کننده تر مجوز آن ، فوراً به شیوه گسترده ای پذیرفته نشد.. در سال 2006 ، یک نسخه تغییر یافته از پروتکل توسط IETF استاندارد ساخته شد. این با استفاده از کدهای تأیید صحت پیام برای بررسی یکپارچگی و تبادل کلید Diffie-Hellman برای تأیید اعتبار ، امنیت بیشتری داشت.

در سال 1999 پروژه OpenBSD OpenSSH را منتشر کرد. OpenSSH نسخه رایگان پروتکل است این است که در تغییراتی که Björn Grönvall به SSH 1.1.12 ساخته است. توسعه دهندگان به این نسخه قدیمی بازگشتند و به شدت آن را تغییر دادند ، زیرا آخرین نسخه SSH بود که کاملاً منبع باز بود. OpenSSH اکنون پرکاربردترین گزینه است و از آن زمان تاکنون در طیف وسیعی از سیستم عامل ها مانند ویندوز ، macOS ، لینوکس ، سولاریس و سایرین اجرا شده است..

SSH-1 در مقابل SSH-2 در مقابل OpenSSH

همانطور که گفته شد ، SSH-1 اولین نسخه پروتکل است که در ابتدا تحت آن منتشر شد مجوز منبع باز. این ناامن تلقی می شود ، و نباید اجرا شود. این نسخه اختصاصی ، SSH-2 ، و نسخه آزادانه در دسترس ، OpenSSH را به عنوان گزینه های مناسب در اختیار شما قرار می دهد.

SSH-2 و OpenSSH در مورد معماری و نحوه کار آنها اساساً یکسان هستند. تفاوت اصلی این است که نسخه اختصاصی دارای طیف وسیعی از گزینه های پشتیبانی است ، در حالی که آنهایی که از OpenSSH استفاده می کنند باید به منابعی که بطور آزاد توسط جامعه ایجاد شده اند اعتماد کنند..

SSH: مشخصات فنی

SSH-1 به عنوان یک پروتکل واحد عمل می کرد ، اما ما از اینجا منسوخ نمی شویم. در عوض ، ما بر روی SSH-2 و OpenSSH ، که هر دو از سه پروتکل جداگانه تشکیل شده اند ، متمرکز خواهیم شد:

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

هر یک از این پروتکل ها نقش منحصر به فردی دارند که در جهت برقراری و تأمین اتصال ، تأیید هویت طرف مقابل و انتقال داده ها مؤثر است. درگاه پیش فرض اتصال TCP 22 است و اتصالات بین یک سرویس دهنده SSH و یک سرور SSH در امتداد آن تنظیم شده است مدل مشتری-سرور.

فرآیند ورود به سیستم از راه دور SSH مطابق ساختار اساسی زیر (با تغییرات بسته به پیکربندی) ادامه می یابد ، که بعداً با جزئیات بیشتری به آنها خواهیم پرداخت:

• مشتری برای شروع اتصال با سرور SSH تماس می گیرد.
• سپس سرور کلید عمومی خود را برای تأیید هویت خود به مشتری ارسال می کند.
• دو طرف در مورد پارامترهای اتصال مذاکره می کنند ، سپس یک کانال امن را در امتداد آن خطوط ایجاد می کنند.
• کاربر سپس وارد سیستم عامل میزبان سرور می شود و اکنون می تواند وظایف خود را از راه دور انجام دهد.

پروتکل حمل و نقل

لایه حمل و نقل یک پروتکل سطح پایین است که به کارهای زیر توجه می کند.

• احراز هویت میزبان سرور
• تبادل کلید
• رمزگذاری برای محرمانه بودن داده ها
• یکپارچگی بررسی می کند که داده ها تغییر نکرده اند
• ایجاد شناسه جلسه که می تواند در پروتکل های دیگر مورد استفاده قرار گیرد

پروتکل حمل و نقل تنها سرور را تأیید می کند و نه مشتری (احراز هویت مشتری در صورت لزوم در پروتکل تأیید اعتبار انجام می شود).

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

پس از شروع اتصال ، سرور و مشتری باید از طریق یک رشته شناسایی ارسال کنند ، که شامل نسخه پروتکل (2.0).

مذاکره الگوریتم

برای تنظیم پارامترهای اتصال ، هر دو طرف با استفاده از یک بسته شامل یک لیست با گزینه های زیر از طریق بسته ارسال می کنند:

بایت SSH_MSG_KEXINIT

کوکی بایت [16] (بایت تصادفی)
لیست نام kex_algorithms
server -host_key_algorithms-list-list
لیست نامگذاری encryption_algorithms_client_to_server
name-list encryption_algorithms_server_to_client
لیست نام mac_algorithms_client_to_server
لیست نام mac_algorithms_server_to_client
compression_algorithms_client_to_server-list name
لیست نام compression_algorithms_server_to_client
لیست نامها Language_client_to_server
لیست نامها Language_server_to_client
boolean first_kex_packet_follows
uint32 0 (برای برنامه افزودنی در آینده ذخیره شده است)

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

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

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

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

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

تبادل کلید

مسئولیت مبادله کلیدی است احراز هویت سرور, و آن کلیدهایی را که برای امنیت اتصال استفاده می شود تنظیم می کند در مراحل بعدی این امر به طور کلی با ارسال طرفین لیست های الگوریتم های پشتیبانی شده به یکدیگر آغاز می شود. از طرف دیگر ، هر طرف می تواند الگوریتم مورد نظر طرف مقابل را حدس زده و بسته ای را ارسال کند که متناسب با پارامترهای این الگوریتم در ابتدا باشد.

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

تبادل کلید نیز وظیفه ایجاد یک راز مشترک و یک هش را بر عهده دارد. مقدار هش از مبادله اولیه کلید تبدیل به یک شناسه منحصر به فرد برای جلسه می شود و همچنین به عنوان بخشی از امضاهای دیجیتال مورد استفاده قرار می گیرد که ثابت می کند طرف صاحب واقعی کلید خصوصی آن است..

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

مطابق با پیش نویس اینترنتی مهندسی اینترنت (IETF) روش های تبادل کلیدی زیر در نظر گرفته می شود:

• curve25519-sha256
• curve448-sha512
• difie-hellman-group-exchange-sha256
• difie-hellman-group14-sha256
• diffie-hellman-group15-sha512
• diffie-hellman-group16-sha512
• difie-hellman-group17-sha512
• difie-hellman-group18-sha512
• ecdh-sha2-nistp256
• ecdh-sha2-nistp384
• gss-group14-sha256
• gss-group15-sha512
• gss-group16-sha512
• gss-group17-sha512
• gss-group18-sha512
• gss-nistp256-sha256
• gss-nistp384-sha384
• gss-nistp521-sha512
• gss-curve25519-sha256
• gss-curve448-sha512
• rsa2048-sha256

الگوریتم کلید میزبان سرور

از این الگوریتم های کلید عمومی استفاده می شود احراز هویت سرور و همچنین برای ایجاد ایمن شناسه جلسه مشترک. آنها همچنین می توانند به صورت اختیاری برای تأیید اعتبار میزبان مورد استفاده قرار گیرند. SSH برای کار با طیف وسیعی از الگوریتم های کلید عمومی ، انواع و قالب های رمزگذاری شده طراحی شده است:

• از الگوریتم های کلید عمومی برای رمزگذاری و / یا امضاهای دیجیتال استفاده می کند.
• طیف وسیعی از روش های رمزگذاری می تواند اجرا شود ، امکان تنظیم پیکربندی با فرمت های مختلف داده ، padding و ترتیب بایت.
• قالب های مختلف کلید اجازه می دهد تا کلیدها به روش های مختلف رمزگذاری شوند ، همچنین طیف وسیعی از نمایشنامه ها را نشان می دهد.

الگوریتم های پیش فرض شامل موارد زیر است ، با این وجود برخی تغییرات دیگر نیز قابل اجرا هستند:

• ssh-rsa
• ssh-rsa-sha256
• ssh-dss
• ssh-dss-sha256
• x509v3-sign-dss
• x509v3-sign-dss-sha256
• x509v3-sign-rsa
• x509v3-sign-rsa-sha256

الگوریتم های رمزگذاری

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

طیف وسیعی از الگوریتم های رمزگذاری مختلف در SSH پذیرفته شده است ، اما برای اهداف امنیتی بهتر است با AES بچسبید. کلیدها باید حداقل 128 بیتی باشند ، اما کلیدهای بزرگتر ترجیح داده می شوند.

الگوریتم های MAC

پروتکل حمل و نقل با افزودن یک کد تأیید اعتبار پیام (MAC) به بسته ، صحت اطلاعات را تأیید می کند. این MAC بر اساس راز مشترک (که در مبادله کلید مشخص شده است) ، شماره دنباله بسته و محتویات بسته استوار است. قبل از وقوع رمزگذاری محاسبه می شود.

برای اجرای در هر جهت ، پیاده سازی ها باید یک الگوریتم مستقل ارائه دهند ، اگرچه اگر از هر دو طرف استفاده شود ، ایده آل است. طیف گسترده ای از الگوریتم های تأیید اعتبار پیام قابل اجرا است ، اما SHA-256 و بالاتر باید در بیشتر شرایط مورد استفاده قرار گیرد تا از امنیت بالایی برخوردار شود..

فشرده سازی

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

بسته پروتکل حمل و نقل

بسته پروتکل حمل و نقل به گونه ای تهیه شده است که می تواند اطلاعات زیر را در بر بگیرد (و همچنین برخی از جزئیات کم اهمیت تر که مانده است):

• طول بسته
• طول بالشتک
• بار
• لایه گذاری
• کد تأیید اعتبار پیام (MAC)

پروتکل احراز هویت

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

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

امنیت پروتکل احراز هویت وابسته به پروتکل حمل و نقل است که در بالای آن اجرا می شود. اگر پروتکل حمل و نقل نتواند محرمانه بودن را تضمین کند یا صحت و سقم داده ها را بررسی کند ، در این صورت چگونگی استفاده ایمن از پروتکل احراز هویت محدود می شود..

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

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

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

پروسه پروتکل تأیید اعتبار

پروتکل احراز هویت از زمانی شروع می شود که سرور لیستی از روشهای تأیید اعتبار پذیرفته شده خود را به مشتری ارسال می کند. مشتری می تواند به هر ترتیب از بین این روشها انتخاب کند. این فرایند کنترل را به سرور می دهد ، اما همچنین انعطاف پذیری کافی را امکان پذیر می کند تا مشتری بتواند ترتیب استفاده از راحت ترین روش را فراهم کند.

متداول ترین روش های تأیید اعتبار مشتری شامل موارد زیر است:

• کلید عمومی – در این روش از الگوریتم هایی مانند RSA ، DSA و ECDSA برای احراز هویت مشتری از طریق رمزنگاری کلید عمومی استفاده می شود. برخی از پیاده سازی ها از گواهینامه x.509 نیز استفاده می کنند. سرور برای تأیید هویت مشتری ، امضای دیجیتالی مشتری را در برابر کلید عمومی خود بررسی می کند.
• کلمه عبور – همچنین می توانید از گذرواژه‌ها برای تأیید اعتبار مشتری استفاده کنید. مشتری از طریق رمز عبور خود ارسال می کند (که باید توسط پروتکل حمل و نقل رمزگذاری شود). اگر گذرواژه با مقدار ذخیره شده سرور مطابقت داشته باشد ، پذیرفته می شود و احراز هویت به جلو پیش می رود.
• GSSAPI – تحت این روش می توان از طرح های خارجی مانند Kerberos برای ورود به سیستم استفاده کرد.
• صفحه کلید تعاملی است – این تکنیک تأیید اعتبار یک بار رمز عبور را با درخواست سرور از مشتری می خواهد تا اطلاعات را دریافت کند.

پروتکل اتصال

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

پروتکل اتصال در بالای لایه حمل و نقل و پروتکل های تأیید اعتبار قرار دارد. این برنامه امکان اجرای فرمان از راه دور و همچنین اتصالات X11 و TCP / IP را فراهم می کند. اگر سرور یا مشتری به خطر بیفتد ، پروتکل اتصال امن نیست.

کانالها

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

باز کردن کانال ها

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

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

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

• منع شده توسط دولت
• اتصال انجام نشد
• نوع کانال ناشناخته
• کمبود منابع

اگر هر دو طرف اتصال بخواهند داده بیشتری را از آنچه پنجره اجازه می دهد ارسال کنند ، می توانند پیامی را ارسال کنند که درخواست اضافه کردن بایت های بیشتر را دارد.

بسته شدن کانالها

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

امنیت SSH

نسخه های مختلف SSH دارای مشکلات امنیتی خاص خود است ، گرچه تنظیمات فعلی از SSH-2 و OpenSSH بسیار امن تر از SSH-1 در نظر گرفته می شوند.

SSH-1

SSH-1 عموماً دارای نقص و دارای طیف وسیعی از آسیب پذیری های مختلف است. اینها شامل اشکال در SSH 1.5 است که به کاربران غیرمجاز اجازه می دهد تا محتوای موجود در جریان داده SSH را وارد کنند. این حمله از حداقل محافظت از یکپارچگی داده های الگوریتم CRC-32 استفاده کرد.

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

همچنین یک آسیب پذیری وجود دارد که به دشمنان اجازه می دهد تا آخرین جلسه را در یک جلسه که از رمزگذاری IDEA استفاده می کند ، تغییر دهند ، همچنین یک سرور به خطر بیافتد که پروسه احراز هویت مشتری را به سرور دیگری منتقل کند..

به دلیل این مسائل امنیتی ، به جای آن باید از SSH-2 استفاده شود. برای حفظ امنیت اجرای خود ، شما نیز باید مذاکره مجدد با SSH-1 را غیرفعال کنید, زیرا حملات می توانند از این مزیت استفاده کنند تا به داده های شما از طریق سطح ضعیف ترین محافظت SSH-1 دسترسی پیدا کنند.

SSH-2

SSH-2 در برابر حمله نظری در برابر حالت پیش فرض رمزگذاری آن ، CBC آسیب پذیر است. این اجازه می دهد تا حمله کننده تا 32 بیت از متن ساده را از یک بلوک رمزگذاری شده بازیابی کند. این امر می تواند با استفاده از حالت Counter (CTR) کاهش یابد و به جای آن رمزنگاری بلوک را به رمزنگاری جریان تبدیل کند..

در پایان سال 2014 ، Der Spiegel اسناد NSA را منتشر کرد که حاکی از آن است که NSA گاهی اوقات می تواند SSH را بشکند. این پاورپوینت NSA اعلام کرد که NSA می تواند “به طور بالقوه بازیابی نام کاربری و کلمه عبور“، اگرچه جزئیات بیشتری ارائه نشده است. مشخص نیست که آژانس برای این کار از چه روشی استفاده کرده است ، اما بعید به نظر می رسد که در مستندات داخلی خود در مورد قابلیت هایش دروغ بگوید..

در نشت Vault 7 [year] ، این موضوع آشکار شد CIA دو ابزار داشت که می تواند برای رهگیری و سرقت از ورود به سیستم ها و کلمات عبور SSH استفاده شود. BothanSpy کلاینت Windows Xshell را هدف قرار داد ، در حالی که Gyrfalcon در برابر توزیع OpenSSH در تعدادی از توزیعهای مختلف لینوکس مورد استفاده قرار گرفت..

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

علیرغم این حملات ، SSH-2 در بیشتر مواقع ایمن تلقی می شود ، تا زمانی که به طور مناسب اجرا شود. اهداف با ارزش بالا یا افرادی که از پیاده سازی های قدیمی یا ضعیف استفاده می کنند باید گزینه های دیگری را در نظر بگیرند.

OpenSSH

در نسخه OpenSSH 2, حمله ای کشف شد که از ضعف در بسته باینری SSH استفاده کرد. این حمله به محققان دانشگاه لندن اجازه داد 14 قطعه متن ساده را از یک بلوک رمزگذاری شده بازیابی کنند. این کار در نسخه 5.2 با استفاده از پروتکل خواندن کلیه طول بسته نامعتبر یا کد احراز هویت پیام ، به جای پایان دادن به اتصال ، کاهش یافت..

در نسخه های 6.8 و 6.9 از لینوکس می توان برای اجرای دستورات دلخواه در پایانه های سایر کاربران استفاده کرد. این امر از طریق یک آسیب پذیری افزایش سرعت انجام می شود که به مهاجمان امکان می دهد شخصیت هایی با کنترل ورودی / خروجی TIOCSTI تزریق کنند..

آیا SSH امن است?

در حالی که ممکن است به نظر برسد SSH دارای مشکلات امنیتی زیادی است, این نسبتی استy طبیعی است که تعدادی از آسیب پذیری ها را در پیاده سازی های مختلف پروتکل مشاهده کنید. این بدان معنا نیست که پروتکل SSH ناامن است. در عوض ، فقط به این معنی است باید به درستی اجرا شود.

تا زمانی که از هر کدام استفاده می کنید SSH-2 یا OpenSSH و به روشی تنظیم شده است که برای استفاده شما مناسب است ، شما باید در محافظتی که SSH اتصال شما را تأمین می کند ، اطمینان داشته باشید.. به همین دلیل است که هنوز هم چنین پروتکل اغلب استفاده می شود ، به ویژه برای دسترسی از راه دور و اهداف تونل زنی.

همچنین ببینید: انواع رمزنگاری رایج توضیح داده شده است

پیش زمینه فناوری شبکه سایبر توسط TheDigitalArtist تحت مجوز CC0