VPS پر SSH کو محفوظ بنانے کا مکمل طریقہ

SSH کو سخت بنانا اولین ترجیح کیوں ہے

SSH کے ذریعے آپ اپنے server کو کنٹرول کرتے ہیں، اس لیے ہر attacker سب سے پہلے اسی کو نشانہ بناتا ہے۔ VPS کے online ہوتے ہی scanners، port 22 پر usernames اور passwords آزمانا شروع کر دیتے ہیں۔ آپ چند منٹ کے اندر اپنے logs میں یہ سرگرمی دیکھ سکتے ہیں۔ SSH کو harden کرنے کا مطلب ہے کہ attacker کے اندازہ لگانے کے امکانات ختم کیے جائیں: password login مکمل طور پر بند کریں، root login بند کریں، اور صرف cryptographic keys کے ذریعے رسائی کی اجازت دیں۔ ایسا کرنے کے بعد مسلسل guessing کامیاب نہیں ہو سکتی، کیونکہ تلاش کرنے کے لیے کوئی password موجود نہیں ہوتا۔

یہ فرض کیا گیا ہے کہ SSH پہلے سے کام کر رہا ہے۔ اگر آپ login کر سکتے ہیں تو اسے harden بھی کر سکتے ہیں۔ اقدامات ترتیب سے کریں، اور موجودہ session اس وقت تک کھلا رکھیں جب تک نئی session کامیابی سے کام نہ کرنے لگے۔ اس طرح کسی غلطی کی وجہ سے آپ خود کو server سے lock out نہیں کریں گے۔

مرحلہ 1: پہلے یقینی بنائیں کہ key authentication کام کرتی ہے

Key authentication میں password کے بجائے key pair استعمال ہوتا ہے: ایک private key جو آپ کے computer پر رہتی ہے، اور ایک public key جسے آپ server پر رکھتے ہیں۔ Server یہ ثابت کرتا ہے کہ private key آپ کے پاس ہے، جبکہ یہ key کبھی آپ کے machine سے باہر نہیں جاتی۔ Passwords غیر فعال کرنے سے پہلے تصدیق کریں کہ keys کام کر رہی ہیں، ورنہ آپ خود کو server سے باہر کر دیں گے۔

اپنے computer پر key بنائیں، اگر آپ کے پاس پہلے سے موجود نہیں ہے:

ssh-keygen -t ed25519

Public حصہ server پر copy کریں:

ssh-copy-id user@your-server

اس کے بعد ایک نیا SSH session کھولیں۔ اگر password پوچھے بغیر login ہو جائے تو آپ کی key کام کر رہی ہے اور passwords غیر فعال کرنا محفوظ ہے۔ اگر یہ آپ کو Permission denied (publickey) کے ساتھ روک دے تو یہ ایک error پانچ مختلف خرابیوں کو چھپا دیتی ہے، اور ssh -v output آپ کو بتاتا ہے کہ تبدیلیاں کرنے سے پہلے ان میں سے کون سی خرابی موجود ہے۔ اگر keys آپ کے لیے نئی ہیں، یا آپ ایک سے زیادہ computers استعمال کرتے ہیں، تو SSH key management کی بنیادی باتیں مکمل model کی وضاحت کرتی ہیں: ہر device کے لیے ایک key، وہ permissions جن کا sshd تقاضا کرتا ہے، اور laptop گم ہو جانے پر key revoke کرنے کا طریقہ۔

مرحلہ 2: drop-in فائل کے ذریعے sshd کو سخت بنائیں

/etc/ssh/sshd_config میں براہِ راست ترمیم نہ کریں۔ Ubuntu 24.04، /etc/ssh/sshd_config.d/ سے drop-in فائلیں پڑھتا ہے۔ وہاں ایک چھوٹی فائل زیادہ صاف طریقہ ہے، package upgrades کے بعد بھی برقرار رہتی ہے، اور مسئلہ پیدا ہونے پر اسے آسانی سے حذف کیا جا سکتا ہے۔ نام اہم ہے: sshd ہر setting کے لیے پہلی پڑھی جانے والی value برقرار رکھتا ہے، اور Ubuntu cloud images اس directory میں 50-cloud-init.conf کو PasswordAuthentication yes کے ساتھ فراہم کرتی ہیں۔ اپنی فائل کا نام 00- رکھیں تاکہ ترتیب میں یہ اس فائل سے پہلے آئے اور مؤثر ہو جائے؛ 99- فائل خاموشی سے غیر مؤثر رہتی ہے۔ ایک فائل بنائیں:

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

اس میں درج ذیل شامل کریں:

# Key-only login: no passwords to guess.
PasswordAuthentication no
KbdInteractiveAuthentication no

# No direct root login. Log in as your user, then use sudo.
PermitRootLogin no

