تنظیمات امنیتی SSH و جلوگیری از ورود غیرمجاز به سرور لینوکس

مقدمه: 

تنظیمات امنیتی SSH و جلوگیری از ورود آن توسط افراد غیرمجاز باید با فعال‌سازی SSH Key، محدودکردن کاربران مجاز، غیرفعال‌کردن ورود مستقیم Root و کنترل تلاش‌های ناموفق انجام شود. مهم‌ترین نکته، ترتیب اجرای تغییرات است: ابتدا دسترسی کلیدی و کاربر دارای Sudo را در یک نشست جداگانه آزمایش کنید و فقط پس از اطمینان، ورود رمزی را ببندید. همچنین باید فایروال، لاگ‌ها، به‌روزرسانی‌ها و مسیر دسترسی اضطراری به سرور بررسی شوند.

فهرست مطالب

• SSH چیست و چرا باید ایمن شود؟
• پیش‌نیازهای تغییر تنظیمات
• تهیه نسخه پشتیبان از پیکربندی
• ساخت کاربر مدیریتی
• فعال‌سازی SSH Key
• بستن ورود Root و رمز عبور
• محدودسازی کاربران و تلاش‌های ورود
• تغییر پورت SSH
• تنظیم فایروال و Fail2ban
• بررسی لاگ‌ها و آزمایش تنظیمات
• چک‌لیست امنیت SSH
• جمع‌بندی
• سؤالات متداول

SSH چیست و چرا تنظیمات پیش‌فرض آن کافی نیست؟

SSH یا Secure Shell پروتکلی برای مدیریت امن سرور از راه دور است. مدیر سرور از طریق آن می‌تواند فرمان اجرا کند، فایل انتقال دهد، سرویس‌ها را مدیریت کند و تنظیمات سیستم‌عامل را تغییر دهد.

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

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

تنظیمات اصلی OpenSSH Server معمولاً در فایل زیر قرار دارند:

/etc/ssh/sshd_config

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

