ورود SSH به سرور تازه: از رمز تا بستن روت

سرور را تحویل گرفته‌اید، رمز روت در پنل است، و اولین کاری که می‌کنید این است:

ssh root@185.10.20.30

و بعد از چند ثانیه این را می‌بینید:

Permission denied (publickey).

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

اول تشخیص بدهید چرا ورود SSH رد می‌شود

قبل از هر تغییری، پیام خطا را بخوانید. سه حالت رایج داریم و هرکدام درمان متفاوتی دارد.

• Connection refused یعنی سرویس sshd بالا نیست یا روی پورت دیگری گوش می‌دهد. از کنسول پنل سرور (VNC) وارد شوید و systemctl status sshd بزنید.
• Permission denied (publickey) یعنی سرور فقط کلید قبول می‌کند و شما کلید نفرستاده‌اید. با ssh -v root@IP ببینید کدام کلیدها پیشنهاد شده‌اند.
• Connection timed out تقریباً همیشه فایروال است، نه SSH. یا در پنل ابری پورت بسته است، یا ufw روی سرور پورت 22 را نبسته باقی نگذاشته.

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

ساخت کاربر غیر روت قبل از هر کار دیگری

کار کردن با روت وسوسه دارد و اشتباه است. یک کاربر بسازید، به گروه sudo اضافه کنید، و از همان لحظه با او وارد شوید:

adduser ali
usermod -aG sudo ali
rsync --archive --chown=ali:ali ~/.ssh /home/ali

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

chmod 700 /home/ali/.ssh
chmod 600 /home/ali/.ssh/authorized_keys
chown -R ali:ali /home/ali/.ssh

حالا یک ترمینال جدید باز کنید و ssh ali@IP بزنید. تا وقتی این پنجره باز است، پنجره روت را نبندید. این تنها بیمه‌نامه واقعی شماست.

انتقال کلید، و اینکه چرا رمز عبور را نگه می‌داریم

روی لپ‌تاپ خودتان:

ssh-keygen -t ed25519 -C "ali@laptop"
ssh-copy-id ali@185.10.20.30

ed25519 را به rsa ترجیح می‌دهم: کلید کوتاه‌تر، امضا سریع‌تر، و روی OpenSSH نسخه 8 به بالا پیش‌فرض امن است. اگر کلاینت قدیمی دارید که ed25519 را نمی‌شناسد، ssh-keygen -t rsa -b 4096 بزنید و تمام.

اینجا اشتباه می‌کنند: خیلی‌ها همان شب PasswordAuthentication no را می‌گذارند و رمز روت را هم عوض نمی‌کنند. سه هفته بعد لپ‌تاپ عوض می‌شود، کلید قدیمی همراه فایل‌های پشتیبان می‌رود، و هیچ راه ورودی نمی‌ماند جز rescue. من رمز عبور را برای کاربر غیر روت باز نگه می‌دارم و فقط روت را می‌بندم. هزینه‌اش این است که سطح حمله کمی بزرگ‌تر می‌شود؛ در عوض یک در پشتی قانونی دارید که با fail2ban و یک رمز بلند محافظت می‌شود.

بستن ورود روت: تغییر کوچک، اثر بزرگ

فایل /etc/ssh/sshd_config.d/99-hardening.conf را بسازید تا تنظیمات پیش‌فرض توزیع را دست نزنید:

PermitRootLogin no
PasswordAuthentication yes
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 20

بعد sshd -t برای تست سینتکس و systemctl reload sshd. هرگز restart نزنید وقتی از همان مسیر SSH وصل هستید؛ reload اتصال فعلی را قطع نمی‌کند، restart ممکن است بکند.

عدد MaxAuthTries 3 را دست‌کم نگیرید. روی سروری که ماه پیش راه انداختم، لاگ /var/log/auth.log در 24 ساعت 41 هزار تلاش ناموفق نشان می‌داد؛ با این تنظیم هر اتصال بعد از سه تلاش بسته می‌شود و بار روی sshd محسوس پایین می‌آید.