ہر line ایک راستہ بند کرتی ہے۔ PasswordAuthentication no سب سے اہم setting ہے: passwords بند ہونے پر brute-force attack کے لیے آزمانے کو کچھ نہیں رہتا۔ KbdInteractiveAuthentication no password-style کے دوسرے راستے کو بند کرتا ہے۔ PermitRootLogin no کا مطلب ہے کہ attacker کو آپ کا username معلوم ہونا چاہیے اور آپ کی key بھی اس کے پاس ہونی چاہیے؛ صرف اس واحد account، root، کو target کرنا کافی نہیں جو ہر box پر موجود ہوتا ہے۔

مرحلہ 3: configuration کی جانچ کریں، پھر reload کریں

لاگو کرنے سے پہلے configuration میں موجود غلطیاں چیک کریں، تاکہ کوئی typo service کو خراب نہ کر سکے:

sudo sshd -t

اگر کوئی output ظاہر نہ ہو تو configuration درست ہے۔ SSH کو reload کریں:

sudo systemctl reload ssh

اس کے بعد وہ settings چیک کریں جو sshd حقیقت میں استعمال کرتا ہے، تاکہ معلوم ہو سکے کہ کوئی drop-in کسی دوسری file کی وجہ سے نظرانداز تو نہیں ہوا:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

دونوں میں no درج ہونا چاہیے۔ اب موجودہ session بند کیے بغیر، کسی دوسرے terminal سے بالکل نیا session کھولیں۔ اگر key کے ذریعے login ہو جائے تو کام مکمل ہے۔ اگر کوئی مسئلہ ہو تو اسے درست کرنے کے لیے پہلا session اب بھی کھلا رہے گا۔ یہ بیک وقت موجود session حفاظتی انتظام ہے، اس لیے اسے کبھی نظرانداز نہ کریں۔

مرحلہ 4: اختیاری غیر معیاری port

SSH کو port 22 سے 2222 جیسے port پر منتقل کرنے سے حقیقی معنوں میں سکیورٹی بہتر نہیں ہوتی، کیونکہ پُرعزم حملہ آور تمام ports کو scan کرتا ہے۔ اس کا فائدہ صرف یہ ہے کہ logs میں غیر ضروری شور کم ہو جاتا ہے، کیونکہ زیادہ تر automated scanners صرف 22 آزماتے ہیں۔ اگر آپ یہ کرنا چاہتے ہیں تو اپنی drop-in file میں Port 2222 شامل کریں، پہلے firewall میں نئے port کی اجازت دیں، پھر sudo systemctl daemon-reload && sudo systemctl restart ssh.socket چلائیں اور ssh -p 2222 کے ذریعے connect کریں۔ Ubuntu 24.04 میں listening port کا انتظام ssh.socket کرتا ہے، اس لیے سادہ reload ssh سے sshd port 22 پر ہی رہتا ہے؛ نیا port فعال کرنے کے لیے socket کو restart کرنا ضروری ہے۔ اسے protection نہیں بلکہ configuration کی صفائی سمجھیں۔

مرحلہ 5: مزید دفاعی تہیں شامل کریں

محفوظ SSH keys بنیادی دفاع ہیں، اور ان کے اوپر مزید دو تہیں شامل کی جا سکتی ہیں۔

Fail2ban آپ کے logs کی نگرانی کرتا ہے اور بار بار ناکام کوششیں کرنے والے addresses کو ban کر دیتا ہے۔ اس سے scanner noise کم ہوتی ہے اور ایسے addresses کو ابتدا ہی میں خارج کر دیا جاتا ہے۔ یہ key-only auth کے ساتھ فطری طور پر موزوں ہے: Ubuntu پر SSH attacks روکنے کے لیے Fail2ban دیکھیں۔

اس سے بھی مضبوط طریقہ یہ ہے کہ SSH کو public internet سے مکمل طور پر دور رکھا جائے۔ اگر آپ SSH کو WireGuard VPN کے پیچھے رکھیں اور port 22 کو tunnel تک محدود کر دیں تو VPN سے باہر کوئی بھی شخص اس تک پہنچ نہیں سکتا۔ اس طرح brute-force guessing صرف مشکل نہیں رہتی بلکہ ناممکن ہو جاتی ہے۔ یہ سب نیچے default-deny firewall کی موجودگی پر منحصر ہے، جس کے لیے VPS پر UFW کی ترتیب دیکھیں۔

