۱۰ تنظیم مهم برای امن‌سازی SSH Server در لینوکس

SSH معمولاً یکی از مهم‌ترین راه‌های مدیریت یک سرور لینوکسی است.

با دستوری مثل:

ssh user@SERVER_IP

می‌تونیم از راه دور به سرور متصل بشیم، تنظیمات را تغییر دهیم، سرویس‌ها را مدیریت کنیم، فایل انتقال دهیم و حتی Deployment انجام بدیم.

همین اهمیت باعث میشه SSH یکی از سرویس‌هایی باشه که روی یک سرور عمومی باید با دقت بیشتری تنظیم شود.

اما امن‌سازی SSH به معنی تغییر چند خط در sshd_config و بستن Port 22 نیست!

یک SSH Server امن‌تر معمولاً چند لایه دارد:

Updates
+
SSH Key
+
Access Control
+
Firewall
+
Safe sshd Configuration
+
Monitoring

در این مقاله ۱۰ تنظیم و اقدام مهم را بررسی می‌کنیم که برای بسیاری از VPSها و Linux Serverهای متصل به اینترنت نقطه شروع خوبی هستند.

هیچ Configuration امنیتی برای همه Serverها یکسان نیست. اگر از MFA، Bastion Host، SSH Tunneling، Automation یا سرویس‌های خاص استفاده می‌کنید، بعضی تنظیمات این مقاله باید متناسب با همان معماری تغییر کنند.

قبل از Hardening، دسترسی خودتان را قطع نکنید!

قبل از هر تغییری یک قانون مهم داریم:

SSH Session فعلی را باز نگه دارید.

اگر قرار است Authentication یا Firewall را تغییر دهید، یک Terminal دوم برای تست داشته باشید.

در صورت امکان، مطمئن شوید Provider سرور روشی مثل:

Web Console
VNC
Serial Console
Recovery Console

برای دسترسی اضطراری در اختیارتان قرار می‌دهد.

قبل از Restart یا Reload کردن OpenSSH نیز Configuration را بررسی کنید:

sudo sshd -t

اگر این دستور بدون Error برگردد، Configuration از نظر Syntax معتبر است.

همچنین برای مشاهده بسیاری از تنظیمات مؤثر:

sudo sshd -T

بسیار کاربردی است.

در Ubuntu می‌توانید تنظیمات اختصاصی خود را به‌جای دستکاری زیاد فایل اصلی، داخل:

/etc/ssh/sshd_config.d/

قرار دهید.

۱. سیستم و OpenSSH را به‌روز نگه دارید

اولین اقدام امنیتی قبل از هر Hardening پیچیده‌ای، نصب Security Updateهاست.

در Ubuntu و Debian:

sudo apt update

سپس بسته‌های قابل Upgrade را ببینید:

apt list --upgradable

و Updateها را طبق سیاست نگهداری Server اعمال کنید:

sudo apt upgrade

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

ssh -V

و Package نصب‌شده روی Ubuntu:

apt policy openssh-server

چرا این مرحله مهم است؟

چون حتی بهترین Configuration هم نمی‌تواند Vulnerability موجود در خود Software را جبران کند.

در سپتامبر ۲۰۲۶ نیز Ubuntu چند مشکل امنیتی OpenSSH را برای نسخه‌های پشتیبانی‌شده خود اصلاح کرد؛ نمونه خوبی از اینکه Patch Management بخشی از SSH Hardening است، نه کاری جدا از آن.

آیا همیشه فوراً Upgrade کنیم؟

روی Production Server بهتر است Updateها مدیریت‌شده باشند.

یعنی:

Backup
↓
Review Update
↓
Apply
↓
Verify Services

نه اینکه بدون بررسی هر Upgrade بزرگی را روی Server حساس اجرا کنید.

۲. از SSH Key استفاده کنید و Password Login را ببندید

برای بسیاری از VPSهای مدیریتی، یکی از مهم‌ترین تغییرات این است:

Password Login
✗

SSH Key
✓

ابتدا باید Public Key کاربر به Server اضافه شده باشد و Login با Key واقعاً کار کند.

بعد می‌توانید Configuration را بررسی کنید:

sudo sshd -T | grep -Ei '^(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication)'