fail2ban و پورت، دو تصمیمی که اغلب اشتباه گرفته می‌شوند

تغییر پورت SSH از 22 به چیز دیگر امنیت واقعی نمی‌آورد؛ فقط نویز لاگ را کم می‌کند. اگر اسکنرها را آزاردهنده می‌دانید عوضش کنید، ولی به‌جایش روی fail2ban سرمایه‌گذاری کنید:

apt install fail2ban
# /etc/fail2ban/jail.local
[sshd]
enabled = true
maxretry = 4
bantime = 1h

نکته‌ای که کمتر گفته می‌شود: اگر پورت SSH را عوض کردید، باید port را در jail هم به‌روز کنید، وگرنه fail2ban روی پورت اشتباه گوش می‌دهد و هیچ‌وقت کسی را بن نمی‌کند. علامتش هم این است که لاگ پر از تلاش ناموفق است ولی fail2ban-client status sshd عدد صفر نشان می‌دهد.

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

1. به‌روزرسانی کامل: apt update && apt full-upgrade -y و بعد یک ریبوت تا کرنل جدید فعال شود.
2. فایروال: ufw allow 22/tcp && ufw allow 80,443/tcp && ufw enable. ترتیب مهم است؛ اگر اول enable بزنید، خودتان را بیرون می‌بندید.
3. زمان سرور: timedatectl set-timezone Asia/Tehran تا لاگ‌ها با ساعت محلی بخوانند.
4. سواپ اگر رم کم است، و بررسی free -h و df -h.
5. یک اسنپ‌شات یا بکاپ اولیه از پنل، قبل از نصب هر چیز سنگین.

اگر بعد از این‌ها سرور کند شد، احتمالاً مشکل SSH نیست؛ الگوی مصرف CPU و I/O را در تشخیص علت لود بالای سرور دنبال کنید.

انتقال فایل و ادامه راه

برای آپلود پروژه از لپ‌تاپ، scp -r ./app ali@IP:/var/www/ کافی است، ولی برای هر چیزی بزرگ‌تر از چند صد مگابایت rsync بزنید تا در صورت قطعی از همان‌جا ادامه دهد. جزئیات فلگ‌ها در انتقال فایل با scp و rsync آمده.

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

برای سرورهای کوچک و متوسط، همین ترتیب کافی است. اگر بار کاری‌تان سنگین است و به منابع اختصاصی CPU و دیسک NVMe نیاز دارید، هاست لینوکس نقطه شروع منطقی‌تری است تا اینکه روی یک VPS اشتراکی همه چیز را دستی تنظیم کنید.

پرسش‌های پرتکرار

چرا بعد از بستن ورود روت دیگر نمی‌توانم با SSH وارد شوم؟

چون کاربر غیر روت را قبل از بستن روت تست نکرده‌اید یا مجوزهای ~/.ssh درست نیست. SSH اگر مجوز پوشه 755 یا فایل کلید 644 باشد، بی‌هیچ پیام واضحی ورود را رد می‌کند. با کنسول پنل وارد شوید و chmod 700 و chmod 600 را اعمال کنید.

آیا تغییر پورت SSH امنیت را بیشتر می‌کند؟

نه به‌اندازه‌ای که تصور می‌شود. اسکنرها بازه کامل پورت‌ها را می‌گردند و فقط چند ثانیه بیشتر وقت می‌گذارند. اثر واقعی‌اش کم‌شدن نویز لاگ است. اگر می‌خواهید جلوی brute-force را بگیرید، fail2ban و کلید عمومی اثر بیشتری دارند.

کلید ed25519 بهتر است یا RSA؟

برای هر سروری که OpenSSH نسخه 6.5 به بالا دارد، ed25519 انتخاب بهتری است: کوتاه‌تر، سریع‌تر و بدون وابستگی به طول کلید. فقط اگر با تجهیزات شبکه قدیمی یا کلاینت‌های خیلی قدیمی کار می‌کنید، RSA با 4096 بیت را نگه دارید.

اگر کلید خصوصی را گم کنم چه می‌شود؟

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