SSH keys کا درست انتظام کیسے کریں

SSH keys کیسے کام کرتی ہیں

SSH key فائلوں کا ایک جوڑا ہوتی ہے: ایک private key جو آپ کے device پر رہتی ہے، اور ایک public key جسے آپ ہر اس server پر copy کرتے ہیں جہاں آپ login کرنا چاہتے ہیں۔ جب آپ connect کرتے ہیں تو server، challenge بھیجنے کے لیے public key استعمال کرتا ہے۔ اس challenge کا جواب صرف متعلقہ private key دے سکتی ہے۔ private key آپ کے device سے کبھی باہر نہیں جاتی، اس لیے network پر کوئی secret منتقل نہیں ہوتا، اور breached server سے چوری کرنے کے لیے کوئی مفید secret موجود نہیں ہوتا۔ اسی وجہ سے keys، passwords سے بہتر ہیں۔ SSH keys کو درست طریقے سے manage کرنے کے لیے چار عادات ضروری ہیں: ہر device کے لیے ایک key، وہ file permissions جن کا sshd تقاضا کرتا ہے، ایک ~/.ssh/config file تاکہ آپ options بار بار type نہ کریں، اور یہ جاننا کہ laptop گم ہونے کے دن key کیسے remove کرنی ہے۔

یہ guide Ubuntu 24.04 پر ہر عادت کا احاطہ کرتی ہے، تاہم یہاں بیان کردہ تقریباً تمام باتیں کسی بھی Linux server اور OpenSSH کے کسی بھی حالیہ version پر لاگو ہوتی ہیں۔

شروع کرنے سے پہلے اصطلاحات کے بارے میں ایک اہم بات سمجھ لیں، کیونکہ اس سے حقیقی غلطیوں سے بچا جا سکتا ہے۔ public key secret نہیں ہوتی۔ آپ اسے ticket میں paste کر سکتے ہیں، email کے ذریعے بھیج سکتے ہیں یا اسے publish کر سکتے ہیں، اور کوئی بھی اس key کے ذریعے login نہیں کر سکتا۔ private key secret ہوتی ہے۔ جو شخص اس file کی copy حاصل کر لے، اور اگر اس پر passphrase لگا ہو تو وہ passphrase بھی جانتا ہو، وہ آپ کے servers کی نظر میں آپ ہی ہوتا ہے۔

کلید بنائیں: ed25519 درست ڈیفالٹ ہے

اپنے کمپیوٹر پر، سرور پر نہیں، یہ کمانڈ چلائیں:

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 کلید کی قسم منتخب کرتا ہے۔ Ed25519 جدید ڈیفالٹ ہے: اس کی کلیدیں مختصر اور تیز ہوتی ہیں، اور 2014 کے بعد جاری ہونے والی ہر OpenSSH ریلیز اسے سپورٹ کرتی ہے۔ ssh-keygen -t rsa -b 4096 صرف اس وقت استعمال کریں جب آپ کو ایسے پرانے آلے سے رابطہ کرنا ہو جو ed25519 کو نہیں سمجھتا۔ -C "laptop" تبصرہ مقرر کرتا ہے۔ اس تبصرے کا خفیہ نگاری سے کوئی تعلق نہیں، لیکن دو سال بعد سرور کی authorized_keys فائل میں اسی سے آپ اس کلید کو پہچانیں گے، اس لیے اس ڈیوائس کا نام لکھیں جس پر یہ کلید موجود ہے۔

ssh-keygen کلید محفوظ کرنے کی جگہ پوچھتا ہے۔ ڈیفالٹ، ~/.ssh/id_ed25519، قبول کریں۔ اس کے بعد یہ passphrase پوچھتا ہے۔ ایک passphrase مقرر کریں؛ ذیل کا passphrase سیکشن بتاتا ہے کہ روزمرہ استعمال میں اس کی کوئی اضافی لاگت نہیں ہوتی۔ آخر میں آپ کے پاس دو فائلیں ہوں گی: ~/.ssh/id_ed25519 نجی کلید ہے، اور ~/.ssh/id_ed25519.pub عوامی کلید ہے۔ عوامی حصے کو دیکھیں:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

یہ ایک ہی سطر ہے: کلید کی قسم، کلید کا مواد، اور آپ کا تبصرہ۔ یہی سطر آپ کے سرورز پر شامل کی جائے گی۔

ہر ڈیوائس کے لیے ایک key، ہر server کے لیے نہیں

