SSH کے ذریعے پاس ورڈ سے تصدیق ایک عام سرور کی سب سے بڑی کھلی سطح ہے۔ اس کے سامنے نہ Fail2ban کام آتا ہے نہ کوئی حد: ہزار پتے، فی گھنٹہ ایک کوشش، کبھی کسی حد تک نہیں پہنچیں گے اور تب تک اندازہ لگاتے رہیں گے جب تک اندازہ لگانا سرے سے ممکن ہے۔ کلیدیں اس امکان ہی کو ختم کر دیتی ہیں، اور سختی کی پوری فہرست میں یہی وہ واحد ترتیب ہے جو صورتِ حال کو معیاری طور پر بدل دیتی ہے۔

اس میں ڈرانے والی صرف ایک بات ہے: پاس ورڈ بند کر دیں اور باہر رہ جائیں۔ یہ رہی وہ ترتیب جس میں ایسا نہیں ہو سکتا۔

کلید

یہ آپ کی اپنی مشین پر بنتی ہے، سرور پر نہیں:

ssh-keygen -t ed25519 -C "work laptop"

RSA کے بجائے ed25519: چھوٹی، تیز اور لمبائی کے سوالوں کے بغیر۔ RSA صرف تب چاہیے جب کسی بہت پرانی چیز تک پہنچنا ہو؛ تب -t rsa -b 4096۔

کلید پر پاس فریز رکھنا فائدہ مند ہے: کلید کی فائل لیپ ٹاپ سے چوری ہو سکتی ہے، اور پاس فریز کے بغیر وہ فوراً کام کرتی ہے۔ اسے ہر بار لکھنا نہیں پڑے گا — یہ کام ssh-agent سنبھالتا ہے، اور macOS اور بیشتر ڈیسک ٹاپ لینکس نظاموں پر وہ پہلے ہی چل رہا ہوتا ہے۔

سرور پر نقل کرنا ایک ہی کمانڈ ہے، جب تک پاس ورڈ ابھی کام کر رہا ہے:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@203.0.113.25

اگر ssh-copy-id دستیاب نہ ہو تو .pub فائل کا مواد سرور پر ~/.ssh/authorized_keys میں ایک سطر کے طور پر جوڑ دیا جاتا ہے۔ اجازتیں اہم ہیں: ڈائریکٹری .ssh 700، فائل 600، اور مالک صارف۔ کسی اور صورت میں sshd خاموشی سے فائل پڑھنے سے انکار کر دیتا ہے، اور «کلید کام نہیں کرتی» کا یہی سب سے عام سبب ہے۔

وہ جانچ جو فیصلہ کر دیتی ہے

کچھ بھی بند کرنے سے پہلے پہلا کنکشن بند کیے بغیر دوسرا کنکشن کھولیں:

ssh -o PasswordAuthentication=no user@203.0.113.25

یہ اختیار کلائنٹ کو پاس ورڈ کی طرف لوٹنے سے روکتا ہے — یعنی اگر لاگ اِن کامیاب ہوا تو کلید سے ہوا۔ جب تک یہ کمانڈ کام نہ کرے، آگے نہ بڑھیں۔ اور پہلا کنکشن آخر تک کھلا رکھیں: وہی ہر اُس چیز کو ٹھیک کرے گا جو آپ توڑ بیٹھیں۔

پاس ورڈ بند کرنا اور ایک غیر بدیہی رکاوٹ

ترتیبات ایک الگ فائل میں رکھی جاتی ہیں تاکہ پیکج کی تازہ کاری انہیں اوپر سے نہ لکھ دے۔ لیکن فائل کا نام اہم ہے:

sudo tee /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PasswordAuthentication no
PermitRootLogin no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LogLevel VERBOSE
EOF

بات یہ ہے کہ OpenSSH کسی پیرامیٹر کے لیے پہلی ملنے والی قدر استعمال کرتا ہے، آخری نہیں جیسا کہ تقریباً ہر جگہ ہوتا ہے۔ sshd_config.d کی فائلیں حروفِ تہجی کے ترتیب سے پڑھی جاتی ہیں، اور Ubuntu کی کلاؤڈ تصاویر وہاں 50-cloud-init.conf رکھتی ہیں، جس میں اکثر PasswordAuthentication yes ہوتا ہے۔ ایسی صورت میں 90 نمبر والی آپ کی فائل کچھ نہیں کرے گی: ترتیب اپنی جگہ نظر آتی ہے جبکہ پاس ورڈ کام کرتا رہتا ہے۔ اسی لیے نمبر 10 — یہ پہلے پڑھی جاتی ہے۔

واقعی کیا نکلا، یہ اندازے کے بغیر دیکھا جا سکتا ہے:

