راه‌اندازی بک‌اند Node.js روی اوبونتو؛ از SSH تا HTTPS

هدف امروز نصب بک‌اند نیست؛ می‌خواهیم مطمئن شویم به میزبان درست، با حساب درست و راه ورود قابل اتکا وصل شده‌ایم. بسیاری از خطاهای خطرناک از اجرای یک دستور صحیح در محیط غلط آغاز می‌شوند. یک پنجرهٔ PowerShell محلی و یک نشست Bash روی اوبونتو می‌توانند ظاهری شبیه داشته باشند، اما sudo و مسیر /etc متعلق به میزبان لینوکسی‌اند. در این درس هر بلوک می‌گوید کجا اجرا می‌شود. تنها روی ماشین تازهٔ آزمایشگاهی Ubuntu Server 24.04 LTS ادامه دهید. اگر روی ماشین سرویس یا دادهٔ واقعی وجود دارد، ابتدا محیط مستقلی بسازید؛ این دستورها برنامهٔ نگهداری یک سرور اشتراکی نیستند.

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

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

مرحلهٔ اول را در Windows PowerShell اجرا کنید. ابتدا وجود فرمان ssh را ببینید، سپس به‌جای نام و نشانی نمونه، حساب و IP ماشین خودتان را بنویسید. 203.0.113.10 نشانی مستنداتی است و labadmin هم حساب نمونه است. اگر ارائه‌دهنده کاربر ubuntu یا نام دیگری داده، همان حساب صحیح را استفاده کنید. اگر پورت SSH شما ۲۲ نیست، مقدار گزینهٔ کوچک p را مطابق تنظیم واقعی میزبان تغییر دهید. این دستور پورت سرور را عوض نمی‌کند؛ فقط به کلاینت می‌گوید کجا وصل شود. رمز را در خود فرمان ننویسید؛ اگر سرور آن روش را می‌پذیرد، کلاینت در ورودی تعاملی درخواستش می‌کند.

Get-Command ssh
ssh -p 22 labadmin@203.0.113.10

اگر ssh پیدا نشد، قابلیت OpenSSH Client ویندوز را از تنظیمات Optional Features و راهنمای رسمی Microsoft بررسی کنید؛ نسخهٔ ناشناس از کانال تصادفی نصب نکنید. اگر اتصال timeout شد، نخست نشانی، پورت، روشن‌بودن ماشین و قواعد شبکهٔ ارائه‌دهنده را بررسی کنید. اگر Permission denied گرفتید، اتصال شبکه ممکن است برقرار شده باشد ولی روش احراز هویت یا نام کاربر پذیرفته نشده است. اگر هشدار تغییر کلید میزبان دیدید، توقف کنید و علت را از کنسول مستقل بررسی کنید؛ ممکن است ماشین بازسازی شده باشد یا به مقصد دیگری رسیده باشید. پاک‌کردن فوری known_hosts و پذیرش دوباره، بررسی هویت محسوب نمی‌شود.

برای مقایسهٔ اثرانگشت در کنسول مستقل اوبونتو، مدیر ماشین می‌تواند خروجی ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub را بخواند. کلید عمومی و نام الگوریتم باید با همان پیشنهادی که کلاینت نشان می‌دهد مقایسه شوند؛ اگر الگوریتم دیگری مذاکره شد، اثرانگشت همان کلید لازم است. پس از تطبیق معتبر، تأیید کلید در کلاینت باعث می‌شود اتصال‌های بعدی تغییر غیرمنتظره را آشکار کنند. هیچ کلید خصوصی میزبان یا کاربر را در چت، تیکت عمومی یا متن درس وارد نکنید. برای مرور رابط کلاینت و روش تشخیص مقصد، درس SSH مقدماتی و درس پیکربندی پیشرفتهٔ SSH دو مرجع مکمل‌اند.
اتصال SSH مقدماتی: https://www.darsavand.com/courses/linux-server-from-zero?lesson=80424eae-c67f-4189-977c-4163b6ac7ca9
بازبینی پیکربندی SSH: https://www.darsavand.com/courses/linux-advanced-administration?lesson=f470f44b-e6d1-4532-b15a-bed85b0d4f8e

داخل سرور هستید؛ هویت، نسخه و مجوز را بخوانید

پس از ورود موفق، prompt معمولاً نام کاربر و میزبان را نشان می‌دهد، اما ظاهر prompt می‌تواند سفارشی باشد. مرحلهٔ دوم را در همان نشست اوبونتو اجرا کنید تا شواهد واقعی بگیرید. whoami نام کاربری مؤثر را نشان می‌دهد، hostname نام میزبان است و pwd پوشهٔ کاری فعلی را گزارش می‌کند. os-release شناسنامهٔ فضای کاربر سیستم‌عامل است؛ نسخهٔ هسته به‌تنهایی نام و نسخهٔ توزیع را ثابت نمی‌کند. dpkg معماری بسته‌های نصب‌شده را می‌گوید و در درس نصب Node آن را به معماری باینری مناسب نگاشت می‌کنیم. این دستورها چیزی را تغییر نمی‌دهند؛ خروجی را در شناسنامهٔ آزمایشگاه خود ثبت کنید.

