کنترل چراغ از راه شبکه؛ SSH روی دستگاه کوچک چه می‌کند؟
کابل شبکه داده را می‌رساند و SSH از ارتباط فرمان محافظت می‌کند. با مثال چراغ کم‌ولتاژ می‌بینیم چرا دریافت فرمان، اجازهٔ کاربر و روشن‌شدن واقعی یکی نیستند.
فهرست مطالب
برای کنترل یک چراغ از راه کابل شبکه، دستگاه باید پیام را دریافت کند، اجازهٔ فرستنده را بررسی کند و فرمان را به تغییر خروجی تبدیل کند. SSH روشی برای محافظت از همین ارتباط فرمان است. داشتن SSH به معنی داشتن یک رایانهٔ کامل نیست؛ یک دستگاه کوچک هم می‌تواند فقط چند فرمان مشخص را اجرا کند.
مثال این درس یک چراغ کم‌ولتاژ روی میز آزمایش است. می‌خواهیم کاربر مجاز از رایانه فرمان روشن یا خاموش بدهد و وضعیت درخواستی را بخواند. روشن‌شدن واقعی چراغ، دریافت پیام و مجازبودن کاربر سه سؤال جدا هستند؛ مسیر را از همین تفاوت دنبال می‌کنیم.
داخل این دستگاه کوچک چه چیزهایی لازم است؟
برد، صفحه‌ای است که قطعات الکترونیکی روی آن به هم وصل می‌شوند. میکروکنترلر یکی از این قطعات است: یک رایانهٔ کوچک برای اجرای برنامه و کنترل ورودی و خروجی. برنامه‌ای که روی آن می‌ریزیم مشخص می‌کند پس از دریافت فرمان چه اتفاقی بیفتد. همهٔ میکروکنترلرها امکانات و حافظهٔ یکسان ندارند.
اترنت یا Ethernet روش رایج ارتباط داده روی شبکهٔ کابلی است. بخش اتصال شبکه، تغییرهای الکتریکی کابل را دریافت و ارسال می‌کند؛ سوکت کابل به‌تنهایی این کار را انجام نمی‌دهد. این بخش ممکن است داخل قطعهٔ اصلی باشد یا در یک تراشه یا ماژول جدا قرار بگیرد. ماژول، مجموعه‌ای آماده از چند قطعه برای انجام بخشی از کار است.
برنامه‌های شبکه هم لازم‌اند. IP به پیدا کردن مقصد در شبکه کمک می‌کند و TCP جریان مرتب و قابل اطمینان داده را تا برنامهٔ طرف مقابل فراهم می‌کند؛ این به معنی روشن‌شدن بار نیست. بعضی کنترلرهای شبکه بخشی از این کارها را انجام می‌دهند و در بعضی طراحی‌ها، برنامهٔ میکروکنترلر آن‌ها را اجرا می‌کند. برای نمونه، مستندات WIZnet یک کنترلر دارای امکانات شبکه را معرفی می‌کند؛ وجود این امکانات به‌تنهایی سرور SSH نمی‌سازد.
SSH کجای مسیر قرار می‌گیرد؟
SSH نام کوتاه Secure Shell و یک مجموعه قواعد برای ارتباط محافظت‌شده از راه شبکه است. در این مثال، برنامهٔ رایانه «مشتری» و برنامهٔ منتظر اتصال روی دستگاه «سرور» است. سرور در اینجا یک نقش نرم‌افزاری است؛ قرار نیست حتماً یک رایانهٔ بزرگ باشد. کابل می‌تواند از یک سوئیچ شبکه بگذرد؛ سوئیچ وسیله‌ای است که اتصال چند دستگاه را در شبکه به هم مرتبط می‌کند.
یک اتصال SSH درست باید به مشتری امکان بررسی هویت سرور را بدهد، محتوای ارتباط را در مسیر پنهان کند و تغییر غیرمجاز داده را تشخیص دهد. سپس سرور هویت کاربر را بررسی می‌کند. در برنامهٔ کاربردی هنوز باید تعیین شود آن کاربر اجازهٔ کدام فرمان را دارد. رمزگذاری جای این تصمیم را نمی‌گیرد. سند معماری SSH این بخش‌ها را از هم جدا می‌کند.
«کلید» در این بحث داده‌ای است که روش‌های رمزنگاری از آن استفاده می‌کنند. برای معرفی سرور، مشتری معمولاً اثرانگشت کلید میزبان را می‌بیند؛ اثرانگشت، نمایش کوتاه‌شده‌ای برای مقایسهٔ کلید است. آن را با مقدار معتبر از راهی مستقل مقایسه کنید. تأیید بی‌بررسی اولین اتصال یا نادیده‌گرفتن هشدار تغییر کلید، می‌تواند شما را به دستگاه دیگری وصل کند. روش معتبر تأیید اولیه و نگهداری کلید باید در محصول مشخص باشد؛ راهنمای OpenSSH رفتار مشتری را توضیح می‌دهد. برای تفاوت کلید، هویت دستگاه و محل نگهداری آن، درس هویت دستگاه و کلیدها را ببینید.
مثال چراغ: از فرمان on تا وضعیت درخواستی
فرض کنیم برنامهٔ این دستگاه فقط سه فرمان دارد: on برای درخواست روشن، off برای درخواست خاموش و status برای خواندن آخرین درخواست ثبت‌شده. این‌ها فرمان‌های برنامهٔ فرضی ما هستند؛ هر دستگاه SSH چنین فرمان‌هایی ندارد. اتصال به دستگاه کوچک الزاماً به معنی دسترسی به همهٔ فرمان‌های لینوکس یا یک محیط عمومی اجرای برنامه نیست.
توالی فرضی کار را با چراغ خاموش شروع می‌کنیم:
| رویداد | تصمیم برنامه | چه چیزی ثابت شده است؟ |
|---|---|---|
| کاربر نامعتبر on می‌فرستد | رد؛ درخواست خروجی تغییر نمی‌کند | این کاربر اجازهٔ استفاده از فرمان را نگرفته است. |
| کاربر مجاز on می‌فرستد | درخواست خروجی روشن ثبت می‌شود | برنامه فرمان را پذیرفته است. |
| همان کاربر دوباره on می‌فرستد | درخواست همچنان روشن می‌ماند | تکرار درخواست، وضعیت را معکوس نکرده است. |
| کاربر status می‌خواند | آخرین درخواست: روشن | وضعیت درخواستی معلوم است، نه الزاماً روشنایی واقعی چراغ. |
چرا این تفاوت مهم است؟ ممکن است برنامه خروجی را فعال کرده باشد، اما سیم چراغ قطع باشد یا بخش قدرت کار نکند. برای تأیید روشن‌شدن واقعی، بازخورد جدا لازم است؛ مثلاً اندازه‌گیری جریان یا روشنایی با روش مناسب. چنین بازخوردی در مدل این درس وجود ندارد.
پایهٔ خروجی میکروکنترلر برای تأمین هر باری مناسب نیست. چراغ نشانگر داخلی برد را از یک چراغ بیرونی جدا بدانید؛ بار بیرونی ممکن است به مدار راه‌انداز و منبع تغذیهٔ جدا نیاز داشته باشد. حتی کابل Ethernet هم به‌خودی‌خود جای تغذیهٔ دستگاه نیست؛ دریافت توان از آن به طراحی مناسب دو طرف نیاز دارد. مثال این صفحه فقط کم‌ولتاژ است و هیچ سیم‌کشی برق شهر ندارد.
اگر پاسخ نرسید، دوباره چه فرمانی بفرستیم؟
فرض کنید on اجرا شده، اما پیش از رسیدن پاسخ اتصال قطع شود. نرسیدن پاسخ به معنی اجرا‌نشدن فرمان نیست. اگر فرمان «وضعیت را برعکس کن» باشد، تکرارش می‌تواند چراغ روشن را خاموش کند. در مقابل، تکرار درخواست «روشن باش» در مدل ما همان وضعیت روشن را نگه می‌دارد. این ویژگی برای طراحی فرمان‌های قابل تکرار مفید است.
بااین‌حال، ارسال دوباره همیشه راه‌حل عمومی نیست. برای کاری مثل حرکت‌دادن موتور به اندازهٔ مشخص، اجرای دوباره می‌تواند اثر اضافه ایجاد کند. برنامه باید قواعد تشخیص درخواست، گزارش نتیجه و رفتار پس از قطع ارتباط را متناسب با کار تعریف کند. SSH از مسیر ارتباط محافظت می‌کند؛ معنی «فقط یک بار انجام بده» را برای برنامهٔ شما طراحی نمی‌کند.
یک مثال کوچک از حجم داده هم همین تفاوت لایه‌ها را نشان می‌دهد: متن on به‌همراه یک نویسهٔ پایان خط، در نمایش ASCII سه بایت است. هر بایت از هشت بیت صفر یا یک تشکیل می‌شود. این سه بایت، کل ترافیک شبکه نیست؛ اطلاعات همراه TCP/IP، بسته‌بندی SSH و برقراری اتصال هم وجود دارند. از کوتاه‌بودن فرمان نمی‌توان مصرف حافظه یا زمان پاسخ دستگاه را نتیجه گرفت.
چرا SSH دستگاه را به رایانهٔ کامل تبدیل نمی‌کند؟
سیستم‌عامل برنامه‌ای است که کارهایی مثل اجرای برنامه‌های دیگر و مدیریت منابع را سامان می‌دهد. بعضی دستگاه‌های کوچک بدون سیستم‌عامل عمومی کار می‌کنند و بعضی یک سیستم‌عامل مخصوص کارهای محدود دارند. ارائهٔ سرویس SSH فقط نشان می‌دهد برنامه‌ای آن پروتکل و امکانات مشخصی را اجرا می‌کند؛ وجود فایل‌سیستم، نصب برنامه یا همهٔ قابلیت‌های یک رایانهٔ رومیزی را ثابت نمی‌کند.
حافظهٔ موقت برای داده‌های در حال پردازش و حافظهٔ نگهداری برنامه هم محدودند. برقراری اتصال و پردازش رمزنگاری می‌توانند با کارهای دیگر دستگاه رقابت کنند. زمان پاسخ، تعداد اتصال هم‌زمان و رفتار هنگام قطع کابل باید با همان برنامه و سخت‌افزار بررسی شوند. معرفی میکروکنترلرهای Raspberry Pi نمونه‌ای از این دستهٔ قطعات را توضیح می‌دهد و راهنمای انتخاب میکروکنترلر معیارهای انتخاب را ادامه می‌دهد.
نمونهٔ SSH.RP چه چیزی را نشان می‌دهد؟
پروژهٔ عمومی SSH.RP در نسخهٔ بررسی‌شده اجرای سرور SSHv2 روی سخت‌افزار کوچک با اتصال کابلی را نشان می‌دهد و فرمان‌هایی برای چراغ نشانگر دارد. سازنده آن را نمونهٔ نمایشی و ممیزی‌نشده از نظر امنیت معرفی کرده است. محدودیت یک نشست و نگهداری کلید در firmware نیز در مستنداتش آمده است؛ firmware همان برنامهٔ سطح دستگاه است. در همین نمونه، کار قواعد TCP/IP را نرم‌افزار میکروکنترلر انجام می‌دهد؛ داشتن قابلیت شبکه در یک تراشه به معنی استفادهٔ برنامه از همهٔ آن قابلیت‌ها نیست.
این پروژه شاهد امکان یک پیاده‌سازی مشخص است، نه تأیید امنیت یا کارایی هر برد مشابه. دسترسی فیزیکی به دستگاه یا حافظهٔ قابل خواندن ممکن است کلید محرمانه را در معرض دسترسی قرار دهد؛ محافظت از بسته‌های روی کابل، حافظهٔ دستگاه را خودکار محافظت نمی‌کند. رفتار یک نمونهٔ نمایشی را هم نباید به همهٔ پیاده‌سازی‌های SSH تعمیم داد. این درس، دستور ساخت یا تأیید محصول آن پروژه نیست.
تمرین اختیاری: منطق فرمان را بدون شبکه ببینید
فایل تمرین Python یک مدل آفلاین از همان سه فرمان است. اگر اجرای Python را بلد هستید، با Python 3.10 یا جدیدتر دستور زیر را اجرا کنید؛ کتابخانهٔ اضافه لازم ندارد:
python command_demo.pyفایل، درخواست روشن و تکرار آن را نشان می‌دهد و آزمون‌های منطق دسترسی و فرمان را اجرا می‌کند. این برنامه SSH، رمزگذاری، شبکه یا خروجی واقعی برد را پیاده نمی‌کند؛ نتیجهٔ آن فقط دربارهٔ منطق همین مدل است. برای فهم جدول بالا، اجرای فایل لازم نیست.
سه بررسی عملی پیش از اعتماد به کنترل از راه شبکه
- مقصد و اجازه: دستگاه درست را با روش معتبر بشناسید، ورود کاربر را بررسی کنید و فقط فرمان‌های لازم را به او بدهید. بسته‌بودن شبکهٔ کابلی جای این بررسی‌ها را نمی‌گیرد.
- نتیجه و خطا: دریافت فرمان، ثبت درخواست و اثر فیزیکی را جدا گزارش کنید. حالت روشن‌شدن اولیه، قطع کابل و گم‌شدن پاسخ باید معلوم باشد.
- توانایی و نگهداری: حافظه، زمان پاسخ، به‌روزرسانی و حفاظت فیزیکی دستگاه را با نیاز واقعی بسنجید. بازکردن دسترسی از اینترنت، تصمیمی جدا از کارکردن نمونه در شبکهٔ محلی است.
برای ادامه، مسیر یادگیری سیستم‌های امبدد نقش برنامه، ورودی و خروجی و آزمون را کنار هم قرار می‌دهد. مثال چراغ این صفحه فرضی است؛ برنامهٔ عمومی SSH.RP برای این درس کامپایل یا روی سخت‌افزار آزمایش نشده است.
پرسش و پاسخ مقاله
سوال فنی خود را مطرح کنید
پرسش‌ها و پاسخ‌ها پس از بررسی مدیر منتشر می‌شوند. نویسنده، پیش‌نویس در انتظار بررسی را می‌بیند.
هنوز پرسش تاییدشده‌ای برای این مقاله ثبت نشده است.