نحوه شخصی‌سازی اتصال به سرور مجازی لینوکس (VPS) با SSH

مقدمه

SSH یا Secure Shell، رایج‌ترین روش برای اتصال به سرورهای لینوکس به منظور مدیریت از راه دور است. اگرچه اتصال به یک سرور مجازی لینوکس، از طریق خط فرمان نسبتاً ساده است، اما برای اتصال به چندین سیستم از راه دور، بهینه‌سازی‌های متعددی برای راحت‌تر کردن جریان کار، وجود دارد.

OpenSSH، به عنوان رایج‌ترین کلاینت SSH خط فرمان در بیشتر سیستم‌ها، به شما این امکان را می‌دهد که گزینه‌های اتصال شخصی‌سازی شده‌ای را ایجاد کنید. این گزینه‌ها می‌توانند در یک configuration file ذخیره شوند که برای هر سرور مجازی، تنظیمات و optionهای متفاوتی خواهد داشت. configuration file می‌تواند به ما کمک کند تا گزینه‌های مختلف اتصال که برای هر host استفاده می‌کنیم، تفکیک و سازمان‌دهی شده باقی بماند و نیازی به وارد کردن فلگ‌ها و optionهای زیاد در هر بار اتصال به سرور مجازی، نباشد.

در این مقاله، ساختار configuration file کلاینت SSH را بررسی خواهیم کرد و برخی از گزینه‌های رایج را توضیح خواهیم داد.

پیش‌نیازها

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

• سرور مجازی یا VPS چیست؟ معرفی انواع و کاربردهای سرور مجازی
• SSH چیست؟ + نحوه استفاده از SSH برای اتصال به سرور مجازی (VPS)

ساختار فایل پیکربندی SSH و الگوریتم تفسیر آن

هر کاربر در سیستم شما، می‌تواند فایل پیکربندی SSH خود را در home directory خودش، نگه‌داری کند. این فایل‌ها می‌توانند شامل هر گزینه‌ای باشند که شما در خط فرمان برای مشخص کردن پارامترهای اتصال (به سرور) استفاده می‌کنید. همیشه امکان بازنویسی مقادیر تعریف‌شده در فایل پیکربندی، هنگام اتصال به سرور مجازی، با اضافه کردن فلگ‌های اضافی به دستور ssh، وجود دارد.

موقعیت Config File کلاینت SSH

فایل پیکربندی (Config File) سمت کلاینت در مسیر ~/.ssh/config قرار دارد (در نظر داشته باشید که ~ یک میان‌بر عمومی به home directory شما است). اغلب، فایل ~/.ssh/config به طور پیش‌فرض ایجاد نمی‌شود، بنابراین ممکن است نیاز باشد که خودتان آن را ایجاد کنید. دستور touch این فایل را در صورتی که وجود نداشته باشد، ایجاد می‌کند (و اگر فایل موجود باشد، زمان آخرین تغییر آن را به‌روز می‌کند):

touch ~/.ssh/config

ساختار فایل پیکربندی (Configuration File)

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

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

معمولاً با هدف سازمان‌دهی و خوانایی بیشتر، گزینه‌هایی که برای هر host تنظیم می‌شوند، تورفتگی دارند. این یک الزام نیست، اما یک قرارداد مفید است که امکان تفسیر سریع را فراهم می‌کند. فایل زیر، نمونه‌ای از محتوای ~/.ssh/config است:

Host firsthost
    Hostname your-server.com
    User username-to-connect-as
    IdentityFile /path/to/non/default/keys.pem

Host secondhost
    ANOTHER_OPTION custom_value

Host *host
    ANOTHER_OPTION custom_value

Host *
    CHANGE_DEFAULT custom_value

در قطعه کد فوق، چهار بخش (چهار هدر) داریم که بر اساس اینکه آیا host مورد نظر مطابقت دارد یا نه، در هر تلاشِ اتصال، بررسی خواهند شد.

الگوریتم تفسیر

مهم است که نحوه تفسیر فایل توسط SSH برای اعمال مقادیر پیکربندی را درک کنید. این امر هنگامی که از wildcardها و عبارت Host * استفاده می‌کنید، اهمیت زیادی دارد. SSH نام host ارائه‌شده در خط فرمان را با هر یک از هدرهای Host تطبیق خواهد داد. برای مثال، این تعریف را در فایل ~/.ssh/config نظر بگیرید:

Host devel
    HostName devel.example.com
    User tom

این host به ما این امکان را می‌دهد که با تایپ کردن دستور زیر در خط فرمان به عنوان tom@devel.example.com، به سرور مجازی، متصل شویم:

ssh devel

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

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

