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

SSH چیست؟

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

این نام به دو مفهوم اشاره دارد. SSH پروتکلی است که در RFC 4251 تا RFC 4254 توصیف شده است. OpenSSH برنامه‌ای است که این پروتکل را پیاده‌سازی می‌کند و تقریباً روی هر سرور لینوکسی و هر لپ‌تاپی اجرا می‌شود. وقتی کسی می‌گوید "SSH into the server" (از طریق SSH به سرور متصل شو)، منظور او استفاده از برنامه کلاینت ssh روی دستگاه خودش برای برقراری ارتباط با برنامه سرور sshd در سمت دیگر است.

مشکلی که SSH برای جایگزینی آن ساخته شد

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

Tatu Ylönen اولین SSH را در سال 1995 در دانشگاه صنعتی هلسینکی، پس از یک حمله شنود رمز عبور در شبکه دانشگاه نوشت. این طراحی بخش مفید telnet، یعنی یک جریان بایت بین ترمینال شما و یک shell از راه دور را حفظ می‌کند و دو موردی که telnet پاسخی برای آن‌ها ندارد را اضافه می‌کند: رمزنگاری جریان، و اثبات اینکه سرور در انتهای دیگر، همان سروری است که قصد داشتید به آن متصل شوید.

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

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

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

• سرور فایل /etc/ssh/sshd_config را می‌خواند. در این فایل است که ورود با رمز عبور غیرفعال شده و پورت گوش‌دهی (listening port) تنظیم می‌شود.
• کلاینت برای تنظیمات پیش‌فرض سیستم، فایل /etc/ssh/ssh_config و برای تنظیمات اختصاصی شما به ازای هر میزبان، فایل ~/.ssh/config را می‌خواند.

در Debian و Ubuntu، واحد سرویس (service unit) با نام ssh شناخته می‌شود. در RHEL، Rocky و Fedora نام آن sshd است. نسخه‌های جدید Ubuntu آن را به صورت socket activated نصب می‌کنند، بنابراین ممکن است systemctl status ssh وضعیت inactive (dead) را گزارش دهد در حالی که دستگاه کاملاً در دسترس است؛ زیرا ssh.socket واحدی است که وظیفه گوش دادن را بر عهده دارد و سرویس را در صورت نیاز (on demand) راه‌اندازی می‌کند.

کلاینت لزوماً نباید OpenSSH باشد. PuTTY در ویندوز، Termius در تلفن همراه و قابلیت پشتیبانی از راه دور که در ویرایشگرها تعبیه شده است، همگی از پروتکل یکسانی برای ارتباط با همان sshd استفاده می‌کنند. ویندوز 10 و 11 نیز شامل کلاینت OpenSSH هستند، بنابراین ssh you@server بدون نیاز به نصب هیچ‌گونه نرم‌افزاری، در PowerShell کار می‌کند.

چرا SSH از پورت 22 استفاده می‌کند؟

پورت عددی است که به هسته سیستم‌عامل می‌گوید یک اتصال ورودی متعلق به کدام برنامه در حال اجرا (listening) است و پورت‌ها در لینوکس برای همه سرویس‌ها به همین شکل عمل می‌کنند. SSH از پورت 22 استفاده می‌کند زیرا IANA در سال 1995 این پورت را به آن اختصاص داد. Ylönen درخواست یک شماره آزاد در مجاورت پروتکل‌هایی را داشت که SSH برای جایگزینی آن‌ها نوشته شده بود: پورت 21 برای FTP، پورت 23 برای telnet و پورت 22 در آن زمان بدون استفاده بود.

از آنجا که 22 پورت پیش‌فرض است، همه چیز آن را فرض می‌گیرد. ریموت Git شما، اسکریپت پشتیبان‌گیری و پنل کنترل ارائه‌دهنده سرویس شما، همگی ابتدا پورت 22 را امتحان می‌کنند. هر اسکنر خودکار در اینترنت نیز همین کار را انجام می‌دهد. یک سرور جدید که ورود با رمز عبور در آن فعال باشد، دقایقی پس از بوت شدن، شروع به جمع‌آوری خطوطی مانند این در /var/log/auth.log می‌کند:

Failed password for invalid user admin from 203.0.113.55 port 43122 ssh2

این ترافیک دائمی است و شخص شما را هدف قرار نداده است. انتقال sshd به پورت 2222 اکثر این خطوط را حذف می‌کند، زیرا اسکنرها به جای بررسی دقیق سرور شما، کل اینترنت را روی پورت 22 جارو می‌کنند. این کار باعث نمی‌شود نفوذ به دستگاه برای کسی که واقعاً قصد آن را دارد دشوارتر شود. تغییر پورت را صرفاً به عنوان کاهش نویز در نظر بگیرید و نه چیزی بیشتر.

