VPS پر SSH کو کیسے محفوظ بنائیں

SSH کو ہارڈن (harden) کرنے کی اہمیت

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

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

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

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

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

ssh-keygen -t ed25519

Public half کو server پر copy کریں:

ssh-copy-id user@your-server

پھر ایک نیا SSH session کھولیں۔ اگر یہ بغیر password کے login کرنے دے، تو آپ کی key کام کر رہی ہے اور آپ passwords بند کرنے کے لیے محفوظ ہیں۔ اگر آپ keys کے بارے میں نئے ہیں، یا آپ ایک سے زیادہ computer استعمال کرتے ہیں، تو SSH key management basics مکمل ماڈل کی وضاحت کرتا ہے: ہر device کے لیے ایک key، sshd کی مطلوبہ permissions، اور laptop گم ہو جانے کی صورت میں key کو revoke کرنے کا طریقہ۔

Step 2: sshd کو drop-in file کے ذریعے harden کریں

/etc/ssh/sshd_config کو براہ راست edit نہ کریں۔ Ubuntu 24.04، /etc/ssh/sshd_config.d/ سے drop-in files پڑھتا ہے۔ وہاں ایک چھوٹی فائل کا استعمال کرنا زیادہ بہتر ہے کیونکہ یہ package upgrades کے دوران برقرار رہتی ہے اور اگر کوئی مسئلہ ہو تو اسے ہٹانا آسان ہوتا ہے۔ فائل کا نام اہم ہے: sshd ہر setting کے لیے پہلی پڑھی گئی value کو محفوظ رکھتا ہے۔ Ubuntu cloud images میں اس directory میں PasswordAuthentication yes کے ساتھ 50-cloud-init.conf موجود ہوتا ہے۔ اپنی فائل کا نام 00- رکھیں تاکہ وہ اس فائل سے پہلے sort ہو اور اس کی setting لاگو ہو؛ 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 ایک door کو بند کرتی ہے۔ PasswordAuthentication no سب سے اہم ہے: passwords بند کرنے سے brute-force attack کا مقصد ختم ہو جاتا ہے۔ KbdInteractiveAuthentication no پاس ورڈ پر مبنی دوسرے راستے کو بند کرتا ہے۔ PermitRootLogin no کا مطلب ہے کہ attacker کو آپ کا username معلوم ہونا چاہیے اور اس کے پاس آپ کی key ہونی چاہیے، وہ صرف root اکاؤنٹ کو target نہیں کر سکے گا جو ہر machine پر موجود ہوتا ہے۔

Step 3: Test the config, then reload

Config کو لاگو کرنے سے پہلے اس میں غلطیوں کی جانچ کریں، تاکہ کسی ٹائپو (typo) کی وجہ سے سروس متاثر نہ ہو:

sudo sshd -t

اگر کوئی آؤٹ پٹ ظاہر نہ ہو، تو اس کا مطلب ہے کہ config درست ہے۔ SSH کو ری لوڈ کریں:

sudo systemctl reload ssh

پھر ان سیٹنگز کو چیک کریں جو sshd دراصل استعمال کر رہا ہے، تاکہ اگر کوئی فائل دوسری فائل سے اوور رائٹ ہو گئی ہو تو آپ کو پتہ چل سکے:

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

دونوں کا نتیجہ no ہونا چاہیے۔ اب، موجودہ سیشن کو بند کیے بغیر، کسی دوسرے ٹرمینل سے ایک نیا سیشن کھولیں۔ اگر آپ کی کی (key) کے ذریعے لاگ ان ہو جاتا ہے، تو آپ کا کام مکمل ہو گیا ہے۔ اگر کوئی مسئلہ ہو، تو آپ کا پہلا سیشن ابھی بھی کھلا ہے تاکہ آپ اسے درست کر سکیں۔ یہ اوورلیپ (overlap) ایک حفاظتی نیٹ (safety net) ہے، اس لیے اسے کبھی نہ چھوڑیں۔

Step 4: اختیاری غیر معیاری پورٹ