sudo sshd -T | grep -Ei 'passwordauth|permitrootlogin|pubkeyauth'

یہ کمانڈ تمام شمولیتوں کے بعد مؤثر ترتیبات چھاپتی ہے۔ اسی پر بھروسا کریں، فائلوں کے مواد پر نہیں۔

پھر نحو کی جانچ اور سروس کی نرم دوبارہ لوڈنگ:

sudo sshd -t && sudo systemctl reload ssh

sshd -t لازمی ہے: restart کے ساتھ ترتیبات میں ایک ٹائپنگ کی غلطی سروس کو گرا اور آپ کو باہر چھوڑ دیتی ہے۔ نیز reload کھلے سیشن نہیں توڑتا۔

Ubuntu 24.04: پورٹ وہاں نہیں جہاں آپ سمجھتے ہیں

نئے Ubuntu میں ایک الگ پھندا: sshd وہاں systemd کے ساکٹ کے ذریعے چلتا ہے۔ اس وضع میں sshd_config کی Port سطر کچھ نہیں کرتی — ساکٹ سنتا ہے، ڈیمن نہیں۔ اگر آپ پورٹ بدل رہے ہیں تو یہی ترمیم کرنا ہے:

sudo systemctl edit ssh.socket

اور ListenStream= (خالی قدر پچھلی کو صفر کر دیتی ہے) کو نیا پورٹ بتانا چاہیے۔ اس کی نشاندہی کرنے والی علامت: ترتیبات بدلیں، سروس دوبارہ چلی، اور سرور اب بھی 22 پر جواب دے رہا ہے۔

اور جب پورٹ بدلنے کی بات چلی ہے: بطور تحفظ یہ کام نہیں کرتا — اسکینر کسی بھی پورٹ پر سروس منٹوں میں ڈھونڈ لیتے ہیں۔ اس کا واحد اثر پرسکون لاگ ہیں، کیونکہ اجتماعی اندازہ صرف 22 پر جاتا ہے۔ یہ سہولت ہے، مگر اسے سلامتی نہ سمجھیں۔

داخل ہونے کی اجازت کس کو ہے

ایک مفید اضافہ واضح فہرست ہے:

AllowUsers deploy admin

جو کچھ فہرست میں نہیں وہ کلید جانچے جانے سے بھی پہلے کاٹ دیا جاتا ہے۔ یہ اُس صورت کا بھی احاطہ کرتا ہے جب کوئی پیکج شیل اور ہوم ڈائریکٹری والا نظامی صارف بنا دے۔

اندر آنے کا متبادل راستہ

ایک لیپ ٹاپ پر ایک کلید ناکامی کا واحد نقطہ ہے۔ ڈسک مر جاتی ہے، لیپ ٹاپ گم ہو جاتا ہے، اور سرور ہمیشہ کے لیے ناقابلِ رسائی ہو جاتا ہے۔ معقول کم سے کم:

  • authorized_keys میں کسی دوسرے آلے کی دوسری کلید؛
  • نجی کلید کی ایک نقل پاس ورڈ مینیجر میں یا خفیہ کاری شدہ ڈرائیو پر؛
  • اپنے فراہم کنندہ کے ہاں آزمودہ کنسول رسائی — VNC یا سیریل۔ آزمودہ کا مطلب ہے کہ آپ اس کے ذریعے کم از کم ایک بار داخل ہو چکے ہیں، نہ کہ «پینل میں کہیں کوئی بٹن ہے»۔

اور جب آپ وہاں ہیں تو دیکھ لیں کہ authorized_keys میں پہلے سے کیا پڑا ہے — آپ کے صارف کا بھی اور root کا بھی۔ وہاں موجود اجنبی کلید پاس ورڈ کی ہر تبدیلی سے بچ نکلتی ہے اور کارآمد رسائی رہتی ہے۔

اس کے بعد

پاس ورڈ کا اندازہ لگانا ختم نہیں ہوگا، بس بے کار ہو جائے گا: لاگ میں Failed password کی ہزاروں سطریں جمع ہوتی رہیں گی، جن میں سے کوئی بھی کامیابی پر ختم نہیں ہو سکتی۔ اب نگرانی کے قابل چیز کامیاب لاگ اِن ہیں: کس پتے سے، کس صارف کے تحت، کس وقت۔ کسی نامانوس پتے سے کلید کے ذریعے کامیاب لاگ اِن دس لاکھ ناکامیوں سے کہیں زیادہ اہم واقعہ ہے، اور عام بہاؤ میں اسے دیکھنا کہیں مشکل۔ عین یہی تصویر نیچے ڈیمو صفحہ دکھاتا ہے۔