شما می‌توانید پاسخ سرور را پیش از ورود به سیستم مشاهده کنید:

nc 203.0.113.10 22

در Ubuntu 24.04 این دستور خروجی مشابه SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13 چاپ می‌کند. این بنر به صورت متن ساده (cleartext) و پیش از برقراری هرگونه رمزنگاری ارسال می‌شود، زیرا هر دو طرف برای توافق بر سر نسخه پروتکل به آن نیاز دارند. برای بستن اتصال، کلیدهای Ctrl+C را فشار دهید.

هنگام اتصال، در شبکه چه اتفاقی می‌افتد

توالی زیر مراحلی است که یک ssh you@server پیش از نمایش اعلان (prompt) به شما طی می‌کند.

1. کلاینت نام میزبان (hostname) را به آدرس IP ترجمه کرده و سپس یک اتصال TCP به پورت 22 باز می‌کند.
2. هر دو طرف بنر نسخه (version banner) خود را به‌صورت متن ساده (cleartext) ارسال می‌کنند.
3. هر دو طرف فهرستی از الگوریتم‌های پشتیبانی‌شده خود را ارسال می‌کنند: تبادل کلید، رمزنگاری، احراز اصالت پیام و فشرده‌سازی. این مرحله نیز همچنان متن ساده است. قوی‌ترین گزینه‌ای که هر دو طرف می‌شناسند، انتخاب می‌شود.
4. تبادل کلید انجام می‌شود. OpenSSH فعلی، curve25519-sha256 را ترجیح می‌دهد. هر دو طرف به یک راز مشترک دست می‌یابند، بدون آنکه این راز از شبکه عبور کند؛ بنابراین کسی که کل مکالمه را ضبط کرده باشد، نمی‌تواند بعداً آن را استخراج کند.
5. سرور نتیجهٔ آن تبادل را با کلید خصوصی میزبان خود امضا می‌کند. کلاینت شما امضا را با کلید عمومی میزبان که در فایل‌هایش دارد، تطبیق می‌دهد. این مرحله‌ای است که مانع از جعل هویت سرور شما توسط یک دستگاه واسط می‌شود.
6. رمزنگاری آغاز می‌شود. chacha20-poly1305@openssh.com رمزنگار پیش‌فرض در OpenSSH فعلی است.
7. تنها در این مرحله است که کلاینت شما را با رمز عبور یا کلید احراز اصالت می‌کند. نام کاربری و رمز عبور شما درون کانال رمزنگاری‌شده منتقل می‌شوند.
8. کلاینت یک کانال باز کرده و درخواست shell می‌کند.

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

کسی که شبکه را زیر نظر دارد، همچنان اطلاعاتی کسب می‌کند. آن‌ها آدرس IP شما، آدرس IP سرور، پورت 22، هر دو بنر نسخه به صورت متن ساده، و زمان‌بندی و حجم تقریبی هر بسته (packet) را می‌بینند. آن‌ها نام کاربری، رمز عبور، دستورات یا خروجی آن‌ها را نمی‌بینند. جستجوی نام میزبان در مرحله 1 بخشی از SSH نیست و معمولاً خصوصی نیست، بنابراین پرس‌وجوی DNS که نام سرور شما را ترجمه می‌کند می‌تواند فاش کند که قصد دارید به کدام دستگاه متصل شوید، حتی اگر خود نشست (session) کاملاً محرمانه باقی بماند.

کلید میزبان و آن اعلان اثر انگشت در اولین اتصال

هنگامی که openssh-server نصب می‌شود، جفت‌کلیدهای میزبان را برای آن ماشین تولید کرده و در /etc/ssh/ می‌نویسد؛ برای مثال در ssh_host_ed25519_key و ssh_host_ed25519_key.pub. بخش خصوصی هرگز از سرور خارج نمی‌شود. بخش عمومی، هویت سرور است و امضای مرحله 5 بر اساس آن بررسی می‌شود.

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

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:E9nVQ5Sm2oQ3nGm5Zf1tOaU7Xh0k2p8bWc4dLrTvYxA.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