برای یک Server معمولی که فقط با SSH Key مدیریت می‌شود، Configuration می‌تواند چیزی شبیه این باشد:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

اما قبل از اعمال این تنظیم حتماً از Terminal دوم با SSH Key وارد شوید.

اگر از MFA مبتنی بر PAM یا Keyboard Interactive استفاده می‌کنید، KbdInteractiveAuthentication را کورکورانه غیرفعال نکنید.

بعد از تغییر:

sudo sshd -t

و سپس Configuration را Reload کنید.

در Ubuntu:

sudo systemctl reload ssh

OpenSSH به‌صورت مستقیم PasswordAuthentication و PubkeyAuthentication را برای کنترل این روش‌های احراز هویت ارائه می‌کند.

۳. Login مستقیم Root را محدود کنید

Root بالاترین سطح دسترسی را روی Linux دارد.

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

ssh root@SERVER_IP

وارد نشود.

به‌جای آن:

SSH
↓
Normal Admin User
↓
sudo

ساختار مناسب‌تری است.

ابتدا مطمئن شوید User مدیریتی شما sudo دارد:

sudo whoami

باید خروجی:

root

باشد.

سپس وضعیت Root Login را بررسی کنید:

sudo sshd -T | grep -i permitrootlogin

برای جلوگیری کامل از Login مستقیم Root:

PermitRootLogin no

را می‌توان در نظر گرفت.

OpenSSH در حال حاضر مقدار پیش‌فرض PermitRootLogin را prohibit-password تعریف می‌کند؛ یعنی Password و Keyboard Interactive برای Root ممنوع‌اند، ولی Public Key ممکن است همچنان مجاز باشد.

اگر سیاست شما این است که Root اصلاً Remote Login نداشته باشد:

PermitRootLogin no

صریح‌تر است.

هشدار!

قبل از این تغییر مطمئن شوید:

Admin User Login ✓
SSH Key ✓
sudo ✓

در غیر این صورت ممکن است خودتان را از Server خارج کنید.

۴. مشخص کنید چه Userهایی اجازه SSH دارند

روی بسیاری از Serverها همه Accountهای Linux نیازی به SSH ندارند.

فرض کنید فقط دو User:

deploy
admin

باید بتوانند Remote Login داشته باشند.

می‌توانید از:

AllowUsers

استفاده کنید:

AllowUsers deploy admin

در این حالت فقط Userهای مشخص‌شده اجازه SSH Login خواهند داشت.

OpenSSH همچنین:

AllowGroups
DenyUsers
DenyGroups

را ارائه می‌کند.

مثلاً اگر Group مخصوص SSH ساخته باشید:

AllowGroups ssh-users

می‌تواند مدیریت تعداد زیادی User را ساده‌تر کند.

قبل از فعال‌سازی AllowUsers چه کنیم؟

اول نام User فعلی خودتان را بررسی کنید:

whoami

و مطمئن شوید Userی که با آن Server را مدیریت می‌کنید در Rule وجود دارد.

مثلاً اگر فقط:

AllowUsers deploy

قرار دهید و خودتان با User:

admin

متصل باشید، Login بعدی شما Fail خواهد شد.

۵. SSH را در Firewall فقط به اندازه نیاز باز کنید

یکی از مؤثرترین لایه‌های امنیتی این است که Traffic نامطلوب اصلاً به sshd نرسد.

در Ubuntu وضعیت UFW:

sudo ufw status verbose

را بررسی کنید.

اگر SSH روی Port 22 قرار دارد:

sudo ufw allow 22/tcp

یک Rule عمومی ایجاد می‌کند.

اما اگر Administrator همیشه از Public IP ثابت مشخصی متصل می‌شود، می‌توانید دسترسی را محدودتر کنید:

sudo ufw allow proto tcp from YOUR_PUBLIC_IP to any port 22

مثلاً:

sudo ufw allow proto tcp from 198.51.100.20 to any port 22

Ubuntu نیز UFW را برای محدودکردن دسترسی Port به Host یا Subnet مشخص پشتیبانی می‌کند.

ساختار نتیجه:

Internet
│
├── Unknown IP ✗
│
└── Admin IP ✓
        ↓
       SSH

