آموزش اتصال به سرور مجازی با SSH — از ویندوز، لینوکس و موبایل

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

SSH چیست و چرا مدیریت سرور بدون آن ممکن نیست؟

SSH (پوسته‌ی امن) یک کانال رمزنگاری‌شده بین کامپیوتر شما و سرور است؛ همه‌ی دستورها و خروجی‌ها داخل همین تونل جابه‌جا می‌شوند و برخلاف ابزارهای قدیمی مثل Telnet، هیچ‌چیز — نه رمز، نه داده — به‌صورت متن ساده روی شبکه نمی‌رود.

یک تفکیک کوچک اما مفید: SSH نام پروتکل است و OpenSSH نام رایج‌ترین پیاده‌سازی آن که روی تقریباً همه‌ی توزیع‌های لینوکس، مک و ویندوزهای امروزی اجرا می‌شود. پورت پیش‌فرضش هم ۲۲ است.

در اولین اتصال دقیقاً چه اتفاقی می‌افتد؟

هر اتصال SSH سه مرحله دارد. اول، دو طرف نسخه‌ی پروتکل خود را رد و بدل می‌کنند. دوم، تبادل کلید انجام می‌شود: کلاینت و سرور روی یک کلید رمزنگاری مشترک توافق می‌کنند و سرور در همین مرحله نتیجه را با «کلید میزبان» خودش امضا می‌کند؛ کلاینت آن کلید میزبان را با نسخه‌ی ذخیره‌شده در ~/.ssh/known_hosts مقایسه می‌کند و چون بار اول نسخه‌ای ذخیره نشده، همان پیام «authenticity of host» را می‌بینید. سوم، نوبت احراز هویت خود شماست — با رمز یا با کلید. خطاهای رایج SSH به همین سه مرحله برمی‌گردند و تشخیص اینکه خطا در کدام مرحله رخ داده، نصف مسیر عیب‌یابی است.

پیش از اولین اتصال چه چیزهایی لازم دارید؟

دقیقاً چهار چیز نیاز دارید: آی‌پی عمومی سرور، پورت SSH (پیش‌فرض ۲۲)، نام کاربری (روی سرور تازه معمولاً root) و یک راه احراز هویت که یا رمز است یا کلید. در پنل کاربری مهران هاست، آی‌پی و رمز اولیه‌ی root در صفحه‌ی همان سرور نمایش داده می‌شود.

پیش از آنکه SSH را متهم کنید، ببینید پورت SSH از سمت شما باز است یا نه. در لینوکس و مک:

nc -zv 203.0.113.10 22

Connection to 203.0.113.10 22 port [tcp/ssh] succeeded!

و در ویندوز، بدون نصب هیچ ابزاری، در PowerShell:

Test-NetConnection 203.0.113.10 -Port 22

ComputerName     : 203.0.113.10
RemoteAddress    : 203.0.113.10
RemotePort       : 22
InterfaceAlias   : Ethernet
SourceAddress    : 192.168.1.20
TcpTestSucceeded : True

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

اتصال به سرور مجازی با SSH از ویندوز

ویندوز ۱۱ و ویندوز ۱۰ (از بیلد ۱۸۰۹ به بعد) کلاینت OpenSSH را به‌صورت یک «قابلیت اختیاری» در خود دارند و روی بیشتر نصب‌ها از قبل فعال است؛ نیازی به PuTTY نیست. PowerShell یا Windows Terminal را باز کنید و بنویسید:

ssh root@203.0.113.10

به‌جای آی‌پی نمونه، آی‌پی سرور خودتان را بگذارید. خروجی اولین اتصال چنین است:

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:2xJ8h1Qm0kZ9Rr7vC4pLd6TyWnAe5BsUgXf3NqMoIkE.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '203.0.113.10' (ED25519) to the list of known hosts.
root@203.0.113.10's password:

این پیام طبیعی است — اثر انگشت کلید میزبان برای دفعات بعد ذخیره می‌شود. yes بزنید و رمز را وارد کنید. هنگام تایپ رمز هیچ کاراکتری، حتی ستاره، نمایش داده نمی‌شود؛ این عمدی است.

اگر دستور ssh شناخته نشد، وجود قابلیت را چک کنید و در صورت نبود از مسیر Settings › Optional Features گزینه‌ی OpenSSH Client را اضافه کنید:

Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*'

Name  : OpenSSH.Client~~~~0.0.1.0
State : NotPresent

PuTTY هم همچنان انتخاب خوبی است اگر ترجیح می‌دهید اتصال‌ها را در یک رابط گرافیکی ذخیره کنید. فقط حواستان باشد PuTTY کلیدهایش را در قالب اختصاصی .ppk نگه می‌دارد و برای استفاده از همان کلید در OpenSSH باید با PuTTYgen تبدیلش کنید.

اتصال از لینوکس و مک

ترمینال را باز کنید؛ دستور دقیقاً همان است:

ssh root@203.0.113.10

اگر پورت SSH سرور را عوض کرده‌اید (مثلاً به ۲۲۲۲)، با سوییچ -p مشخصش کنید:

ssh -p 2222 root@203.0.113.10

اگر روی سرور کاربر معمولی ساخته‌اید، به‌جای root نام همان کاربر را بگذارید: ssh ali@203.0.113.10. یک سوییچ دیگر را هم به خاطر بسپارید: -v. اضافه‌کردنش به هر دستور SSH مراحل اتصال را خط‌به‌خط چاپ می‌کند:

ssh -v root@203.0.113.10

debug1: Connecting to 203.0.113.10 [203.0.113.10] port 22.
debug1: Connection established.
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/ali/.ssh/id_ed25519 ED25519 SHA256:8Kd2...q4 explicit

همین چند خط می‌گوید اتصال TCP برقرار شده (پس فایروال مشکلی ندارد)، کدام کلید پیشنهاد شده، و سرور چه روش‌هایی را قبول دارد.

اتصال از گوشی موبایل

وقتی پشت سیستم نیستید و سایت از دسترس خارج شده، موبایل نجات‌دهنده است. در اندروید Termux (نصب از F-Droid یا گیت‌هاب — بیلد گوگل‌پلی آن متوقف شده و ناقص است؛ با pkg install openssh همان کلاینت استاندارد OpenSSH را می‌آورد)، ConnectBot یا Termius، و در آیفون Termius یا Blink Shell گزینه‌های محبوبی هستند.

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

اولین دقیقه پس از ورود: سرور را بشناسید

پرامپت root@srv1:~# جلوی چشمتان است. پیش از هر نصبی، سه دستور بزنید:

root@srv1:~# uptime
 09:41:02 up 7 min,  1 user,  load average: 0.02, 0.06, 0.02

root@srv1:~# free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       243Mi       3.3Gi       1.0Mi       311Mi       3.4Gi
Swap:             0B          0B          0B

root@srv1:~# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        39G  2.1G   35G   6% /

این سه خروجی به ترتیب بار سرور، رم آزاد و فضای باقی‌مانده‌ی دیسک را می‌گویند. روی سرور تازه باید بار نزدیک صفر و دیسک تقریباً خالی باشد؛ اگر غیر از این دیدید، چیزی از قبل در حال اجراست. قدم بعدی، به‌روزرسانی بسته‌هاست:

apt update && apt upgrade -y

روی خانواده‌ی RHEL (مثل AlmaLinux و Rocky) معادلش dnf upgrade -y است. این کار را همان روز اول انجام دهید: ایمیج‌های سیستم‌عامل معمولاً چند هفته‌ای از آخرین وصله‌های امنیتی عقب‌ترند و سروری که تازه آی‌پی عمومی گرفته، از دقیقه‌ی اول اسکن می‌شود. اگر با دستورهای پایه‌ی لینوکس راحت نیستید، فهرست دستورهای ضروری لینوکس را کنار دستتان باز نگه دارید.