این نکته بسیار مهم است. SSH هر یک از بخش‌های Host که با نام host داده شده در خط فرمان مطابقت دارند را به ترتیب تفسیر خواهد کرد. در این فرایند، همیشه از اولین مقداری که برای هر گزینه داده شده استفاده می‌کند. هیچ‌گونه راهی برای لغو مقداری که قبلاً توسط بخش‌های مطابقت یافته قبلی داده شده، وجود ندارد.

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

بیایید دوباره به مثال بخش قبلی نگاه کنیم:

Host firsthost
    Hostname your-server.com
    User username-to-connect-as
    IdentityFile /path/to/non/default/keys.pem

Host secondhost
    ANOTHER_OPTION custom_value

Host *host
    ANOTHER_OPTION custom_value

Host *
    CHANGE_DEFAULT custom_value

در قطعه کد فوق، می‌بینیم که دو بخش اول با نام‌های hostها (یا نام‌های مستعار) تعریف شده‌اند، به این معنی که از هیچ wildcards (کاراکتر عمومی) استفاده نمی‌کنند. اگر با دستور ssh firsthost به سرور متصل شویم، اولین بخش ابتدا اعمال خواهد شد. این بخش مقادیر Hostname و User و IdentityFile را برای این اتصال تنظیم می‌کند.

سپس بخش دوم را بررسی می‌کند و می‌بیند که با آن تطابق ندارد و ادامه می‌دهد. سپس بخش سوم را پیدا می‌کند و می‌بیند که تطابق دارد. آن‌گاه گزینه ANOTHER_OPTION را بررسی می‌کند تا ببیند آیا قبلاً مقداری از بخش‌های قبلی برای آن وجود دارد یا خیر. با پیدا نکردن مقدار قبلی، مقدار جدید را از این بخش اعمال می‌کند. سپس بخش آخر را تطبیق می‌دهد، زیرا تعریف Host * با هر اتصال تطابق دارد. از آنجا که برای گزینه CHANGE_DEFAULT مقداری از سایر بخش‌ها وجود ندارد، مقدار را از این بخش می‌گیرد. سپس اتصال با گزینه‌های جمع‌آوری شده از این فرایند برقرار می‌شود.

بیایید یک مثال دیگر بزنیم، با این فرض که از خط فرمان دستور ssh secondhost را وارد می‌کنیم.

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

سپس SSH به بخش سوم نگاه می‌کند و می‌بیند که wildcard با اتصال فعلی تطابق دارد. سپس بررسی می‌کند که آیا برای ANOTHER_OPTION مقداری از قبل وجود دارد یا خیر. چون این گزینه در بخش دوم تعریف شده بود که قبلاً تطبیق داده شده است، مقدار بخش سوم رد می‌شود و تأثیری ندارد.

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

گزینه‌های اتصال

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

اولین مواردی که پوشش می‌دهیم، تنظیمات حداقلی لازم برای اتصال به یک سرور مجازی راه دور است. به طور خاص، نام میزبان (نام سرور مجازی)، نام کاربری و پورتی که سرور SSH روی آن اجرا می‌شود.

برای اتصال به عنوان کاربر apollo به سروری مجازی به نام example.com که SSH خود را روی پورت 4567 اجرا می‌کند، می‌توانید دستور ssh را به صورت زیر اجرا کنید:

ssh -p 4567 apollo@example.com

با این حال، شما همچنین می‌توانید از نام‌های کامل گزینه‌ها همراه با فلگ -o استفاده کنید، به این صورت:

ssh -o "User=apollo" -o "Port=4567" -o "HostName=example.com"

برای تنظیم دستور فوق در فایل پیکربندی خود، باید یک نام هدر Host انتخاب کنید، مانند home:

Host home
    HostName example.com
    User apollo
    Port 4567

گزینه‌های رایج پیکربندی SSH

تا کنون، برخی از گزینه‌های لازم برای برقراری اتصال را بررسی کرده‌ایم. این گزینه‌ها شامل موارد زیر بودند:

• HostName: نام واقعی هاست (سرور مجازی) که باید برای برقراری اتصال استفاده شود. این گزینه هر نام مستعار تعریف‌شده در هدر Host را جایگزین می‌کند. این گزینه در صورتی که تعریف Host آدرس معتبر واقعی برای اتصال را مشخص کند، ضروری نیست.
• User: نام کاربری که باید برای اتصال استفاده شود.
• Port: پورتی که SSH در سرور مجازی، روی آن اجرا می‌شود. این گزینه فقط در صورتی ضروری است که SSH سرور مجازی بر روی پورت پیش‌فرض 22 اجرا نشود.

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

تنظیمات عمومی و موارد اتصال

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