چه زمانی این کار مناسب نیست؟

اگر Public IP شما مرتب تغییر می‌کند یا تیم از چند Location کار می‌کند، محدودکردن SSH به یک IP می‌تواند دردسر ایجاد کند.

در این شرایط ممکن است گزینه‌های زیر مناسب‌تر باشند:

VPN
Bastion Host
Company IP Range
Cloud Firewall

و فراموش نکنید اگر Provider شما Cloud Firewall جداگانه دارد، Ruleهای آن هم باید بررسی شوند.

۶. تعداد تلاش‌های Authentication را محدود کنید

OpenSSH به‌صورت پیش‌فرض تعداد مشخصی Authentication Attempt برای هر Connection اجازه می‌دهد.

مقدار فعلی را ببینید:

sudo sshd -T | grep -i maxauthtries

OpenSSH مقدار پیش‌فرض:

MaxAuthTries 6

را دارد.

برای Server مدیریتی ساده می‌توانید مقدار محدودتری مثل:

MaxAuthTries 3

را بررسی کنید.

این یعنی یک Connection فرصت کمتری برای Authentication ناموفق خواهد داشت.

همچنین:

LoginGraceTime

مشخص می‌کند Client چه مدت فرصت دارد Authentication را کامل کند.

مقدار پیش‌فرض OpenSSH در حال حاضر:

120 seconds

است.

برای مثال:

LoginGraceTime 30

می‌تواند Window مربوط به Connectionهای احراز هویت‌نشده را کوتاه‌تر کند.

Configuration نمونه:

MaxAuthTries 3
LoginGraceTime 30

مقدار کمتر همیشه بهتر نیست

اگر Authentication پیچیده، MFA یا Connection کند دارید، مقادیر بسیار سخت‌گیرانه می‌توانند User واقعی را هم اذیت کنند.

هدف:

محدودکردن سطح حمله بدون خراب‌کردن Login قانونی.

۷. تعداد Connectionهای احراز هویت‌نشده را کنترل کنید

Directive دیگری که کمتر به آن توجه می‌شود:

MaxStartups

است.

این گزینه تعداد Connectionهای هم‌زمانی را کنترل می‌کند که هنوز Authentication آن‌ها کامل نشده است.

OpenSSH مقدار پیش‌فرض:

10:30:100

را استفاده می‌کند.

ساختار این مقدار به‌صورت:

start:rate:full

است.

یعنی OpenSSH بعد از رسیدن Connectionهای unauthenticated به Threshold اولیه، شروع به Drop تصادفی Connectionهای جدید می‌کند و با افزایش تعداد، محدودیت سخت‌تر می‌شود.

برای بیشتر Serverهای کوچک لازم نیست بدون دلیل این مقدار را تغییر دهید.

اما دانستن آن مهم است؛ خصوصاً برای Serverهایی که:

• SSH مستقیماً روی اینترنت باز است

• Scanner زیاد دریافت می‌کنند

• تعداد Administrator واقعی کمی دارند

روی نسخه‌های جدید OpenSSH مکانیزم‌های بیشتری برای اعمال Penalty به Sourceهای مشکل‌دار هم وجود دارد، ولی Availability آن‌ها به نسخه OpenSSH Distribution شما بستگی دارد.

۸. قابلیت‌های Forwarding غیرضروری را غیرفعال کنید

SSH فقط Remote Shell نیست.

می‌تواند قابلیت‌هایی مثل:

TCP Forwarding
Agent Forwarding
X11 Forwarding

را نیز ارائه کند.

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

برای بررسی:

sudo sshd -T | grep -Ei '^(allowtcpforwarding|allowagentforwarding|x11forwarding)'

بسته به نیاز Server می‌توانید مواردی مثل:

AllowAgentForwarding no
X11Forwarding no

را در نظر بگیرید.

و اگر اصلاً از SSH Tunnel استفاده نمی‌کنید:

AllowTcpForwarding no

هم قابل بررسی است.

OpenSSH گزینه DisableForwarding را هم برای غیرفعال‌کردن انواع Forwarding دارد.

این تنظیم را کورکورانه انجام ندهید!

ممکن است Deployment یا Workflow شما از:

SSH Tunnel
Agent Forwarding
Remote Forwarding