کلید SSH: خداحافظی با رمز عبور

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

ساخت جفت کلید

ssh-keygen -t ed25519 -C "ali@laptop"

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/ali/.ssh/id_ed25519):
Enter passphrase for "/home/ali/.ssh/id_ed25519" (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/ali/.ssh/id_ed25519
Your public key has been saved in /home/ali/.ssh/id_ed25519.pub

نوع ed25519 را انتخاب کنید؛ کوتاه‌تر و سریع‌تر از RSA است. سوییچ -C یک برچسب متنی است تا بعداً در authorized_keys سرور بفهمید هر کلید مال کدام دستگاه است. عبارت عبور (passphrase) را جز برای کلیدهای اتوماسیون خالی نگذارید؛ کلید خصوصی بدون آن یعنی هر کسی که یک بار به فایل‌های شما دسترسی پیدا کند، به سرور هم رسیده است.

فرستادن کلید عمومی به سرور

ssh-copy-id root@203.0.113.10

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/ali/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@203.0.113.10's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'root@203.0.113.10'"
and check to make sure that only the key(s) you wanted were added.

در ویندوز که ssh-copy-id ندارد، این جایگزین را در PowerShell اجرا کنید:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh root@203.0.113.10 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

از این به بعد ssh root@203.0.113.10 بدون تایپ رمز سرور وارد می‌شود.

مجوز فایل‌ها: رایج‌ترین دلیل کار نکردن کلید

اگر کلید را فرستادید و هنوز رمز می‌پرسد، معمولاً تقصیر مجوز فایل‌هاست: sshd کلید را نادیده می‌گیرد اگر پوشه‌ی خانه‌ی کاربر، پوشه‌ی ~/.ssh یا خودِ authorized_keys برای گروه یا دیگران قابل نوشتن باشد — قابل خواندن بودن اشکالی ندارد، چون داخل این فایل فقط کلید عمومی است. سمت شما هیچ خطایی چاپ نمی‌شود و فقط دوباره رمز پرسیده می‌شود، اما سرور علت را در لاگ می‌نویسد؛ با journalctl -u sshd (یا tail /var/log/auth.log) خطی شبیه Authentication refused: bad ownership or modes for directory /home/ali/.ssh را می‌بینید. روی سرور اجرا کنید:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

روی دستگاه خودتان هم کلید خصوصی باید 600 باشد وگرنه کلاینت از استفاده از آن امتناع می‌کند. در ویندوز chmod کاری نمی‌کند و باید مالکیت و ACL فایل را اصلاح کنید:

icacls "$env:USERPROFILE\.ssh\id_ed25519" /inheritance:r /grant:r "$env:USERNAME:R"

وقتی مطمئن شدید کلید کار می‌کند، در ۱۰ قدم حیاتی امنیت سرور لینوکس می‌بینید چطور ورود با رمز و ورود مستقیم root را ببندید.

فایل config: کوتاه‌کردن دستور و پایدارکردن اتصال

تایپ‌کردن آی‌پی و پورت و نام کاربری در هر اتصال، خسته‌کننده و اشتباه‌خیز است. فایل ~/.ssh/config (در ویندوز زیر پوشه‌ی .ssh کاربر) این را برای همیشه حل می‌کند:

Host srv1
    HostName 203.0.113.10
    User root
    Port 22
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 30
    ServerAliveCountMax 5

از این به بعد فقط می‌نویسید ssh srv1 — و همین نام مستعار در scp، rsync و sftp هم کار می‌کند. اما مهم‌ترین دو خط، دو خط آخرند. مقدار پیش‌فرض ServerAliveInterval صفر است، یعنی کلاینت هیچ بسته‌ی زنده‌نگه‌دارنده‌ای نمی‌فرستد؛ پس اگر چند دقیقه دستوری نزنید، مودم یا NAT مسیر اتصال بی‌کار را می‌بندد و پیام Broken pipe می‌گیرید. ServerAliveCountMax هم می‌گوید چند بسته‌ی بی‌پاسخ تحمل شود؛ پیش‌فرضش ۳ است و با ۵ حدود ۱۵۰ ثانیه قطعی موقت را بدون بسته‌شدن اتصال تاب می‌آورد.

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

Host db1
    HostName 10.0.0.12
    User root
    ProxyJump srv1

حالا ssh db1 اول به srv1 وصل می‌شود و از آنجا به مقصد می‌رود، بدون آنکه کلید خصوصی شما روی سرور واسط ذخیره شود.

انتقال فایل با scp، rsync و sftp

همان اتصال، کانال انتقال فایل هم هست و نرم‌افزار جداگانه نمی‌خواهد. ساده‌ترین حالت scp است:

scp backup.zip srv1:/root/
scp -r ./site srv1:/var/www/
scp srv1:/var/log/nginx/error.log ./

جهت انتقال برعکس هم می‌شود: هر طرف که مقصد است، دوم نوشته می‌شود. از OpenSSH نسخه‌ی ۹.۰ به بعد، scp در پشت‌صحنه دیگر از پروتکل قدیمی خودش استفاده نمی‌کند و روی SFTP سوار شده است.

برای هر چیزی جز یک فایل کوچک، rsync انتخاب بهتری است چون فقط تفاوت‌ها را می‌فرستد و با سوییچ -P تکه‌ی نیمه‌کاره را روی مقصد نگه می‌دارد:

rsync -avzP ./site/ srv1:/var/www/site/

به اسلش انتهای مسیر مبدأ دقت کنید: با اسلش، محتوای پوشه کپی می‌شود و بدون آن، خودِ پوشه داخل مقصد ساخته می‌شود — این تفاوت یک‌کاراکتری منبع بی‌شمار پوشه‌ی تودرتوی ناخواسته است. اگر انتقال قطع شد، همان دستور را دوباره بزنید؛ چون -P (کوتاه‌شده‌ی --partial --progress) تکه‌ی ناقص را روی مقصد نگه داشته، rsync از همان‌جا ادامه می‌دهد. بدون -P، rsync فایل نیمه‌کاره را پاک می‌کند و از صفر می‌فرستد. و اگر ترجیح می‌دهید فایل‌ها را مثل یک مدیر فایل مرور کنید، sftp srv1 یک نشست تعاملی با ls، cd، get و put باز می‌کند.

tmux و تونل SSH: دو کاری که فقط از SSH برمی‌آید

tmux — وقتی اینترنت قطع می‌شود، کار قطع نشود

هر دستوری که در نشست SSH معمولی اجرا کنید، با قطع اتصال کشته می‌شود. اگر وسط یک apt upgrade اینترنت بپرد، به‌روزرسانی نیمه‌کاره رها می‌شود — دقیقاً همان چیزی که سرور را خراب می‌کند. راه‌حل یک خط است (اگر tmux نصب نبود، اول apt install tmux و روی خانواده‌ی RHEL dnf install tmux):

tmux new -s work
# ... کار خود را انجام دهید، اتصال قطع شود ...
tmux attach -t work

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

پورت‌فوروارد — دیدن سرویس محلی سرور در مرورگر خودتان

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

ssh -L 8080:127.0.0.1:8080 srv1

حالا http://localhost:8080 در مرورگر شما در واقع پورت ۸۰۸۰ روی سرور است — رمزشده و بدون هیچ پورت بازی روی فایروال. برای دیتابیس هم همین است، اما عدد سمت چپ پورت روی دستگاه شماست: با ssh -L 3306:127.0.0.1:3306 srv1 و یک MySQL محلی، خطای bind: Address already in use می‌گیرید و بی‌آنکه بفهمید به دیتابیس خودتان وصل می‌شوید. پس یک پورت آزاد بگذارید: ssh -L 3307:127.0.0.1:3306 srv1 و اتصال به localhost:3307. سوییچ -D هم یک پروکسی SOCKS محلی می‌سازد؛ فقط یادتان باشد این ترافیک از پهنای باند سرور خرج می‌شود و برای تونل‌های دائمی، ابزارهای اختصاصی مناسب‌ترند — تفاوت‌ها را در راهنمای سرور تونل مقایسه کرده‌ایم.

خطاهای رایج اتصال SSH و درمان آن‌ها

جدول زیر هر پیام خطا را به علت محتمل و اولین اقدام مفید وصل می‌کند:

Connection timed out

اگر ping جواب می‌دهد اما پورت باز نیست، مشکل فایروال است؛ اگر ping هم جواب نمی‌دهد، سرور خاموش است یا آی‌پی را اشتباه برداشته‌اید. فایروال هم ممکن است دو لایه داشته باشد: داخل سیستم‌عامل (مثل UFW) و در سطح شبکه.

Permission denied (publickey,password)

عبارت داخل پرانتز دقیقاً می‌گوید سرور چه روش‌هایی را پذیرفته؛ اگر password در آن نباشد، تنها راه ورود کلید است و باید از کنسول گرافیکی سرور کلید عمومی‌تان را دستی داخل authorized_keys بگذارید.

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED

یعنی اثر انگشت کلید میزبان سرور با دفعه‌ی قبل فرق دارد. اگر خودتان سرور را از نو نصب (rebuild) کرده‌اید یا آی‌پی به سرور دیگری واگذار شده، طبیعی است؛ رکورد قدیمی را پاک کنید و دوباره وصل شوید:

ssh-keygen -R 203.0.113.10

# Host 203.0.113.10 found: line 14
/home/ali/.ssh/known_hosts updated.
Original contents retained as /home/ali/.ssh/known_hosts.old

اما اگر هیچ تغییری روی سرور نداده‌اید، این پیام را جدی بگیرید؛ SSH دارد هشدار می‌دهد که ممکن است چیزی وسط مسیر نشسته باشد. پیش از پاک‌کردن رکورد، اثر انگشت واقعی سرور را از کنسول گرافیکی سرور با ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub بگیرید و مقایسه کنید.

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

یک متغیر که در راهنماهای انگلیسی SSH پیدا نمی‌کنید، کیفیت ناپایدار مسیر است. اگر سرورتان داخل ایران باشد — مثل سرورهای ابری مهران هاست که در دیتاسنتر داخل کشور اجرا می‌شوند — مسیر کوتاه است و SSH معمولاً بی‌دردسر کار می‌کند. اما سرور خارج، هر اتصال شما را از گذرگاه بین‌الملل رد می‌کند: تأخیر بالا، افت بسته و قطعی‌های کوتاه.

سه اقدام کار را قابل‌تحمل می‌کنند: همان ServerAliveInterval که قطعی‌های چندثانیه‌ای را جذب می‌کند؛ اجرای هر کار طولانی داخل tmux؛ و اگر سرور داخلی هم دارید، رسیدن به سرور خارجی از مسیر آن با ProxyJump — گاهی مسیر دیتاسنتر تا مقصد باکیفیت‌تر از مسیر خانه‌ی شماست.

ابزاری به نام mosh هم هست که پس از یک ورود عادی با SSH، ارتباط را روی UDP ادامه می‌دهد و در برابر تغییر آی‌پی و قطعی مقاوم است — به شرطی که mosh روی هر دو سر نصب باشد و بازه‌ی پورت UDP ۶۰۰۰۰ تا ۶۱۰۰۰ در فایروال سرور باز باشد؛ وگرنه بعد از پیام mosh-server is running نشست تا ابد معلق می‌ماند. اما صادق باشیم: کیفیت UDP روی برخی مسیرهای بین‌الملل بدتر از TCP است و mosh ممکن است از SSH ساده ضعیف‌تر عمل کند. برای ریشه‌ی این تأخیرها راهنمای کاهش پینگ را ببینید، و اگر بین سرور داخل و خارج مردد هستید، راهنمای خرید سرور مجازی خارج معیارها را کنار هم گذاشته است.

قدم بعدی چیست؟

حالا که وارد سرور شده‌اید، وقت محکم‌کاری است. اولویت اول امنیت است — بستن ورود با رمز، ساخت کاربر غیر root، فایروال و Fail2ban. بعد از آن مسیر بسته به هدفتان جدا می‌شود: برای بالا آوردن سایت، راه‌اندازی وب‌سایت با Nginx روی اوبونتو؛ و برای نشستن چند سرویس کنار هم، اجرای داکر روی سرور ابری. هنوز سرور ندارید؟ در یک دقیقه یکی بسازید.

سؤالات پرتکرار

چطور به سرور مجازی با SSH وصل شوم؟

در ویندوز ۱۰ و ۱۱ پاورشل را باز کنید و در لینوکس و مک ترمینال را، سپس دستور ssh root@IP-SERVER را بزنید و آی‌پی سرور خود را جایگزین کنید. بار اول پیامی درباره‌ی اثر انگشت میزبان می‌بینید که با تایپ yes تأییدش می‌کنید، بعد رمز کاربر را وارد می‌کنید — رمز هنگام تایپ نمایش داده نمی‌شود. اگر پورت SSH تغییر کرده، آن را با سوییچ -p اضافه کنید.

چرا SSH خطای Connection timed out می‌دهد؟

این خطا یعنی درخواست شما اصلاً به سرویس SSH نرسیده است و سه علت رایج دارد: سرور خاموش است، فایروال پورت SSH را بسته، یا آی‌پی را اشتباه وارد کرده‌اید. برای تفکیک، باز بودن پورت را با دستور nc -zv IP 22 یا در ویندوز با Test-NetConnection بیازمایید. اگر پورت باز بود اما اتصال باز هم برقرار نشد، احتمالاً سرویس sshd اجرا نیست و باید از راه دسترسی خارج از شبکه — کنسول گرافیکی سرور — وضعیتش را ببینید.

تفاوت ورود با رمز و ورود با کلید SSH در چیست؟

در ورود با رمز، مبنای احراز هویت یک رشته‌ی قابل حدس زدن است و ربات‌ها شبانه‌روز همان را روی آی‌پی‌های عمومی امتحان می‌کنند. در ورود با کلید، یک جفت کلید ساخته می‌شود که نیمه‌ی خصوصی‌اش هرگز از دستگاه شما خارج نمی‌شود و سرور فقط با نیمه‌ی عمومی، هویت شما را می‌سنجد. نتیجه هم امن‌تر است و هم راحت‌تر، چون دیگر رمز سرور را تایپ نمی‌کنید؛ روی خودِ کلید حتماً یک عبارت عبور بگذارید — ssh-agent آن را فقط یک بار در هر نشست می‌پرسد.

آیا می‌شود از گوشی موبایل به سرور SSH زد؟

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

اگر SSH اصلاً وصل نشد و از سرور بیرون ماندم چه کار کنم؟

از کنسول تحت وب پنل کاربری استفاده کنید. این کنسول مستقیماً به صفحه‌نمایش مجازی سرور وصل می‌شود و به شبکه‌ی SSH وابسته نیست، بنابراین حتی وقتی پورت بسته شده، سرویس sshd خراب است یا فایل تنظیمات را اشتباه ویرایش کرده‌اید کار می‌کند — روی سرورهای ابری داخل ایران همیشه در دسترس است و روی سرورهای خارج به ارائه‌دهنده بستگی دارد. از همان‌جا وارد شوید، قانون فایروال یا فایل sshd_config را اصلاح کنید و سرویس را دوباره راه‌اندازی کنید تا دسترسی SSH برگردد.