LogLevel: این گزینه سطح جزئیات ثبت لاگ در سمت مشتری را تنظیم می‌کند. می‌توان از آن برای خاموش کردن لاگ‌گیری در شرایط خاص یا افزایش verbosity (جزئیات بیشتر) در زمان رفع اشکال استفاده کرد. از کمترین به بیشترین verbosity، سطوح عبارتند از: QUIET و FATAL و ERROR و INFO و VERBOSE و DEBUG1 و DEBUG2و DEBUG3.

StrictHostKeyChecking: این گزینه مشخص می‌کند که آیا SSH به طور خودکار سرورهای مجازی را به فایل ~/.ssh/known_hosts اضافه خواهد کرد یا خیر. به طور پیش‌فرض، این گزینه به حالت “ask” تنظیم می‌شود، یعنی اگر کلید سرور مجازی دریافتی از سرور ریموت با کلید موجود در فایل known_hosts تطابق نداشته باشد، به شما هشدار می‌دهد. اگر شما به طور مداوم به تعداد زیادی از سرورهای مجازی موقتی (مانند سرورهای تست) متصل می‌شوید، ممکن است بخواهید این گزینه را به “no” تغییر دهید. در این صورت، SSH به طور خودکار هر سرور مجازی را به فایل اضافه خواهد کرد. این می‌تواند پیامدهای امنیتی داشته باشد اگر سرورهای مجازی شناخته‌شده شما آدرس‌های خود را زمانی که نباید، تغییر دهند، بنابراین قبل از فعال‌سازی آن، با دقت فکر کنید.

VisualHostKey: این گزینه می‌تواند به SSH بگوید که هنگام اتصال نمایشی ASCII از کلید سرور مجازی ریموت نمایش دهد. فعال کردن این گزینه می‌تواند یک راه مفید برای آشنایی با کلید سرور مجازی شما باشد تا در صورتی که بخواهید در آینده از کامپیوتر دیگری به آن متصل شوید، آن را شناسایی کنید.

Compression: فعال کردن فشرده‌سازی می‌تواند برای اتصالات بسیار کند مفید باشد. بیشتر کاربران به این گزینه نیاز نخواهند داشت.

با در نظر گرفتن تنظیمات پیکربندی بالا، می‌توانیم چند تغییر پیکربندی مفید ایجاد کنیم. برای مثال، اگر به صورت عجله‌ای، در حال ایجاد و حذف سرورهای مجازی باشیم، چیزی مانند این ممکن است مفید باشد:

Host home
    VisualHostKey yes

Host cloud*
    StrictHostKeyChecking no
    LogLevel QUIET

Host *
    StrictHostKeyChecking ask
    LogLevel INFO
    ServerAliveInterval 120

انتقال ارتباطات (Connection Forwarding)

یکی از استفاده‌های رایج SSH، انتقال ارتباطات است، که به اتصال محلی اجازه می‌دهد تا از طریق سرور مجازی ریموت، تونل شود، یا به ماشین ریموت اجازه می‌دهد تا از طریق ماشین محلی، تونل شود. این کار زمانی که باید به یک ماشین ریموت، پشت یک فایروال از طریق یک سرور “gateway” جداگانه متصل شوید؛ لازم است. SSH همچنین می‌تواند انتقال پویا را با استفاده از پروتکل‌هایی مانند SOCKS5 انجام دهد که شامل اطلاعات انتقال برای سرور مجازی ریموت است.

گزینه‌هایی که این رفتار را کنترل می‌کنند عبارتند از:

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

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

# This will allow us to use port 8080 on the local machine
# in order to access example.com at port 80 from the remote machine
Host local_to_remote
    LocalForward 8080 example.com:80

# This will allow us to offer access to internal.com at port 443
# to the remote machine through port 7777 on the other side
Host remote_to_local
    RemoteForward 7777 internal.com:443

تعیین کلیدها (Specifying Keys)

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

IdentityFile: این گزینه می‌تواند برای مشخص کردن مکان کلیدی که باید برای هر سرور به کار می‌رود، استفاده شود. به طور پیش‌فرض، SSH از کلیدهایی که در مسیر ~/.ssh قرار دارند استفاده می‌کند، اما اگر شما کلیدهایی برای هر سرور به صورت جداگانه اختصاص داده‌اید، می‌توانید از این گزینه برای مشخص کردن مسیر دقیق جایی که کلیدها ذخیره شده‌اند، استفاده کنید.

IdentitiesOnly: این گزینه می‌تواند برای مجبور کردن SSH به استفاده تنها از هویت‌هایی که در فایل پیکربندی مشخص شده‌اند، به کار رود. این ممکن است زمانی لازم باشد که یک عامل SSH (SSH agent) کلیدهای جایگزین در حافظه داشته باشد که برای سرور مجازی مورد نظر معتبر نیستند.

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

نتیجه‌گیری

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

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

همچنین بخوانید: سرور ابری چیست؟ نحوه عملکرد + معرفی بهترین سرور ابری