این اثر انگشت (fingerprint)، یک هش SHA256 از کلید عمومی میزبان است که به صورت base64 نمایش داده می‌شود تا برای مقایسه چشمی به اندازه کافی کوتاه باشد. تایپ کردن yes، آن کلید را در ~/.ssh/known_hosts روی ماشین خودتان ذخیره می‌کند. در تمام اتصالات بعدی به همان آدرس، کلیدی که سرور ارائه می‌دهد با کلید ذخیره‌شده مقایسه می‌شود. وقتی مطابقت داشته باشند، چیزی چاپ نمی‌شود و مستقیماً به اعلان دستور (prompt) خود می‌روید.

این مدل، «اعتماد در اولین استفاده» (trust on first use) نامیده می‌شود و لازم است صادقانه درباره هزینه‌های آن صحبت کنیم. اولین اتصال، تنها لحظه‌ای است که شما محافظت‌نشده هستید، زیرا کلیدی را می‌پذیرید که قبلاً هرگز ندیده‌اید. برای بستن این شکاف امنیتی، اثر انگشت را از طریق دیگری دریافت کرده و مقایسه کنید. اکثر ارائه‌دهندگان، آن را در خروجی بوت که در کنسول وب نمایش داده می‌شود چاپ می‌کنند؛ همچنین می‌توانید آن را روی خود سرور نیز چاپ کنید:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

این دستور همان رشته SHA256: را چاپ می‌کند که در اعلان اولیه به شما نشان داده شده بود. گزینه [fingerprint] در اعلان، دقیقاً برای همین منظور وجود دارد: اثر انگشتی که انتظار دارید را وارد کنید تا کلاینت تنها در صورتی ادامه دهد که با آنچه سرور ارائه کرده است مطابقت داشته باشد.

در Debian و Ubuntu، فایل known_hosts به‌صورت پیش‌فرض هش می‌شود، بنابراین این فایل به جای نام‌های میزبان خوانا، شامل خطوطی است که با |1| شروع می‌شوند. برای یافتن ورودی مربوط به یک میزبان، دستور ssh-keygen -F 203.0.113.10 را اجرا کنید.

چرا SSH می‌گوید کلید میزبان (host key) تغییر کرده است؟

دیر یا زود با این دیوار متنی مواجه خواهید شد:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

این پیام با Host key verification failed. پایان می‌یابد و کلاینت از برقراری اتصال خودداری می‌کند. همچنین Password authentication is disabled to avoid man-in-the-middle attacks. را چاپ می‌کند، زیرا وارد کردن رمز عبور در یک ماشین ناشناس، دقیقاً همان آسیبی است که این بررسی برای جلوگیری از آن طراحی شده است.

این پیام شبیه به یک وضعیت اضطراری به نظر می‌رسد، اما در بیشتر مواقع چنین نیست. دلایل معمول عبارتند از:

• شما سرور را بازسازی یا دوباره نصب کرده‌اید، بنابراین sshd در اولین بوت، کلیدهای میزبان جدیدی تولید کرده است. این رایج‌ترین دلیل است.
• شما یک VPS را حذف و دیگری ایجاد کرده‌اید و ارائه‌دهنده، همان آدرس IP قدیمی را به ماشین جدید اختصاص داده است.
• شما از طریق یک forward یا load balancer متصل می‌شوید که اکنون به یک ماشین backend متفاوت هدایت می‌شود.
• واقعاً چیزی در حال شنود (intercept) اتصال شماست.

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

ssh-keygen -R 203.0.113.10

اتصال بعدی دوباره اعلان اثر انگشت (fingerprint) را نمایش می‌دهد که به شما فرصتی تازه می‌دهد تا آن را با کنسول ارائه‌دهنده مقایسه کنید.

تفاوت ورود با رمز عبور و ورود با کلید

احراز هویت با رمز عبور، رمز شما را درون کانالی که از قبل رمزنگاری شده ارسال می‌کند و sshd آن را با پایگاه داده حساب کاربری، معمولاً از طریق PAM (ماژول‌های احراز هویت قابل اتصال)، مطابقت می‌دهد. این روش به هیچ آماده‌سازی نیاز ندارد؛ به همین دلیل است که ارائه‌دهنده می‌تواند سرور جدیدی را فقط با یک رمز عبور root به شما تحویل دهد.

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

احراز هویت با کلید عمومی متفاوت عمل می‌کند. شما یک جفت کلید روی ماشین خود می‌سازید. نیمه عمومی آن در ~/.ssh/authorized_keys درون حساب کاربری شما روی سرور قرار می‌گیرد. نیمه خصوصی روی لپ‌تاپ شما باقی می‌ماند و هرگز منتقل نمی‌شود. برای ورود، کلاینت بخشی از داده‌ها را که شامل شناسه نشست (session identifier) از تبادل کلید است، امضا می‌کند و سرور آن امضا را با استفاده از کلید عمومی که از قبل در اختیار دارد، تأیید می‌کند. از آنجا که داده‌های امضا شده به همین یک نشست خاص گره خورده‌اند، امضای ضبط‌شده برای هر کار دیگری بی‌ارزش است.

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

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