/etc/ssh/sshd_config.d/*.conf

در Ubuntu استفاده از فایل‌های Snippet داخل sshd_config.d می‌تواند تغییرات اختصاصی را از تنظیمات اصلی جدا کند. باید توجه داشت که در بسیاری از گزینه‌های OpenSSH، اولین مقدار مؤثر در ترتیب پردازش اهمیت دارد؛ بنابراین تنظیمات فایل‌های Include را نیز بررسی کنید. Ubuntu Server documentation

اگر سرور فعال و حساسی دارید و از نتیجه تغییرات SSH مطمئن نیستید، می‌توانید پیش از بستن ورود Root یا رمز عبور از کارشناسان شرکت تجارت الکترونیک نوژن برای بررسی دسترسی و پیکربندی مشاوره بگیرید.

مطالعه بیشتر: SSH چیست و چگونه به سرور متصل شویم

پیش‌نیازهای تنظیمات امنیتی SSH

تغییر اشتباه در SSH ممکن است تنها مسیر مدیریت سرور را مسدود کند. پیش از ویرایش تنظیمات، مطمئن شوید به کنسول اضطراری مانند KVM، کنسول دیتاسنتر، پنل VPS یا دسترسی فیزیکی دسترسی دارید.

این موارد را قبل از شروع آماده کنید:

• دسترسی فعلی SSH با سطح مدیریتی
• یک کاربر غیر Root با دسترسی Sudo
• کلید عمومی و خصوصی سالم
• دسترسی کنسول اضطراری
• نسخه پشتیبان فایل تنظیمات
• اطلاع از پورت فعلی SSH
• دسترسی به تنظیمات فایروال
• یک ترمینال دوم برای آزمایش اتصال جدید

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

تهیه نسخه پشتیبان از تنظیمات SSH

پیش از هر تغییر، از فایل اصلی و فایل‌های Snippet نسخه پشتیبان تهیه کنید. برای نمونه:

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

اگر از مسیر sshd_config.d استفاده می‌کنید، فایل جدید را با نام مشخصی مانند زیر ایجاد کنید:

/etc/ssh/sshd_config.d/99-security.conf

قبل از بارگذاری مجدد سرویس، ساختار تنظیمات را آزمایش کنید:

sudo sshd -t

اگر فرمان بدون خروجی پایان یابد، معمولاً خطای نحوی آشکاری پیدا نشده است. گزینه -t برای بررسی اعتبار پیکربندی و کلیدهای میزبان طراحی شده است. OpenBSD manual pages

برای مشاهده تنظیمات مؤثر می‌توانید از دستور زیر استفاده کنید:

sudo sshd -T

این فرمان به شناسایی تنظیماتی کمک می‌کند که ممکن است توسط فایل دیگری یا بخش Match تغییر کرده باشند.

ساخت کاربر مدیریتی غیر Root

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

در Ubuntu و Debian می‌توانید کاربر جدیدی ایجاد کنید:

sudo adduser serveradmin
sudo usermod -aG sudo serveradmin

در AlmaLinux، Rocky Linux یا RHEL معمولاً گروه مدیریتی wheel استفاده می‌شود:

sudo useradd -m serveradmin
sudo passwd serveradmin
sudo usermod -aG wheel serveradmin

نام serveradmin فقط نمونه است و باید با نام کاربری موردنظر جایگزین شود. پیش از بستن دسترسی Root، ورود کاربر جدید و اجرای فرمانی مانند sudo -v را در نشست جداگانه آزمایش کنید.

مطالعه بیشتر: ساخت User جدید و دادن دسترسی Sudo در Ubuntu

فعال‌سازی ورود با SSH Key

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

برای ایجاد کلید Ed25519 روی سیستم کاربر اجرا کنید:

ssh-keygen -t ed25519

مستندات Ubuntu استفاده از Ed25519 را به‌دلیل اندازه کوتاه‌تر کلید و نیاز پردازشی کمتر پیشنهاد می‌کنند. در صورت نیاز به RSA، باید اندازه کلید و سازگاری محیط نیز بررسی شود. Ubuntu Server documentation

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

ssh-copy-id serveradmin@SERVER_IP

اگر SSH روی پورت دیگری اجرا می‌شود:

ssh-copy-id -p SSH_PORT serveradmin@SERVER_IP

پس از انتقال کلید، یک نشست جدید باز کنید:

ssh serveradmin@SERVER_IP

کلید خصوصی را برای هیچ‌کس ارسال نکنید و آن را روی سرور مقصد کپی نکنید. تنها محتوای فایل دارای پسوند .pub باید در فایل authorized_keys کاربر قرار گیرد.

بررسی مجوز فایل‌های کلید

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

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

این مسیر برای کاربری با Home استاندارد نوشته شده است. اگر مسیر Home متفاوت است، فرمان‌ها را بدون بررسی اجرا نکنید.

تنظیمات امنیتی SSH و جلوگیری از ورود آن با حساب‌های غیرمجاز

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

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no

AllowUsers serveradmin

MaxAuthTries 3
LoginGraceTime 30

گزینه‌ها به‌ترتیب این کارها را انجام می‌دهند:

طبق راهنمای رسمی OpenSSH، گزینه PermitRootLogin no ورود Root را متوقف می‌کند و AllowUsers فقط به الگوهای کاربری تعیین‌شده اجازه ورود می‌دهد. OpenBSD manual pages

اگر چند مدیر دارید، همه کاربران را در یک خط وارد کنید:

AllowUsers admin1 admin2 deploy

راه دیگر، ایجاد گروه مخصوص SSH و استفاده از AllowGroups است. در این روش فقط اعضای گروه تعیین‌شده اجازه ورود خواهند داشت.

AllowGroups sshlogin

Ubuntu نیز محدودسازی دسترسی SSH با یک گروه اختصاصی را به‌عنوان روش قابل استفاده مستند کرده است. Ubuntu Server documentation

چه زمانی ورود با رمز عبور را غیرفعال کنیم؟

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

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

1. ساخت کاربر غیر Root
2. افزودن دسترسی Sudo
3. ایجاد و نصب SSH Key
4. آزمایش ورود کلیدی در ترمینال دوم
5. آزمایش فرمان‌های Sudo
6. تهیه بکاپ از تنظیمات SSH
7. غیرفعال‌کردن ورود Root و رمز عبور
8. اجرای sshd -t
9. Reload کردن سرویس
10. آزمایش مجدد بدون بستن نشست قبلی

Red Hat نیز توصیه می‌کند پیش از غیرفعال‌کردن Password Authentication، ورود کلیدی از یک سیستم دیگر آزمایش شود. Red Hat Documentation

محدودکردن قابلیت‌های غیرضروری SSH

SSH فقط برای Shell استفاده نمی‌شود و قابلیت‌هایی مانند Port Forwarding، Agent Forwarding، X11 Forwarding و Tunnel نیز دارد. اگر این قابلیت‌ها در پروژه لازم نیستند، می‌توانید پس از بررسی وابستگی‌ها آن‌ها را غیرفعال کنید.

X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no

این تنظیمات برای همه سرورها مناسب نیستند. سیستم‌های استقرار، Git، Proxy، پنل‌ها یا عملیات نگهداری ممکن است به Forwarding نیاز داشته باشند؛ بنابراین هر گزینه را جداگانه ارزیابی کنید.

برای حساب‌های سرویس می‌توان با بخش Match محدودیت اختصاصی ایجاد کرد. بخش‌های Match حساس هستند و ممکن است تنظیمات پایین فایل را فقط برای گروه خاصی اعمال کنند؛ پس خروجی sshd -T و شرایط اتصال را بررسی کنید.

آیا تغییر پورت SSH امنیت را افزایش می‌دهد؟

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

اگر قصد تغییر پورت را دارید، ترتیب امن بسیار مهم است:

1. پورت جدید را در فایروال و پنل شبکه باز کنید.
2. محدودیت‌های SELinux را در توزیع‌های مربوط بررسی کنید.
3. پورت جدید را در sshd_config تعریف کنید.
4. پیکربندی را با sshd -t آزمایش کنید.
5. سرویس را Reload کنید.
6. اتصال به پورت جدید را در نشست جداگانه آزمایش کنید.
7. فقط پس از موفقیت، پورت قبلی را ببندید.

نمونه اتصال به پورت سفارشی:

ssh -p SSH_PORT serveradmin@SERVER_IP

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

مطالعه بیشتر: آموزش تغییر پورت SSH در اوبونتو

تنظیم فایروال برای SSH

بهترین حالت این است که SSH فقط از IP یا شبکه مدیریتی مورد اعتماد قابل دسترسی باشد. اگر مدیران IP ثابت ندارند، باید از روش‌هایی مانند VPN مدیریتی، Bastion Host یا محدودسازی مناسب دیگری استفاده شود.

نمونه مجوز در UFW برای یک IP مشخص:

sudo ufw allow from ADMIN_IP to any port SSH_PORT proto tcp

قبل از فعال‌کردن UFW، حتماً قانون دسترسی فعلی SSH را ایجاد و بررسی کنید. فعال‌کردن فایروال بدون قانون صحیح می‌تواند دسترسی راه دور را قطع کند.

در سرورهای دارای پنل ابری، Security Group یا فایروال دیتاسنتر نیز باید بررسی شود. ممکن است پورت در فایروال سیستم‌عامل باز باشد اما در لایه شبکه بسته باقی بماند.

مطالعه بیشتر: آموزش فایروال UFW در لینوکس

جلوگیری از تلاش‌های مکرر با Fail2ban

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

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

پیش از فعال‌سازی موارد زیر را بررسی کنید:

• IPهای مدیریتی مورد اعتماد
• مدت مسدودسازی
• تعداد تلاش مجاز
• بازه شمارش خطاها
• پورت واقعی SSH
• محل لاگ احراز هویت
• روش Unban از طریق کنسول

مطالعه بیشتر: آموزش نصب و تنظیم Fail2ban

بارگذاری امن تنظیمات SSH

پس از ویرایش، ابتدا فایل را اعتبارسنجی کنید:

sudo sshd -t

سپس تنظیم مؤثر گزینه‌های حساس را ببینید:

sudo sshd -T | grep -E \
'permitrootlogin|passwordauthentication|pubkeyauthentication|kbdinteractiveauthentication|maxauthtries'

اگر خطایی وجود ندارد، سرویس را Reload کنید. نام سرویس در توزیع‌ها متفاوت است:

# Ubuntu و Debian
sudo systemctl reload ssh

# AlmaLinux، Rocky Linux و RHEL
sudo systemctl reload sshd

Reload معمولاً نشست موجود را حفظ می‌کند، اما تضمین بازیابی دسترسی نیست. نشست فعلی را باز نگه دارید و ورود جدید را در یک ترمینال دیگر آزمایش کنید.

مستندات Ubuntu نیز اجرای sshd -t پیش از Restart یا Reload را توصیه می‌کنند؛ زیرا از دست‌دادن SSH ممکن است تنها مسیر مدیریت سرور را از بین ببرد. Ubuntu Server documentation

بررسی لاگ‌های ورود SSH

لاگ‌ها برای تشخیص تلاش ناموفق، نام کاربری هدف، IP مبدا و علت ردشدن اتصال مفید هستند. در سیستم‌های مبتنی بر systemd می‌توانید وضعیت سرویس را بررسی کنید:

sudo journalctl -u ssh --since today

در بعضی توزیع‌ها نام Unit برابر sshd است:

sudo journalctl -u sshd --since today

مسیر فایل‌های لاگ نیز به توزیع وابسته است. Ubuntu معمولاً رویدادهای احراز هویت را در /var/log/auth.log و خانواده RHEL در /var/log/secure ثبت می‌کنند.

برای پایش فقط به تلاش‌های ناموفق اکتفا نکنید. ورود موفق از IP ناشناس، تغییر فایل authorized_keys، ایجاد کاربر جدید و استفاده غیرمنتظره از Sudo نیز باید بررسی شوند.

مطالعه بیشتر: آموزش بررسی لاگ‌های لینوکس با Journalctl

استفاده از احراز هویت دومرحله‌ای

برای سرورهای حساس می‌توان علاوه بر SSH Key از عامل دوم مانند کلید سخت‌افزاری FIDO/U2F یا رمز یک‌بارمصرف استفاده کرد. این روش در صورت سرقت کلید خصوصی، مانع دیگری مقابل مهاجم قرار می‌دهد.

پیاده‌سازی MFA ممکن است با PAM، تنظیمات AuthenticationMethods و روش ورود اضطراری ارتباط داشته باشد. قبل از اعمال روی سرور اصلی، آن را در محیط آزمایشی بررسی کنید.

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

اقدامات تکمیلی برای امنیت SSH

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

اقدامات تکمیلی عبارت‌اند از:

• نصب به‌روزرسانی‌های امنیتی سیستم‌عامل
• حذف یا قفل‌کردن حساب‌های بلااستفاده
• استفاده از Passphrase برای کلید خصوصی
• نگهداری کلیدها در ابزار امن
• لغو سریع کلید کارکنان سابق
• محدودکردن دسترسی Sudo
• مانیتورینگ فایل authorized_keys
• تنظیم هشدار برای ورودهای حساس
• استفاده از کنسول خارج از باند
• مستندسازی کاربران و پورت‌ها
• تهیه بکاپ از تنظیمات
• آزمایش دوره‌ای فرایند بازیابی

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

سناریوی نمونه ایمن‌سازی SSH

فرض کنید یک VPS جدید با ورود Root و رمز عبور تحویل گرفته‌اید. ابتدا با دسترسی موجود وارد شده و یک کاربر دارای Sudo ایجاد می‌کنید.

در مرحله بعد، کلید عمومی مدیر را به حساب جدید منتقل کرده و از یک ترمینال دوم وارد می‌شوید. پس از آزمایش Sudo، از فایل تنظیمات بکاپ گرفته و ورود Root و Password Authentication را غیرفعال می‌کنید.

سپس sshd -t و sshd -T اجرا می‌شوند. بعد از Reload، اتصال جدید با کلید آزمایش می‌شود و نشست قبلی تا پایان این تست باز باقی می‌ماند.

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

چک‌لیست امنیت SSH

• دسترسی کنسول اضطراری در اختیار است.
• از تنظیمات SSH نسخه پشتیبان تهیه شده است.
• کاربر غیر Root با دسترسی Sudo ساخته شده است.
• ورود با SSH Key در نشست جداگانه آزمایش شده است.
• کلید خصوصی دارای Passphrase و محل نگهداری امن است.
• ورود مستقیم Root محدود شده است.
• ورود رمزی فقط پس از آزمایش کلید بسته شده است.
• کاربران یا گروه‌های مجاز مشخص شده‌اند.
• قابلیت‌های Forwarding غیرضروری بررسی شده‌اند.
• قانون فایروال پیش از تغییر پورت ساخته شده است.
• پیکربندی با sshd -t آزمایش شده است.
• تنظیمات مؤثر با sshd -T بررسی شده‌اند.
• نشست قبلی تا پایان تست باز مانده است.
• Fail2ban یا محدودسازی شبکه پیکربندی شده است.
• لاگ‌های ورود موفق و ناموفق پایش می‌شوند.
• کلیدها و حساب‌های قدیمی حذف شده‌اند.
• بکاپ و روش بازیابی دوره‌ای آزمایش می‌شوند.

جمع‌بندی تنظیمات امنیتی SSH و جلوگیری از ورود آن

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

مهم‌ترین اصل، حفظ دسترسی هنگام اعمال تغییرات است. ابتدا کاربر Sudo و ورود کلیدی را در نشست دوم آزمایش کنید، سپس Password Authentication را غیرفعال کرده و پیش از Reload، دستور sshd -t را اجرا کنید.

تغییر پورت و Fail2ban ابزارهای کمکی هستند و جایگزین احراز هویت قوی نمی‌شوند. برای سرورهای حساس، محدودسازی شبکه، MFA، دسترسی کنسول و برنامه بازیابی نیز باید در طراحی امنیت لحاظ شوند.

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

سؤالات متداول

آیا غیرفعال‌کردن ورود Root ضروری است؟

برای بیشتر سرورها توصیه می‌شود مدیریت روزانه با کاربر دارای Sudo انجام شود. قبل از بستن Root، ورود و دسترسی Sudo کاربر جایگزین را آزمایش کنید.

چه زمانی Password Authentication را غیرفعال کنیم؟

فقط پس از آنکه ورود با SSH Key برای تمام مدیران در یک نشست جدید با موفقیت آزمایش شده و دسترسی کنسول اضطراری آماده باشد.

آیا تغییر پورت SSH جلوی هک را می‌گیرد؟

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

تفاوت sshd -t و sshd -T چیست؟

گزینه -t صحت ساختار تنظیمات را آزمایش می‌کند. گزینه -T علاوه بر آزمایش، پیکربندی مؤثر سرویس را در خروجی نمایش می‌دهد.

چرا پس از غیرفعال‌کردن رمز هنوز ورود رمزی ممکن است؟

ممکن است فایل Snippet، بخش Match یا احراز هویت تعاملی فعال باشد. خروجی sshd -T و گزینه KbdInteractiveAuthentication را بررسی کنید.

آیا Fail2ban برای امنیت SSH کافی است؟

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

اگر بعد از تغییر تنظیمات دسترسی SSH قطع شد چه کنیم؟

از کنسول KVM یا پنل ارائه‌دهنده وارد شوید، فایل پشتیبان را بازگردانید، تنظیمات را با sshd -t بررسی و سپس سرویس را Reload کنید.