احراز هویت با گذرواژه از راه SSH بزرگ‌ترین سطح در معرض دیدی است که یک سرور معمولی دارد. در برابر آن نه Fail2ban کارگر است و نه هیچ آستانه‌ای: هزار نشانی با یک تلاش در ساعت هرگز به حدی نمی‌رسند و تا زمانی که حدس‌زدن اصلاً ممکن باشد به حدس‌زدن ادامه می‌دهند. کلیدها خودِ این امکان را برمی‌دارند، و از میان همه فهرست سخت‌سازی این تنها تنظیمی است که وضع را کیفی دگرگون می‌کند.

تنها یک چیز در این میان ترسناک است: گذرواژه را خاموش کنید و بیرون بمانید. اینک ترتیبی که در آن چنین چیزی رخ نمی‌دهد.

کلید

روی ماشین خودتان ساخته می‌شود، نه روی سرور:

ssh-keygen -t ed25519 -C "work laptop"

ed25519 به‌جای RSA: کوتاه‌تر، سریع‌تر و بدون پرسش درباره طول. RSA تنها هنگامی لازم است که باید به چیزی بسیار قدیمی برسید؛ آن‌گاه -t rsa -b 4096.

گذاشتن عبارت عبور روی کلید ارزشش را دارد: فایل کلید ممکن است از لپ‌تاپ دزدیده شود و بدون عبارت عبور بی‌درنگ کار می‌کند. لازم نیست هر بار تایپش کنید — این را ssh-agent بر عهده می‌گیرد، و روی macOS و بیشتر سامانه‌های رومیزی لینوکس از پیش در حال اجراست.

کپی‌کردنش روی سرور یک فرمان است، تا وقتی گذرواژه هنوز کار می‌کند:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@203.0.113.25

اگر ssh-copy-id در دسترس نیست، محتوای فایل .pub همچون یک سطر به ~/.ssh/authorized_keys روی سرور افزوده می‌شود. مجوزها مهم‌اند: پوشه .ssh با ۷۰۰، فایل با ۶۰۰، و مالکش کاربر. با هر چیز دیگری sshd بی‌صدا از خواندن فایل سر باز می‌زند، و این رایج‌ترین علت جمله «کلید کار نمی‌کند» است.

بررسی‌ای که همه‌چیز را روشن می‌کند

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

ssh -o PasswordAuthentication=no user@203.0.113.25

این گزینه به کارخواه اجازه بازگشت به گذرواژه را نمی‌دهد — پس اگر ورود کامیاب شد، با کلید کامیاب شده است. تا این فرمان کار نکند، پیش نروید. و اتصال نخست را تا پایان باز نگه دارید: همان است که هر چه را خراب کنید درست می‌کند.

خاموش‌کردن گذرواژه‌ها و یک مانع نه‌چندان آشکار

تنظیمات را در فایلی جداگانه می‌گذارند تا به‌روزرسانی بسته آن‌ها را بازننویسد. اما نام فایل مهم است:

sudo tee /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PasswordAuthentication no
PermitRootLogin no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LogLevel VERBOSE
EOF

نکته آن است که OpenSSH نخستین مقداری را که برای یک پارامتر می‌یابد به کار می‌برد، نه آخرین را چنان‌که تقریباً همه‌جای دیگر. فایل‌های درون sshd_config.d به ترتیب الفبا خوانده می‌شوند، و تصویرهای ابری Ubuntu آنجا 50-cloud-init.conf را می‌گذارند که اغلب PasswordAuthentication yes دارد. فایل شما با شماره ۹۰ در چنین وضعی هیچ کاری نمی‌کند: تنظیم ظاهراً سر جایش است در حالی که گذرواژه همچنان کار می‌کند. از همین‌روست شماره ۱۰ — زودتر خوانده می‌شود.

آنچه واقعاً از کار درآمده را می‌توانید بدون حدس ببینید:

sudo sshd -T | grep -Ei 'passwordauth|permitrootlogin|pubkeyauth'

این فرمان پیکربندی مؤثر را پس از همه include‌ها چاپ می‌کند. به آن اعتماد کنید نه به محتوای فایل‌ها.

سپس بررسی نحو و بارگذاری نرم دوباره سرویس:

sudo sshd -t && sudo systemctl reload ssh

sshd -t الزامی است: یک غلط تایپی در پیکربندی همراه با restart سرویس را افتاده و شما را بیرون می‌گذارد. reload نشست‌های باز را هم قطع نمی‌کند.

Ubuntu 24.04: پورت آنجایی نیست که گمان می‌کنید

تله‌ای جداگانه در Ubuntu‌های تازه: sshd آنجا از راه سوکت systemd آغاز می‌شود. در این حالت سطر Port در sshd_config هیچ کاری نمی‌کند — سوکت گوش می‌دهد نه دیمن. اگر پورت را عوض می‌کنید، همین را باید ویرایش کنید:

sudo systemctl edit ssh.socket

و ListenStream= (مقدار تهی مقدار پیشین را صفر می‌کند) باید پورت تازه را نام ببرد. نشانه‌ای که این را لو می‌دهد: پیکربندی عوض شده، سرویس بازراه‌اندازی شده، و سرور همچنان روی ۲۲ پاسخ می‌دهد.

و حالا که سخن از عوض‌کردن پورت شد: همچون حفاظت کار نمی‌کند — پویشگرها سرویس را روی هر پورتی در چند دقیقه می‌یابند. تنها اثرش گزارش‌های آرام‌تر است، چون حدس‌زدن انبوه تنها به ۲۲ می‌رود. این آسوده است، اما با امنیت اشتباهش نگیرید.

چه کسی اصلاً اجازه ورود دارد

افزوده‌ای سودمند فهرستی صریح است:

AllowUsers deploy admin

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

راه ورود پشتیبان

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

  • کلیدی دوم از دستگاهی دیگر در authorized_keys؛
  • رونوشتی از کلید خصوصی در یک مدیر گذرواژه یا روی حافظه رمزگذاری‌شده؛
  • دسترسی آزموده به کنسول نزد ارائه‌دهنده‌تان — VNC یا سریال. آزموده یعنی دست‌کم یک‌بار از راه آن وارد شده‌اید، نه اینکه «جایی در پنل دکمه‌ای هست».

و حالا که آنجایید، ببینید در authorized_keys از پیش چه هست — هم برای کاربرتان و هم برای root. کلید بیگانه آنجا از هر تغییر گذرواژه جان به در می‌برد و دسترسی کارآمدی می‌ماند.

و پس از آن

حدس‌زدن گذرواژه از میان نمی‌رود، تنها بی‌فایده می‌شود: گزارش‌ها همچنان هزاران سطر Failed password گرد خواهند آورد که هیچ‌کدام نمی‌تواند به کامیابی بینجامد. آنچه اکنون ارزش پایش دارد ورودهای کامیاب است: از کدام نشانی، با کدام کاربر، در چه ساعتی. ورود کامیاب با کلید از نشانی‌ای ناآشنا رویدادی بسیار مهم‌تر از یک میلیون شکست است، و دیدنش در جریان کلی بسیار دشوارتر. همین تصویر را صفحه نمایشی پایین نشان می‌دهد.