سب سے پہلے ہر کوئی یہی پوچھتا ہے: کیا مجھے ہر server کے لیے نئی key درکار ہے؟ نہیں۔ ہر اس device کے لیے ایک key بنائیں جس پر آپ typing کرتے ہیں، اور اس device کو جن servers تک رسائی درکار ہو، ان سب پر وہی public key رکھیں۔ key، device کی شناخت کرتی ہے۔ ہر server پر موجود authorized_keys file ان devices کی فہرست ہے جنہیں اندر آنے کی اجازت ہے۔

یہ ماڈل بڑے ماحول میں بھی مؤثر رہتا ہے، جبکہ متبادل طریقے متوقع مسائل پیدا کرتے ہیں۔ ہر server کے لیے الگ key رکھنے کا مطلب ہے کہ 20 servers والا laptop 20 private keys رکھے گا، اور آپ یہ یاد نہیں رکھ پائیں گے کہ کون سی key کس server کے لیے ہے۔ اپنی تمام devices کے لیے ایک ہی key استعمال کرنا اس سے بھی زیادہ خطرناک ہے۔ اگر laptop چوری ہو جائے تو آپ laptop کی access منسوخ نہیں کر سکتے، کیونکہ desktop بھی وہی private key رکھتا ہے۔ اس صورت میں آپ کو ہر جگہ key تبدیل کر کے بیک وقت ہر device پر نئی key تقسیم کرنا ہوگی۔

ہر device کے لیے ایک key رکھنے سے laptop گم ہونے کی صورت میں ہر server پر صرف ایک line حذف کرنی پڑتی ہے: authorized_keys سے laptop کی line حذف کریں، اور باقی تمام devices کام کرتی رہیں گی۔ -C کے ذریعے مقرر کیا گیا comment اس line کو آسانی سے تلاش کرنے میں مدد دیتا ہے۔

اس ماڈل کا بنیادی اصول یہ ہے: private key ایک device پر بنائی جاتی ہے اور اسی device کے ساتھ ختم ہو جاتی ہے۔ private key کو کبھی دوسری machine پر copy نہ کریں، اور اسے کبھی کسی server پر upload نہ کریں۔ جب کسی نئی device کو access درکار ہو، تو اسی device پر نئی key generate کریں۔

سرور پر public key رکھیں

آسان طریقہ ssh-copy-id ہے، جو OpenSSH کے ساتھ جاری ہوتا ہے:

ssh-copy-id matt@10.0.0.10

یہ جو authentication طریقہ اب بھی کام کر رہا ہو، عموماً password، اسی سے login کرتا ہے، پھر اپنی public key سرور پر ~/.ssh/authorized_keys میں شامل کرتا ہے۔ اگر directory یا file موجود نہ ہو تو یہ انہیں درست permissions کے ساتھ بناتا بھی ہے۔ نئی SSH session کھول کر اس کی جانچ کریں۔ سرور کو account password مانگے بغیر آپ کو login کرنے دینا چاہیے۔ اگر آپ کی key پر passphrase ہے تو آپ کی اپنی machine اس کے بجائے وہ passphrase مانگ سکتی ہے۔ یہ prompt مقامی machine کا ہے، سرور کا password نہیں۔

جب password login پہلے ہی disabled ہو، تو ssh-copy-id login نہیں کر سکتا۔ ایسی صورت میں آپ کو line خود شامل کرنی ہوگی۔ ایسی session کے ذریعے login کریں جو اب بھی کام کر رہی ہو، یا اپنے provider کے web console سے login کریں، پھر سرور پر یہ command چلائیں:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

quotes کے اندر اپنی حقیقی public key paste کریں۔ یہ id_ed25519.pub کی مکمل single line ہونی چاہیے۔ authorized_keys میں ہر line پر ایک public key ہوتی ہے، اور یہی مکمل access database ہے: device شامل کرنے کے لیے ایک line append کریں، اور device کی رسائی ختم کرنے کے لیے وہ line delete کریں۔ نئے server پر یہ مرحلہ نئے VPS کے پہلے 10 منٹ میں، password login بند کرنے سے فوراً پہلے مکمل کریں۔

وہ permissions جو key login کو ناکام بناتی ہیں