Authentication refused: bad ownership or modes for directory /home/ubuntu/.ssh

کلاینت فقط به شما می‌گوید Permission denied (publickey)، که پیامی یکسان برای ده‌ها دلیل متفاوت است؛ بنابراین خواندن صحیح خطای publickey پیش از آنکه دسترسی شما قطع شود، ارزش یادگیری دارد. کار عملی ساخت کلیدها، محافظت از آن‌ها با یک passphrase و بارگذاری آن‌ها در یک agent در بخش مدیریت کلید SSH قرار دارد و غیرفعال کردن ورود با رمز عبور بدون قطع دسترسی خودتان، در بخش ایمن‌سازی SSH روی یک VPS توضیح داده شده است.

SFTP، scp و port forwarding از یک اتصال واحد استفاده می‌کنند

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

• یک shell از راه دور. ssh you@server یک کانال نشست (session channel) باز می‌کند و درخواست یک shell تعاملی می‌دهد.
• یک دستور واحد. ssh you@server uptime یک کانال باز می‌کند، یک دستور را اجرا می‌کند، خروجی را چاپ کرده و خارج می‌شود.
• SFTP. کلاینت از sshd می‌خواهد که زیرسیستم sftp خود را راه‌اندازی کند و انتقال فایل در داخل همان اتصال انجام می‌شود. SFTP یک پروتکل انتقال فایل است که بر بستر SSH سوار می‌شود و هیچ اشتراک طراحی با FTP ندارد. پروتکلی که در واقع همان FTP با افزودن رمزنگاری است، FTPS نامیده می‌شود و هیچ ارتباطی با این موضوع ندارد.
• scp. فایل‌ها را با استفاده از همان ورود به سیستم کپی می‌کند. از زمان OpenSSH 9.0 که در سال 2022 منتشر شد، scp به‌طور پیش‌فرض از پروتکل SFTP در لایه زیرین خود استفاده می‌کند.
• Port forwarding. ssh -L 8080:localhost:80 you@server پورت 8080 روی لپ‌تاپ شما را به دروازه‌ای برای پورت 80 روی سرور تبدیل می‌کند که در داخل همان اتصال رمزنگاری‌شده حمل می‌شود. -R ترافیک را در جهت مخالف هدایت می‌کند و -D 1080 نشست را به یک SOCKS proxy تبدیل می‌کند.
• Git. یک remote مانند git@github.com:user/repo.git، یک ورود به سیستم SSH است که سمت سرور آن، به‌جای shell، یک پردازشگر دستور (command handler) را اجرا می‌کند.
• rsync و Ansible نیز کلاینت‌های SSH هستند. آن‌ها یک کانال باز می‌کنند، چیزی را اجرا کرده و خروجی را می‌خوانند.

هر مورد در این لیست از همان پورت، همان بررسی کلید میزبان (host key check) و همان اعتبارنامه‌ها استفاده می‌کند. به همین دلیل است که راه‌اندازی احراز هویت با کلید، بلافاصله نتیجه‌بخش است: هر یک از این ابزارها آن را به ارث می‌برند. همچنین به همین دلیل است که همان فایل ~/.ssh/config که ورودهای شما را کوتاه می‌کند، فایلی است که هنگام مدیریت چندین سرور لینوکسی از یک لپ‌تاپ، مقیاس‌پذیر می‌شود.

کارهایی که SSH انجام نمی‌دهد

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

گام‌های بعدی

اگر در حال حاضر یک سرور جدید در کنسول ارائه‌دهندهٔ خود باز کرده‌اید، ترتیب انجام کارها مشخص است. وارد شوید، یک کاربر معمولی بسازید، کلید خود را نصب کنید و سپس مسیرهای دسترسی آسان را ببندید. مقاله ده دقیقه اول روی یک VPS جدید این ترتیب را از ابتدا تا انتها بررسی می‌کند و VPS دقیقاً چیست اگر با این مفاهیم آشنا نیستید، جزئیات سخت‌افزاری زیرساخت را برایتان روشن می‌کند. پس از آن، مقالات مربوط به کلیدها و مقاوم‌سازی (hardening) را به همین ترتیبی که ذکر شد، مطالعه کنید.

FAQ

