مقدمه

قطع SSH پس از تغییر Authentication می‌تواند یک سرور سالم را از دسترس تیم عملیات خارج کند. هدف این runbook اعمال کنترل دسترسی همراه با آزمون ورود مستقل و مسیر بازیابی است.

مثال عملی

تیم عملیات ۴۰ VM را از bastion در subnet مدیریت 10.20.30.0/24 اداره می‌کند. ورود عمومی اینترنتی بسته است و تغییر ابتدا روی یک canary انجام می‌شود.

پیش‌نیازها

Ubuntu Server 24.04 LTS، Bash 5، systemd؛ package patch را پیش از تغییر با dpkg-query ثبت کنید.

سخت‌افزار و ظرفیت: برای مثال یک VM با ۲ vCPU، ۲ GiB RAM و ۲۰ GiB دیسک؛ این ظرفیت پیشنهادی آزمایشگاه است و sizing سرویس به بار واقعی وابسته است.

نرم‌افزار و دسترسی: openssh-server روی سرور و openssh-client روی workstation؛ sudo و console مجاز. نام opsadmin و آدرس 10.20.30.10 نمونه‌اند و باید با مقادیر سازمان جایگزین شوند.

Architecture / Design

Workstation → VPN/MFA → Bastion → Firewall مدیریت → sshd → حساب شخصی → sudo. کلید خصوصی روی workstation می‌ماند و fingerprint سرور از console تأیید می‌شود.

Installation / Configuration

ابتدا نسخه، listener و سرویس را ثبت کنید. نصب فقط بسته SSH را تغییر می‌دهد؛ full upgrade را به این تغییر وابسته نکنید.

sudo apt-get update
sudo apt-get install -y openssh-server
dpkg-query -W openssh-server
systemctl status ssh.service ssh.socket --no-pager
sudo ss -lntp '( sport = :22 )'
sudo cp -a /etc/ssh /root/ssh-before-change

روی workstation کلید passphraseدار بسازید و آن را برای حسابی که از قبل ایجاد شده نصب کنید. fingerprint را قبل از تأیید اتصال مقایسه کنید.

ssh-keygen -t ed25519 -f "$HOME/.ssh/ops_ed25519"
ssh-copy-id -i "$HOME/.ssh/ops_ed25519.pub" opsadmin@10.20.30.10
ssh -i "$HOME/.ssh/ops_ed25519" -o PasswordAuthentication=no opsadmin@10.20.30.10

در همان حساب روی سرور، مالکیت و permission را بررسی کنید. پس از موفقیت نشست دوم، از نشست مدیریتی دارای sudo تنظیم زیر را بنویسید.

chmod 700 "$HOME/.ssh"
chmod 600 "$HOME/.ssh/authorized_keys"
sudo tee /etc/ssh/sshd_config.d/00-enterprise.conf >/dev/null <<'EOF'
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowUsers opsadmin
X11Forwarding no
MaxAuthTries 3
EOF
sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T | grep -E 'permitrootlogin|passwordauthentication|allowusers'
sudo systemctl reload ssh.service

sshd -t در موفقیت خروجی ندارد؛ -T باید passwordauthentication no نشان دهد. نشست اول را باز نگه دارید و ورود با کلید و sudo در نشست سوم را امتحان کنید. AllowUsers را پیش از اجرا با فهرست حساب‌های انسانی و automation تطبیق دهید.

Security Hardening

محدودیت TCP/22 در firewall بالادستی به bastion اعمال شود. نمونه ufw allow from 10.20.30.0/24 to any port 22 proto tcp فقط روی میزبان با UFW موجود قابل اعمال است؛ firewall خاموش را از راه دور بدون طراحی فعال نکنید. تغییر پورت جای احراز هویت را نمی‌گیرد. MFA روی bastion برقرار باشد؛ اگر PAM MFA روی خود SSH دارید KbdInteractiveAuthentication no را با طراحی آن تطبیق دهید. در سیاست FIPS، پذیرش Ed25519 را بررسی و در صورت نیاز RSA با امضای SHA-2 انتخاب کنید.

Monitoring

journalctl -u ssh.service --since "15 minutes ago" منبع بررسی login است. در Zabbix آزمون TCP و آزمون ورود مجاز جدا باشند؛ بیش از ۱۰ failed login در ۵ دقیقه آستانه نمونه است. Alert باید hostname، source IP و زمان UTC داشته باشد؛ private key و token وارد لاگ نشوند.

Troubleshooting

Connection refused یعنی listener یا مسیر reject؛ timeout بیشتر به routing/drop اشاره دارد. با دستورات زیر ابتدا server و client را جدا بررسی کنید.

sudo journalctl -u ssh.service -n 100 --no-pager
sudo /usr/sbin/sshd -T
ssh -vvv -i "$HOME/.ssh/ops_ed25519" opsadmin@10.20.30.10

Permission denied همراه با bad ownership در log: مالک HOME و .ssh را اصلاح کنید. کلید معتبر ولی ردشده: AllowUsers، Match و تنظیم مؤثر -T -C را بررسی کنید. Ubuntu ممکن است از ssh.socket استفاده کند؛ برای تغییر Port علاوه بر sshd، listener socket را طبق مستندات همان patch بررسی کنید. این runbook پورت را تغییر نمی‌دهد.

Backup / Recovery

Backup از /etc/ssh حاوی host key است و باید رمزنگاری و محدود شود. برای rollback این تغییر از console یا نشست باز فقط snippet جدید را خارج کنید؛ سپس validate و reload کنید.

sudo mv /etc/ssh/sshd_config.d/00-enterprise.conf /root/00-enterprise.conf.failed
sudo /usr/sbin/sshd -t
sudo systemctl reload ssh.service

اگر تنظیم قبلی تغییر کرده، نسخه ثبت‌شده را از backup برگردانید. بازیابی VM نباید host key تکراری بین سرورهای متفاوت ایجاد کند.

Best Practices

حساب‌های شخصی، کلید با passphrase، حذف کلید کارکنان جداشده و بازبینی sudo را در یک lifecycle نگه دارید. قبل از بستن آخرین نشست، login، privilege و audit را از مسیر واقعی management تأیید کنید.

نسخه‌های قدیمی و Compatibility

دستورهای Ubuntu را برای RHEL عیناً اجرا نکنید؛ نام سرویس معمولاً sshd و package manager متفاوت است. توصیه قدیمی PermitRootLogin yes برای Production کنار گذاشته شده است. restart لزوماً همه نشست‌های برقرار را قطع نمی‌کند؛ رفتار daemon و systemd باید جدا بررسی شود.

پرسش‌های متداول

آیا تغییر پورت SSH کافی است؟

خیر؛ کنترل مبدا، کلید، مدیریت حساب و ثبت رویداد لازم است.

قبل از غیرفعال‌کردن Password چه چیزی باید تست شود؟

ورود با کلید و sudo در نشست مستقل همراه با دسترسی console.

منابع رسمی

تاریخ بررسی منابع: 2026-09-30. اعتبارسنجی عملی روی محیط هدف باید پیش از انتشار تغییر زیرساخت انجام شود.

Share