یہ key login کے ناکام ہونے کی سب سے عام وجہ ہے، اور client side پر یہ خاموشی سے ناکام ہوتی ہے۔ Ubuntu 24.04 میں sshd بطور ڈیفالٹ StrictModes yes کے ساتھ چلتا ہے۔ اس کا مطلب ہے کہ یہ ایسی authorized_keys file استعمال کرنے سے انکار کرتا ہے جس میں دوسرے users ترمیم کر سکتے ہوں۔ اگر file، ~/.ssh directory، یا آپ کی home directory آپ کے علاوہ کوئی بھی لکھ سکتا ہو تو sshd آپ کی key نظرانداز کر دیتا ہے اور client کو کوئی وضاحت دیے بغیر password مانگنے پر واپس آ جاتا ہے۔ (Ubuntu کا OpenSSH صرف ایک محدود صورت برداشت کرتا ہے: ایسی file جو آپ کے اپنے private group کے لیے group-writable ہو اور اس group میں کوئی دوسرا شامل نہ ہو۔ اس پر انحصار نہ کریں؛ نیچے دیے گئے modes استعمال کریں۔) اصل وجہ صرف server کے log میں ظاہر ہوتی ہے:

sudo grep 'Authentication refused' /var/log/auth.log

rsyslog کے بغیر minimal image میں auth.log موجود نہیں ہوتی؛ یہی line journal میں موجود ہوتی ہے: sudo journalctl -u ssh | grep 'Authentication refused'۔

Authentication refused: bad ownership or modes for file /home/matt/.ssh/authorized_keys

اس مسئلے کا حل permissions میں دو تبدیلیاں اور ownership کی ایک جانچ ہے۔ یہ کام server پر متاثرہ user کے طور پر چلائیں:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R matt:matt ~/.ssh

یاد رکھنے کا اصول یہ ہے: 700، .ssh directory پر، اور اس کے اندر موجود ہر چیز پر 600۔ یہی numbers آپ کے اپنے computer پر بھی لاگو ہوتے ہیں، کیونکہ client بھی جانچ کرتا ہے۔ اگر دوسرے users private key پڑھ سکتے ہوں تو ssh اس key کو مکمل طور پر مسترد کر دیتا ہے، اور اس بار error واضح طور پر ظاہر ہوتی ہے:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/matt/.ssh/id_ed25519' are too open.

chmod 600 ~/.ssh/id_ed25519 اسے درست کرتا ہے۔

~/.ssh/config: اختیارات بار بار لکھنے کی ضرورت ختم کریں

اپنے کمپیوٹر پر موجود ~/.ssh/config فائل ہر server کے لیے مختصر نام مقرر کرتی ہے اور وہ اختیارات محفوظ رکھتی ہے جو آپ بار بار لکھتے ہیں۔ اسے 600 permissions کے ساتھ بنائیں اور ہر server کے لیے ایک Host block شامل کریں:

Host web1
    HostName 10.0.0.10
    User matt
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host db1
    HostName 10.0.0.11
    User matt
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

اب ssh web1 کی جگہ ssh -p 22 matt@10.0.0.10 استعمال کریں۔ یہی مختصر نام scp، rsync اور git میں بھی کام کرے گا، کیونکہ یہ سب اسی فائل کو پڑھتے ہیں۔ HostName اصل address متعین کرتا ہے، User account name لکھنے سے بچاتا ہے، اور IdentityFile یہ طے کرتا ہے کہ کون سی key پیش کی جائے۔

IdentitiesOnly yes کے بارے میں ایک جملہ ضروری ہے، کیونکہ یہ ایک الجھن پیدا کرنے والی failure کو حل کرتا ہے۔ جب agent میں متعدد keys موجود ہوں تو client انہیں ایک ایک کرکے پیش کرتا ہے، اور server ہر پیش کش کو failed attempt شمار کرتا ہے۔ اگر کافی keys loaded ہوں تو درست key آزمانے سے پہلے ہی آپ کو Received disconnect: Too many authentication failures مل جاتا ہے۔ IdentitiesOnly yes client کو صرف IdentityFile میں درج key پیش کرنے پر مجبور کرتا ہے، اس لیے یہ failure واقع نہیں ہو سکتی۔

پاس فریز اور ssh-agent

پاس فریز ڈسک پر موجود private key فائل کو encrypt کرتا ہے۔ اس کے بغیر جو شخص بھی فائل کی نقل حاصل کر لے، وہ اسے فوراً استعمال کر سکتا ہے؛ پاس فریز کے ساتھ چوری شدہ فائل اس وقت تک بےکار رہتی ہے جب تک پاس فریز معلوم نہ کر لیا جائے۔ laptop پر موجود key کے لیے یہی مطلوبہ تحفظ ہے، کیونکہ laptops چوری ہو سکتے ہیں اور ان کے backups افشا ہو سکتے ہیں۔