whoami
hostname
pwd
cat /etc/os-release
dpkg --print-architecture
id
sudo -v

در os-release انتظار داریم ID مربوط به ubuntu و VERSION_ID برابر 24.04 باشد. اگر چیز دیگری دیدید، فرض‌های این مسیر را بدون بررسی به آن منتقل نکنید. خروجی id گروه‌ها را نشان می‌دهد و sudo -v امکان استفادهٔ مجاز از sudo را می‌سنجد؛ ممکن است رمز همان حساب را بخواهد. sudo یعنی اجرای یک فرمان با هویت و امتیاز مجاز دیگر، نه اینکه هر مشکل فایل را باید با آن حل کرد. اگر حساب اجازه ندارد، از مسیر مدیریت خود ماشین دسترسی درست فراهم کنید. از روی خطای مجوز به تغییر گستردهٔ chmod یا حذف مالکیت فایل‌ها نرسید؛ ابتدا روشن کنید کدام حساب باید چه کاری انجام دهد.

سه نقش را از همین جا جدا کنید. حساب مدیریتی انسان برای نصب بسته و تغییر تنظیمات دارای sudo است؛ حساب root بیشترین امتیاز سیستم را دارد؛ حساب سرویس بعداً فقط برنامه را اجرا می‌کند و مجوز ورود تعاملی و sudo نخواهد داشت. نام حساب سرویس این دوره darsnode است و ایجاد آن در فصل سرویس انجام می‌شود. آن را به گروه sudo اضافه نمی‌کنیم. اگر ارائه‌دهنده فقط ورود اولیهٔ root داده، در کنسول همان ماشین یک حساب مدیریتی معمولی بسازید و راه ورود مستقل آن را آزمایش کنید؛ قبل از تأیید ورود دوم، راه فعلی را نبندید. root بودن برای نخستین آماده‌سازی، توجیهی برای اجرای روزمرهٔ بک‌اند با root نیست.

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

adduser labadmin
usermod -aG sudo labadmin

پس از آماده‌شدن روش ورود، یک PowerShell دوم باز کنید و با حساب جدید به همان IP و پورت وصل شوید. در نشست دوم whoami و sudo -v را بررسی کنید. تنها پس از موفقیت این آزمون می‌توانید از نشست root خارج شوید؛ تغییر تنظیمات SSH یا حذف راه ورود اولیه در این درس لازم نیست. اگر کلید عمومی نصب می‌کنید، فقط فایل با پسوند pub برای سمت سرور است؛ کلید خصوصی روی دستگاه صاحب کلید می‌ماند. راهنمای عمومی Ubuntu جزئیات ایجاد کاربر و مجوزها را توضیح می‌دهد. اجرای کورکورانهٔ فرمان بازنویسی authorized_keys ممکن است کلیدهای لازم دیگر را حذف کند؛ برای همین در این شاخه، جایگزینی خودکار فایل موجود پیشنهاد نمی‌کنیم.

بسته، مخزن و به‌روزرسانی را درست معنا کنیم

بسته مجموعه‌ای مدیریت‌شده از فایل‌ها و اطلاعات نصب یک نرم‌افزار است. مخزن محلی نیست که هر فایل اینترنتی در آن قابل اعتماد شود؛ نشانی و امضای مخزن و سیاست توزیع در زنجیرهٔ اعتماد اهمیت دارد. APT ابزار اوبونتو برای دریافت اطلاعات مخزن، حل وابستگی و نصب بسته است. apt update فقط فهرست اطلاعات بسته‌ها را تازه می‌کند و به معنی ارتقای همهٔ نرم‌افزارها نیست. apt list --upgradable فهرست موارد قابل ارتقا را نشان می‌دهد. پیش از تغییر، نام بسته و اثر آن بر سرویس‌های فعال را می‌خوانیم. روی ماشین آزمایشی تازه نیز اگر فهرست مخزن با خطای امضا یا TLS مواجه شد، نصب را با گزینه‌های غیرفعال‌کردن بررسی امنیت ادامه نمی‌دهیم.

مرحلهٔ سوم، ابتدا فضای آزاد و زمان میزبان را مشاهده کنید؛ کمبود دیسک می‌تواند استخراج Node و نوشتن لاگ را متوقف کند و زمان غلط می‌تواند در اعتبارسنجی گواهی اختلال ایجاد کند. سپس فهرست مخزن را تازه و ابزارهای کوچک مورد نیاز را نصب کنید. ca-certificates مجموعهٔ گواهی‌های مرجع، curl کلاینت انتقال داده، و xz-utils ابزار کار با بایگانی xz است. نصب این سه ابزار، نصب Node یا Nginx نیست. گزینهٔ y را عمداً نگذاشته‌ایم تا پیش از تأیید، تغییرات پیشنهادی APT را ببینید. در این تمرین از sudo برای مدیریت بسته استفاده می‌کنیم، اما برنامهٔ جاوااسکریپت هنوز اجرا نمی‌شود.

df -h /
timedatectl status
sudo apt update
apt list --upgradable
sudo apt install ca-certificates curl xz-utils
curl --version
xz --version