استفاده کند.

مثلاً اگر Developer با:

ssh -L ...

به Database داخلی Tunnel می‌زند، غیرفعال‌کردن TCP Forwarding آن Workflow را خراب می‌کند.

پس این بخش یک قانون ساده دارد:

Featureهایی را که نمی‌شناسید فعال نگذارید؛ ولی Featureهایی را که استفاده می‌کنید هم بدون بررسی نبندید.

۹. تغییر Port SSH را فقط یک لایه جانبی بدانید

Port استاندارد SSH:

22

است.

می‌توانید آن را مثلاً به:

2222

تغییر دهید.

در نتیجه بسیاری از Botهای ساده‌ای که فقط Port 22 را Scan می‌کنند دیگر مستقیماً SSH شما را پیدا نمی‌کنند.

اما این کار یک کنترل امنیتی اصلی نیست.

Port Scanner می‌تواند Port جدید را هم پیدا کند.

پس:

Change Port
≠
Secure SSH

تغییر Port بیشتر می‌تواند:

• Noise Log را کاهش دهد

• Scanهای ساده را کم کند

• تعداد تلاش‌های تصادفی روی 22 را کاهش دهد

اما جایگزین این موارد نیست:

SSH Key
Password Disabled
Firewall
Root Restriction
Updates

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

Port جدید را ابتدا در Firewall باز و Test کنید و فقط بعد از Login موفق، Port قبلی را ببندید.

۱۰. Logها را Monitor کنید و رفتار غیرعادی را ببینید

Hardening بدون Monitoring کامل نیست.

اگر حمله یا Login مشکوکی رخ دهد، باید بتوانید آن را ببینید.

در Ubuntu:

sudo journalctl -u ssh.service

برای دنبال‌کردن Log به‌صورت زنده:

sudo journalctl -fu ssh.service

می‌توانید Loginهای اخیر را نیز ببینید:

last

و تلاش‌های ناموفق بسته به Distribution و Log Configuration ممکن است در Journal یا فایل‌های Authentication ثبت شوند.

برای بررسی LogLevel مؤثر:

sudo sshd -T | grep -i loglevel

مقدار پیش‌فرض OpenSSH:

INFO

است.

در محیط‌هایی که Audit بیشتری لازم دارند می‌توان VERBOSE را بررسی کرد:

LogLevel VERBOSE

اما برای Production بی‌دلیل سراغ:

DEBUG
DEBUG2
DEBUG3

نروید.

OpenSSH هشدار می‌دهد Logging در سطح DEBUG می‌تواند حریم خصوصی کاربران را نقض کند و برای استفاده دائمی توصیه نمی‌شود.

Fail2ban لازم است؟

Fail2ban می‌تواند Logها را بررسی کند و Sourceهایی را که رفتار نامطلوب دارند به‌طور موقت در Firewall Block کند.

روی Serverهایی که SSH برای کل اینترنت باز است، این ابزار می‌تواند مکمل مفیدی باشد.

اما Fail2ban را جایگزین:

SSH Key
Firewall
Access Control
Updates

نکنید.

اگر Password Login از قبل غیرفعال است، Fail2ban هنوز می‌تواند Noise و Sourceهای مزاحم را کنترل کند، ولی امنیت SSH شما نباید فقط به Ban کردن IPها وابسته باشد.

یک Configuration نمونه برای VPS مدیریتی ساده

فرض کنیم شرایط Server این است:

• فقط دو Administrator دارد

• ورود فقط با SSH Key انجام می‌شود

• MFA مبتنی بر Keyboard Interactive نداریم

• Root Login نیاز نیست

• X11 و Agent Forwarding استفاده نمی‌شوند

• TCP Tunnel هم نیاز نداریم

می‌توانیم Snippetی مثل این بسازیم:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

و به‌عنوان نقطه شروع:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

PermitRootLogin no

AllowUsers deploy admin

MaxAuthTries 3
LoginGraceTime 30

AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no

LogLevel VERBOSE

قرار دهیم.

این فایل را بدون تغییر کپی نکنید.

حداقل این بخش:

AllowUsers deploy admin

باید متناسب با Userهای واقعی Server شما باشد.

اگر از:

MFA
SSH Tunnel
Agent Forwarding
Ansible
Automated Deployment

استفاده می‌کنید، بعضی گزینه‌ها باید تغییر کنند.

قبل از اعمال Hardening این سه Command را اجرا کنید

اول Backup:

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

سپس Syntax:

sudo sshd -t

و Configuration مؤثر:

sudo sshd -T

برای بررسی تنظیمات مهم:

sudo sshd -T | grep -Ei '^(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitrootlogin|allowusers|maxauthtries|logingracetime|allowagentforwarding|allowtcpforwarding|x11forwarding|loglevel)'

اگر خروجی مطابق انتظار بود، در Ubuntu:

sudo systemctl reload ssh

را انجام دهید.

Session فعلی را نبندید.

بعد از Hardening حتماً Login جدید را تست کنید

در Terminal دوم:

ssh user@SERVER_IP

یا اگر Port سفارشی دارید:

ssh -p 2222 user@SERVER_IP

بعد از Login:

whoami

و:

sudo whoami

را بررسی کنید.

اگر خروجی دوم:

root

است، User مدیریتی شما دسترسی موردنیاز را دارد.

بعد می‌توانید Session قبلی را ببندید.

ترتیب پیشنهادی Hardening برای یک VPS جدید

همه تنظیمات را یک‌باره عوض نکنید.

ترتیب بهتر:

1. Update Server
↓
2. Create Admin User
↓
3. Add SSH Key
↓
4. Test Key Login
↓
5. Configure Firewall
↓
6. Disable Password Login
↓
7. Disable Root Login
↓
8. Restrict SSH Users
↓
9. Tune Remaining SSH Settings
↓
10. Monitor Logs

مزیت این روش این است که بعد از هر تغییر می‌توانید نتیجه را Verify کنید.

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

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

• Linux و OpenSSH به‌روز هستند

• User مدیریتی غیر Root دارم

• Login با SSH Key کار می‌کند

• Password Login در صورت عدم نیاز غیرفعال شده

• Root Login طبق Policy محدود شده

• فقط User یا Groupهای لازم SSH Access دارند

• Firewall فقط Port موردنیاز را باز کرده

• در صورت امکان Source IP محدود شده

• MaxAuthTries و LoginGraceTime بررسی شده‌اند

• Forwardingهای غیرضروری بسته شده‌اند

• Configuration با sshd -t تست شده

• Effective Config با sshd -T بررسی شده

• Login جدید قبل از بستن Session قدیمی تست شده

• SSH Logها Monitor می‌شوند

• Recovery/Console Access در صورت امکان در دسترس است

کدام تنظیم‌ها برای همه سرورها لازم نیستند؟

این نکته مهم است.

Hardening نباید تبدیل شود به:

هرچه بیشتر ببندیم = امن‌تر

مثلاً:

AllowTcpForwarding no

برای Serverی که از SSH Tunnel استفاده می‌کند مناسب نیست.

KbdInteractiveAuthentication no

ممکن است MFA شما را از کار بیندازد.

محدودکردن Firewall به یک IP

برای تیمی که دائماً از Locationهای متفاوت کار می‌کند شاید عملی نباشد.

تغییر Port SSH

اجباری نیست و امنیت اصلی شما نباید به آن وابسته باشد.

Fail2ban

برای همه Serverها ضرورت یکسان ندارد.

Hardening خوب یعنی:

حداقل دسترسی لازم را حفظ کنیم، بدون اینکه Workflow واقعی Server را خراب کنیم.

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

نوع Error سرنخ اصلی است.

اگر می‌بینید:

Permission denied (publickey)

Connection به SSH رسیده ولی Authentication مشکل دارد.

مواردی مثل:

SSH Key
Username
authorized_keys
Permissions
AllowUsers

را بررسی کنید.

اگر می‌بینید:

Connection refused

روی:

SSH Service
Listener
Port

تمرکز کنید.

اگر می‌بینید:

Connection timed out

احتمال:

Firewall
Cloud Firewall
Network
Routing

بیشتر است.

به همین دلیل نگه‌داشتن یک Session سالم هنگام Hardening اهمیت زیادی دارد.

آیا تغییر Port SSH از SSH Key مهم‌تر است؟