عملی طور پر پاس فریز رکھنے میں کوئی اضافی زحمت نہیں ہوتی، کیونکہ ssh-agent۔ agent آپ کی decrypted key کو memory میں رکھتا ہے، اس لیے آپ ہر login session میں پاس فریز صرف ایک بار درج کرتے ہیں اور اس کے بعد ہر connection فوراً قائم ہو جاتا ہے۔ زیادہ تر desktop Linux distributions اور macOS پہلے ہی آپ کے لیے agent چلا رہے ہوتے ہیں۔ اپنی key کو اس میں load کرنے کے لیے یہ command چلائیں:

ssh-add ~/.ssh/id_ed25519

ssh-add -l سے agent میں اس وقت موجود keys کی فہرست دکھائی جاتی ہے۔ ایک احتیاط: agent forwarding (ssh -A) remote server کو اجازت دیتی ہے کہ آپ کے connected ہونے کے دوران authentication کے لیے آپ کے agent کو آگے استعمال کرے۔ اس لیے اسے صرف ان servers کی طرف enable کریں جن پر آپ کو مکمل اعتماد ہو، اور default طور پر اسے بند رکھیں۔

گردش اور منسوخی: گم شدہ لیپ ٹاپ کی مشق

سادہ SSH key کو منسوخ کرنے کے لیے صرف ہر ایسے server پر authorized_keys سے اس کی لائن ہٹانا کافی ہے جہاں وہ موجود ہو۔ کسی certificate authority کو اطلاع دینے کی ضرورت نہیں ہوتی، اور نہ ہی expiry date کا انتظار کرنا پڑتا ہے۔ لائن ہٹتے ہی اس key سے نئے logins ناکام ہو جاتے ہیں۔

یہ مشق ابھی کریں، جب کوئی ہنگامی صورتِ حال نہیں ہے۔ ایک server منتخب کریں، ~/.ssh/authorized_keys کھولیں، اور comment کے ذریعے key تلاش کریں۔ کسی editor سے لائن حذف کریں، یا comment کے ذریعے اسے filter out کریں:

grep -v ' laptop$' ~/.ssh/authorized_keys > ~/.ssh/authorized_keys.tmp
mv ~/.ssh/authorized_keys.tmp ~/.ssh/authorized_keys

پھر اسی device سے تصدیق کریں جس کی key آپ نے ابھی منسوخ کی ہے کہ login اب ناکام ہو رہا ہے، اور کسی دوسرے device سے تصدیق کریں کہ login اب بھی کام کر رہا ہے۔ ایک بات یاد رکھیں: key ہٹانے سے پہلے سے کھلے ہوئے sessions بند نہیں ہوتے، کیونکہ key صرف login کے وقت چیک ہوتی ہے۔ اگر آپ کسی چوری شدہ device کی key منسوخ کر رہے ہیں تو server پر who بھی چیک کریں اور ہر غیر معروف session ختم کریں۔

Rotation میں یہی عمل مختلف ترتیب سے کیا جاتا ہے: device پر نئی key generate کریں، اسے ssh-copy-id کے ذریعے install کریں، تصدیق کریں کہ نئی key سے login ہو رہا ہے، پھر پرانی لائن حذف کریں۔ یہ کام اس وقت کریں جب کوئی device کسی دوسرے شخص کے حوالے کیا جائے، جب key کے exposed ہونے کا امکان ہو، یا جب کوئی شخص team چھوڑ دے۔ دو servers پر یہ کام دستی طور پر کرنا مناسب ہے؛ لیکن بیس servers پر یہ automation کا کام ہے، اور متعدد Linux servers کا انتظام بتاتا ہے کہ ایک ہی authorized_keys state کو پوری fleet پر کیسے نافذ کیا جائے۔

کیا نہ کریں

• اپنے تمام devices کے لیے ایک ہی private key استعمال نہ کریں۔ اس صورت میں ایک چوری شدہ device کی access منسوخ کرنے کے لیے ہر جگہ key تبدیل کرنا پڑے گی۔

• private key کو git repository میں commit نہ کریں، چاہے وہ private repository ہی کیوں نہ ہو۔ Automated scanners public repositories کی نگرانی کرتے ہیں اور push کے چند منٹ کے اندر leaked keys آزمانا شروع کر دیتے ہیں۔ بعد میں public کی گئی repository اپنی پوری history افشا کر دیتی ہے۔

• اپنے laptop کی private key کسی server پر upload نہ کریں تاکہ وہ server کسی دوسرے server تک پہنچ سکے۔ خود server پر الگ key generate کریں اور اس key کو صرف مطلوبہ جگہ پر authorise کریں۔