مخفف SSH چیست؟

SSH مخفف Secure Shell است. این یک پروتکل برای ورود به یک کامپیوتر از راه دور و اجرای دستورات روی آن از طریق یک اتصال رمزنگاری‌شده است که در RFC 4251 تا RFC 4254 تعریف شده است. OpenSSH پیاده‌سازی است که تقریباً همه از آن استفاده می‌کنند: کلاینت ssh روی سیستم شما و سرور sshd روی سیستم مقصد. این پروتکل جایگزین telnet شد که همه چیز، از جمله رمزهای عبور را به صورت متن ساده (plain text) در شبکه ارسال می‌کرد.

چرا SSH از پورت 22 استفاده می‌کند؟

IANA در سال 1995 پورت 22 را به SSH اختصاص داد، در کنار FTP روی پورت 21 و telnet روی پورت 23، یعنی پروتکل‌هایی که SSH برای جایگزینی آن‌ها نوشته شده بود. هیچ اجباری برای استفاده از این عدد وجود ندارد: Port در فایل /etc/ssh/sshd_config آن را در سمت سرور تغییر می‌دهد و ssh -p پورت متفاوتی را در سمت کلاینت انتخاب می‌کند. از آنجا که 22 پورت پیش‌فرض است، اسکنرهای خودکار دائماً آن را بررسی می‌کنند، به همین دلیل است که فایل /var/log/auth.log در یک سرور تازه، با خطوط Failed password for invalid user پر می‌شود. تغییر پورت فقط این نویز را کاهش می‌دهد و امنیت واقعی ایجاد نمی‌کند.

وقتی SSH هشدار می‌دهد که کلید میزبان (host key) تغییر کرده است، چه باید کرد؟

پیش از پاک کردن هر چیزی، علت را پیدا کنید. دلیل معمول بی‌خطر است: سرور دوباره ساخته شده است، بنابراین sshd کلیدهای میزبان جدیدی تولید کرده، یا یک ماشین جدید همان آدرس IP قبلی را دریافت کرده است. اگر می‌دانید ماشین دوباره ساخته شده، دستور ssh-keygen -R <host> را اجرا کنید تا کلید ذخیره‌شده حذف شود، سپس دوباره متصل شوید و اثر انگشت (fingerprint) نمایش داده شده را با آنچه در کنسول ارائه‌دهنده سرویس شما گزارش شده، مقایسه کنید. اگر از سمت شما تغییری رخ نداده، متصل نشوید و رمز عبور خود را وارد نکنید. OpenSSH دقیقاً به همین دلیل در این وضعیت از احراز هویت با رمز عبور جلوگیری می‌کند.

آیا SFTP و scp با SSH متفاوت هستند؟

آن‌ها روی بستر SSH اجرا می‌شوند. هنگامی که احراز هویت شدید، اتصال SSH می‌تواند چندین کانال را حمل کند و shell تنها یکی از آن‌هاست. SFTP یک پروتکل انتقال فایل است که از زیرسیستم sftp در sshd روی همان اتصال استفاده می‌کند و scp از نسخه OpenSSH 9.0 به بعد، در لایه زیرین از پروتکل SFTP استفاده می‌کند. Port forwarding و Git over SSH نیز کانال‌هایی روی همان اتصال هستند. همه آن‌ها از همان پورت، همان بررسی کلید میزبان و همان ورود استفاده می‌کنند. توجه داشته باشید که SFTP همان FTP با رمزنگاری اضافه شده نیست؛ پروتکل رمزنگاری‌شده FTP، با نام FTPS شناخته می‌شود و یک پروتکل مجزا است.

آیا احراز هویت با کلید واقعاً بهتر از رمز عبور است؟

بله، برای هر سروری که از طریق اینترنت در دسترس است. رمز عبور یک راز کوتاه است که در هر بار ورود به سرور ارائه می‌دهید و پورت 22 دائماً توسط کلاینت‌های خودکار حدس زده می‌شود. با یک جفت کلید، بخش خصوصی (private key) هرگز سیستم شما را ترک نمی‌کند: کلاینت داده‌های مرتبط با نشست فعلی را امضا می‌کند و سرور آن امضا را با کلید عمومی موجود در ~/.ssh/authorized_keys تطبیق می‌دهد. یک امضای ضبط‌شده را نمی‌توان روی سرور دیگری بازپخش کرد. از کلید خصوصی با یک passphrase محافظت کنید، زیرا یک فایل کلید بدون passphrase، برای هر کسی که آن را کپی کند، یک ابزار ورود آماده است.