خیر.

اگر مجبور باشیم بین این دو اولویت انتخاب کنیم:

SSH Key + Disable Password

اهمیت بسیار بیشتری نسبت به صرفاً:

22 → 2222

دارد.

Port غیر استاندارد یک لایه جانبی است.

Authentication قوی و محدودکردن دسترسی، کنترل امنیتی بنیادی‌تری محسوب می‌شوند.

امن‌سازی SSH یک کار یک‌باره نیست

ممکن است امروز Server را Hardening کنید و همه‌چیز درست باشد.

اما چند ماه بعد:

• User جدید اضافه شود

• Key کارمند سابق باقی بماند

• Firewall Rule جدید ایجاد شود

• Software قدیمی شود

• Automation نیاز به دسترسی جدید پیدا کند

• Configuration موقت فراموش شود

بنابراین SSH Security باید دوره‌ای Review شود.

مثلاً بررسی کنید:

sudo sshd -T

Public Keyهای مجاز:

cat ~/.ssh/authorized_keys

Listenerها:

sudo ss -tlnp

Firewall:

sudo ufw status numbered

و Loginها:

last

همچنان با Policy مورد انتظار شما مطابقت دارند.

جمع‌بندی

برای امن‌سازی SSH Server یک «Directive جادویی» وجود ندارد.

بهترین نتیجه از ترکیب چند لایه به دست می‌آید:

Patch Management
+
SSH Keys
+
No Unnecessary Password Login
+
No Unnecessary Root Login
+
User Restrictions
+
Firewall
+
Authentication Limits
+
Minimal SSH Features
+
Monitoring

اگر تازه Server را راه‌اندازی کرده‌اید، اولویت پیشنهادی این است:

1. Server را Update کنید

2. یک Admin User مناسب بسازید

3. SSH Key را تنظیم و تست کنید

4. Firewall را فعال کنید

5. Password Login را در صورت عدم نیاز ببندید

6. Root Login را محدود کنید

7. دسترسی Userها را محدود کنید

8. تنظیمات باقی‌مانده SSH را متناسب با Workflow خود Hardening کنید

9. Logها را Monitor کنید

10. هر چند وقت یک‌بار Configuration را Review کنید

و مهم‌تر از همه:

هیچ تغییر حساس SSH را بدون Session جایگزین، تست sshd -t و Login آزمایشی در Terminal دوم اعمال نکنید.

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

مهم‌ترین تنظیم برای افزایش امنیت SSH چیست؟

یک تنظیم به‌تنهایی کافی نیست، اما برای بسیاری از VPSها استفاده از SSH Key و غیرفعال کردن Password Login یکی از مهم‌ترین اقدامات اولیه است.

آیا باید Port 22 را تغییر دهیم؟

اجباری نیست. تغییر Port می‌تواند Noise و Scanهای ساده را کاهش دهد، اما جایگزین SSH Key، Firewall و Access Control نیست.

آیا باید Root Login را غیرفعال کنیم؟

اگر Admin User مناسب با sudo دارید و نیاز عملی به Root Login مستقیم وجود ندارد، PermitRootLogin no می‌تواند سطح دسترسی SSH را محدودتر کند.

مقدار مناسب MaxAuthTries چیست؟

OpenSSH به‌صورت پیش‌فرض 6 استفاده می‌کند. روی Server مدیریتی ساده می‌توان مقدار محدودتری مثل 3 را بررسی کرد، اما باید با Authentication واقعی Server سازگار باشد.

آیا Fail2ban برای SSH ضروری است؟

برای همه Serverها الزام نیست. می‌تواند برای کنترل Sourceهای مزاحم مفید باشد، اما نباید جای SSH Key، Firewall یا Updateها را بگیرد.

بعد از تغییر sshd_config چه کنیم؟

ابتدا:

sudo sshd -t

را اجرا کنید. سپس Configuration مؤثر را با:

sudo sshd -T

بررسی کنید و فقط بعد Configuration را Reload کنید.

چطور بفهمیم SSH ما واقعاً امن شده است؟

یک معیار واحد وجود ندارد. Authentication، User Access، Firewall، Software Updates، Forwarding، Logging و Recovery Access را با هم بررسی کنید.