SSH ایک بڑی checklist کا صرف ایک حصہ ہے: نئے VPS کے پہلے 10 منٹ اقدامات کو ترتیب سے بیان کرتے ہیں، جبکہ Ubuntu پر automatic security updates بعد میں system کو patched رکھتے ہیں۔ دروازہ مقفل کرنے سے اس کے پیچھے موجود services محفوظ نہیں ہوتیں۔ اس لیے اگر یہی VPS password vault چلا رہا ہو تو Vaultwarden کی hardening کا جائزہ ان دو چیزوں کا احاطہ کرتا ہے جنہیں key auth کبھی نہیں چھوتی: اس کا admin token اور backup file۔

FAQ

میں Ubuntu 24.04 پر SSH کے لیے password login کیسے غیر فعال کروں؟

/etc/ssh/sshd_config.d/00-hardening.conf پر ایک drop-in file بنائیں۔ 00 prefix اسے 50-cloud-init.conf سے پہلے ترتیب دیتا ہے، کیونکہ PasswordAuthentication yes کی قدر بصورت دیگر غالب آ جاتی؛ sshd پہلی پڑھی جانے والی قدر برقرار رکھتا ہے۔ اس file میں PasswordAuthentication no اور KbdInteractiveAuthentication no شامل کریں، اسے جانچنے کے لیے sudo sshd -t چلائیں، پھر sudo systemctl reload ssh چلائیں۔ اس پر انحصار کرنے سے پہلے نئے session میں key login کے کام کرنے کی تصدیق کریں۔ sshd_config میں ترمیم کرنے کے بجائے drop-in استعمال کرنے سے package upgrades کے بعد configuration برقرار رہتی ہے اور اسے واپس کرنا آسان ہوتا ہے۔

کیا مجھے SSH پر root login غیر فعال کرنا چاہیے؟

ہاں۔ PermitRootLogin no مقرر کریں تاکہ کوئی بھی براہ راست root کے طور پر login نہ کر سکے۔ اپنے عام user کے طور پر login کریں اور انتظامی کاموں کے لیے sudo استعمال کریں۔ ہر Linux box پر root موجود ہوتا ہے، اس لیے اسے قابل رسائی چھوڑنے سے attacker کو ہدف بنانے کے لیے ایک معلوم username مل جاتا ہے۔ اسے غیر فعال کرنے کا مطلب ہے کہ attacker کو آپ کے account name کا علم بھی ہونا چاہیے اور آپ کی key بھی حاصل کرنی چاہیے۔

کیا SSH port تبدیل کرنے سے میرا server زیادہ محفوظ ہو جاتا ہے؟

معنی خیز طور پر نہیں۔ Port 22 سے ہٹنے پر ایسے سست scanners آپ کو نہیں ڈھونڈ پاتے جو صرف 22 کو probe کرتے ہیں۔ اس سے logs میں noise کم ہوتی ہے، لیکن حقیقی attacker ہر port scan کرتا ہے اور اسے پھر بھی تلاش کر لیتا ہے۔ اصل میں break-ins کو روکنے والی چیز key-only authentication ہے۔ اگر port تبدیل کریں تو پہلے firewall میں نئی port کھولیں، پھر sudo systemctl daemon-reload && sudo systemctl restart ssh.socket چلائیں۔ Ubuntu 24.04 میں listener کی ownership socket کے پاس ہوتی ہے، اور عام reload کے بعد بھی sshd port 22 پر چلتا رہتا ہے۔

اگر میں SSH keys استعمال کرتا ہوں تو کیا مجھے Fail2ban کی ضرورت ہے؟

یہ اختیاری ہے، لیکن پھر بھی مفید ہے۔ Key-only authentication کے ساتھ password guessing کامیاب نہیں ہو سکتی، اس لیے attackers کو باہر رکھنے کا بنیادی ذریعہ Fail2ban نہیں ہے۔ یہ ایک address سے ہونے والی repeated failures کی rate limit کرتا ہے، جس سے logs میں scanner noise کم ہوتی ہے اور بار بار کوشش کرنے والوں کو ابتدا ہی میں خارج کر دیا جاتا ہے۔ تاہم ایک سست اور distributed attack اس کی ban threshold سے نیچے رہتا ہے۔ اسے key authentication کے ساتھ اضافی تحفظ کے طور پر چلائیں، اور بہتر ہے کہ SSH کو VPN کے پیچھے رکھیں۔

اگر میں خود کو SSH سے lock out کر دوں تو کیسے بحال کروں؟

اپنے provider کا web console استعمال کریں۔ یہ server تک serial یا VNC connection کے ذریعے پہنچتا ہے، جو SSH سے نہیں گزرتا۔ وہاں سے login کر کے sshd drop-in file درست کریں اور service reload کریں۔ اسی لیے پہلی session بند کرنے سے پہلے دوسرے terminal میں نئی SSH configuration کی جانچ کرنا ضروری ہے۔ اسی طرح passwords غیر فعال کرنے سے پہلے key authentication کا کام کرنا بھی یقینی بنائیں۔