اگر APT به‌دلیل قفل مدیریت بسته متوقف شد، ببینید به‌روزرسانی قانونی دیگری در حال اجراست؛ فایل قفل را کورکورانه حذف نکنید. اگر دامنهٔ مخزن resolve نمی‌شود، مسئله می‌تواند DNS باشد، نه نیاز به نصب مجدد Node. اگر کمبود فضا گزارش شد، ابتدا مصرف را بررسی و روی ماشین آزمایشی ظرفیت مناسب فراهم کنید؛ فرمان پاک‌کردن گستردهٔ مسیرهای سیستمی راه‌حل آموزشی این دوره نیست. به‌روزرسانی امنیتی سیستم را طبق سیاست نگهداری و راهنمای Ubuntu برنامه‌ریزی کنید. ارتقای همهٔ بسته‌ها و reboot ممکن است سرویس و اتصال را قطع کند؛ قبل از آن وضعیت، راه کنسول و زمان مجاز را مشخص کنید. در این مسیر، reboot ناگهانی شرط پنهان نصب قرار داده نشده است.

دفترچهٔ مشاهده و تمرین با پاسخ

اکنون برگهٔ آزمایشگاه را تکمیل کنید: نام محیط، حساب مدیریتی، نسخهٔ اوبونتو، معماری، راه ورود و نتیجهٔ نصب ابزارها. این گزارش با اطلاعات برنامه فرق دارد؛ یک پاسخ #json از API هنوز تولید نشده است. در مراحل بعد وقتی #throw-error یا مسیر #try-catch را در کد می‌بینید، آن‌ها را با شکست SSH یا APT یکی نگیرید. اعتبارسنجی مرز داده در #validation-contracts به ورودی برنامه مربوط است؛ اعتبارسنجی امروز به هویت میزبان، نسخه و پیش‌نیاز عملیاتی مربوط می‌شود. همین تفکیک کمک می‌کند یک خطا را به جای درست ببرید. برای تقویت دلیل استفاده از sudo و رفتار APT، دو درس قبلی زیر را مرور کنید.
مجوزها و sudo: https://www.darsavand.com/courses/linux-server-from-zero?lesson=a6cafdad-8b05-44a8-bfc6-f7ba647ee095
مدیریت بسته‌ها: https://www.darsavand.com/courses/linux-server-from-zero?lesson=b1ef0d5b-0ced-4b03-9ca9-78de906da105

تمرین اول: اتصال برقرار است، whoami مقدار root می‌دهد و برنامه‌نویس می‌گوید «برای جلوگیری از خطای دسترسی، همه چیز را همین‌طور اجرا می‌کنم». پاسخ: root فقط یک نقش موقت مدیریتی است؛ راه ورود حساب معمولی را آماده و آزمایش می‌کنیم و اجرای برنامه را بعداً به حساب محدود می‌سپاریم. تمرین دوم: ssh نام کاربر را رد می‌کند ولی ping پاسخ می‌دهد. ping اثبات نمی‌کند حساب یا کلید مجاز است؛ روش ورود و پیام SSH را بررسی کنید. تمرین سوم: apt update موفق است ولی apt list موارد زیادی نشان می‌دهد. این تناقض نیست؛ فهرست مخزن تازه شده و هنوز ارتقا انجام نشده است. برای هر پاسخ، مشاهدهٔ پشتیبان را هم بنویسید.

معیار عبور، ورود معتبر به حساب معمولی، تأیید Ubuntu 24.04 و معماری پشتیبانی‌شده، دسترسی sudo مجاز، فضای کافی و اجرای موفق curl و xz است. اگر یکی از این شرط‌ها برقرار نیست، نصب Node را شروع نکنید؛ متن خطا و مرحلهٔ شکست را ثبت کنید. هیچ گزارشی شامل رمز، کلید خصوصی یا خروجی کامل متغیرهای محیطی حساس نباشد. در درس بعد یک پوشهٔ دانلود مستقل در خانهٔ همین حساب می‌سازیم و باینری رسمی Node را در آن بررسی می‌کنیم. با پایان این درس هنوز فایروال، Nginx، سرویس برنامه یا تنظیم احراز هویت SSH را تغییر نداده‌ایم؛ پیش‌نیازهای مسیر بعدی اکنون قابل اثبات‌اند.

منابع رسمی انگلیسی:
Ubuntu OpenSSH server: https://ubuntu.com/server/docs/how-to/security/openssh-server/
Ubuntu user management: https://ubuntu.com/server/docs/how-to/security/user-management/
Ubuntu package management: https://ubuntu.com/server/docs/how-to/software/package-management/
Microsoft OpenSSH overview: https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh-overview
OpenSSH ssh manual: https://man.openbsd.org/ssh
Ubuntu release cycle: https://ubuntu.com/about/release-cycle

تألیف و سناریوهای اختصاصی: تحریریه درس‌آوند. فرمان‌های مدیریتی برای ماشین آزمایشی مستقل‌اند؛ نتیجهٔ هر مرحله باید پیش از ادامه بررسی شود.