• private key کو chat، email یا ticket میں paste نہ کریں۔ Public key اور .pub file ہی وہ واحد حصہ ہیں جو کبھی share کیے جاتے ہیں۔

جب آپ کی key قابل اعتماد طور پر login کرنے لگے تو اگلا قدم اٹھائیں اور password authentication بند کر دیں، تاکہ آپ کے server کے خلاف مسلسل guessing بالکل کامیاب نہ ہو سکے۔ اس کے لیے drop-in configuration VPS پر SSH hardening میں موجود ہے۔

FAQ

پاس ورڈ بھیجے بغیر SSH keys کیسے کام کرتی ہیں؟

سرور آپ کی public key کو ~/.ssh/authorized_keys میں محفوظ رکھتا ہے۔ لاگ اِن کے وقت سرور ایک challenge بھیجتا ہے، آپ کا client private key سے اس challenge پر دستخط کرتا ہے، اور سرور public key سے اس دستخط کی تصدیق کرتا ہے۔ private key آپ کے device سے باہر نہیں جاتی، اس لیے دورانِ منتقلی اسے intercept کرنے یا سرور سے کوئی قابلِ دوبارہ استعمال key چرانے کا امکان نہیں ہوتا۔ breached server سے صرف public keys افشا ہوتی ہیں، جن سے کہیں بھی لاگ اِن نہیں کیا جا سکتا۔

کیا مجھے اپنے تمام سرورز کے لیے ایک ہی SSH key استعمال کرنی چاہیے؟

بہت سے سرورز پر ایک ہی key استعمال کرنا درست ہے، بشرطیکہ وہ key ایک ہی device پر محفوظ رہے۔ اصول ہر server کے لیے ایک key نہیں، بلکہ ہر device کے لیے ایک key ہے: آپ کے laptop کی public key ہر اس server پر رکھی جائے جس تک laptop کو رسائی درکار ہے، جبکہ desktop کی اپنی الگ key ہو۔ اس سے key revoke کرنا آسان رہتا ہے، کیونکہ device گم ہونے پر ہر server سے ایک شناخت شدہ line ہٹانی پڑتی ہے، اور دوسرے devices کام کرتے رہتے ہیں۔

.ssh directory اور authorized_keys کے لیے کون سی permissions ہونی چاہییں؟

~/.ssh پر 700، اور authorized_keys پر 600، نیز ہر private key پر یہی permissions مقرر کریں۔ ان files کی ملکیت انہیں استعمال کرنے والے account کے پاس ہونی چاہیے۔ sshd پہلے سے StrictModes yes کے ساتھ چلتا ہے، اس لیے اگر کوئی file یا home directory آپ کے علاوہ کوئی دوسرا شخص لکھ سکتا ہو تو sshd آپ کی key کو خاموشی سے نظرانداز کر دیتا ہے۔ اس کی واحد علامت سرور کے auth log یا journal میں Authentication refused: bad ownership or modes ہوتی ہے۔

میں سرور سے SSH key کیسے ہٹاؤں؟

جس account کے لیے key کو authorize کیا گیا تھا، اس کے ~/.ssh/authorized_keys سے key کی line حذف کریں۔ درست line اس کے comment سے تلاش کریں، جو key material کے بعد موجود label ہوتا ہے۔ اس key سے نئے logins فوراً ناکام ہو جاتے ہیں، لیکن پہلے سے کھلے sessions جاری رہتے ہیں۔ اگر device چوری ہوا ہو تو اس device کا ہر فعال session بھی ختم کریں۔ یہ عمل ہر اس server پر دہرائیں جہاں key copy کی گئی تھی۔

کیا میری SSH key پر passphrase ضروری ہے؟

Laptop یا desktop پر موجود key کے لیے ہاں۔ passphrase key file کو encrypt کرتا ہے، اس لیے چوری شدہ یا افشا شدہ copy اکیلے کسی کام کی نہیں رہتی، اور ssh-agent کے باعث آپ کو اسے ہر connection پر نہیں بلکہ ہر session میں صرف ایک بار درج کرنا پڑتا ہے۔ سرور پر unattended automation کے لیے استعمال ہونے والی keys میں عموماً passphrase نہیں ہوتا، کیونکہ اسے درج کرنے کے لیے کوئی انسان موجود نہیں ہوتا۔ ایسی keys کو target account کے اختیارات محدود کر کے محفوظ رکھیں۔