SSH کو پورٹ 22 سے بدل کر 2222 جیسی کسی پورٹ پر منتقل کرنے سے حقیقی طور پر سیکورٹی بہتر نہیں ہوتی، کیونکہ ایک باخبر حملہ آور تمام پورٹس کو اسکین کرتا ہے۔ اس کا اصل فائدہ لاگ فائلز میں شور (noise) کو کم کرنا ہے، کیونکہ زیادہ تر خودکار اسکینرز صرف 22 پورٹ کو ٹرائی کرتے ہیں۔ اگر آپ یہ کرنا چاہتے ہیں، تو اپنی drop-in فائل میں Port 2222 شامل کریں، پہلے فائر وال میں نئی پورٹ کو اجازت دیں، پھر sudo systemctl daemon-reload && sudo systemctl restart ssh.socket چلائیں اور ssh -p 2222 کے ذریعے کنیکٹ کریں۔ Ubuntu 24.04 پر، ssh.socket لسننگ پورٹ کو کنٹرول کرتا ہے، اس لیے صرف reload ssh کرنے سے sshd پورٹ 22 پر ہی رہتا ہے؛ نئے پورٹ کو فعال کرنے کے لیے ساکٹ (socket) کو ری اسٹارٹ کرنا ضروری ہے۔ اسے سیکورٹی کے بجائے سسٹم کی صفائی (tidiness) کے طور پر دیکھیں۔

Step 5: مزید حفاظتی تہیں (Layer the further defences)

Hardened SSH keys بنیادی بنیاد ہیں، اور ان کے اوپر دو مزید تہیں (layers) کام کرتی ہیں۔

Fail2ban آپ کے logs پر نظر رکھتا ہے اور بار بار ناکام ہونے والے addresses کو ban کر دیتا ہے۔ اس سے scanner noise کم ہو جاتی ہے اور حملہ آوروں کو جلد ہی نکالا جا سکتا ہے۔ یہ key-only auth کے ساتھ بہترین کام کرتا ہے: Fail2ban on Ubuntu to stop SSH attacks دیکھیں۔

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

SSH ایک بڑی checklist کا حصہ ہے: the first 10 minutes on a new VPS تمام مراحل کو ترتیب سے بتاتا ہے، اور automatic security updates on Ubuntu سسٹم کو بعد میں بھی patched رکھتے ہیں۔

FAQ

Ubuntu 24.04 پر SSH کے لیے password login کیسے بند کریں؟

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

کیا مجھے SSH پر root login بند کر دینا چاہیے؟

جی ہاں۔ PermitRootLogin no کو سیٹ کریں تاکہ کوئی بھی براہ راست root کے طور پر لاگ ان نہ کر سکے۔ اپنے عام user کے طور پر لاگ ان کریں اور admin کاموں کے لیے sudo استعمال کریں۔ ہر Linux سسٹم پر root موجود ہوتا ہے، اس لیے اسے کھلا چھوڑنے سے حملہ آور کو ایک معلوم username مل جاتا ہے۔ اسے بند کرنے کا مطلب ہے کہ حملہ آور کو آپ کے اکاؤنٹ کا نام معلوم ہونا چاہیے اور اس کے پاس آپ کی key ہونی چاہیے۔

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

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

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

یہ اختیاری ہے لیکن پھر بھی مفید ہے۔ key-only authentication کے ساتھ، password guessing کامیاب نہیں ہو سکتی، اس لیے Fail2ban حملہ آوروں کو روکنے کا ذریعہ نہیں ہے۔ یہ ایک ہی address سے ہونے والی بار بار کی ناکامیوں (failures) کو limit کرتا ہے، جس سے logs میں scanner noise کم ہوتی ہے اور بار بار حملہ کرنے والوں کو جلد بلاک کر دیا جاتا ہے؛ ایک سست اور distributed attack پھر بھی اس کے ban threshold سے نیچے رہتا ہے۔ اسے key auth کے ساتھ استعمال کریں، اور بہتر ہے کہ SSH کو VPN کے پیچھے رکھیں۔

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

اپنے provider کے web console کا استعمال کریں، جو server تک serial یا VNC connection کے ذریعے رسائی دیتا ہے جو SSH کے ذریعے نہیں جاتا۔ وہاں سے آپ لاگ ان کر سکتے ہیں، sshd drop-in فائل کو ٹھیک کر سکتے ہیں، اور service کو reload کر سکتے ہیں۔ یہی وجہ ہے کہ آپ کو اپنی پہلی session بند کرنے سے پہلے دوسرے terminal میں نئی SSH config کا تجربہ کرنا چاہیے، اور passwords بند کرنے سے پہلے key authentication کا کام کرنا چاہیے۔