SSH keys ka sahi istemal aur intezam

SSH کلیدز کیسے کام کرتی ہیں

SSH کلید فائلوں کا ایک جوڑا ہے: ایک پرائیویٹ کلید جو آپ کے ڈیوائس پر رہتی ہے اور ایک پبلک کلید جسے آپ ہر اس سرور پر کاپی کرتے ہیں جہاں آپ لاگ اِن ہونا چاہتے ہیں۔ جب آپ کنیکٹ ہوتے ہیں، تو سرور پبلک کلید کا استعمال کرتے ہوئے ایک چیلنج بھیجتا ہے جس کا جواب صرف میچنگ پرائیویٹ کلید ہی دے سکتی ہے۔ پرائیویٹ کلیر آپ کے ڈیوائس سے کبھی باہر نہیں نکلتی۔ اس لیے نیٹورک پر کوئی راز سفر نہیں کرتا، اور سمجھوتے والے سرور کے پاس چھیننے کے لیے کوئی مفید چیز نہیں ہوتی۔ اسی لیے کلیدز پاس ورڈز سے بہتر ہیں۔ SSH کلیدز کا بہترین انتظام چار عادتوں پر منحصر ہے: ہر ڈیوائس کے لیے ایک کلید، وہ فائل پرمیشنز جو sshd طلب کرتا ہے، ایک ~/.ssh/config فائل تاکہ آپ آپشنز ٹائپ کرنا چھوڑ دیں، اور یہ جاننا کہ جس دن لیپ ٹاپ گم ہو جائے تو کلید کو کیسے ہٹایا جائے۔

یہ گائیڈ Ubuntu 24.04 پر ہر عادت کو کور کرتا ہے، حالانکہ یہاں کی تقریباً ہر بات کسی بھی Linux سرور اور کسی بھی حالیہ OpenSSH پر لاگو ہوتی ہے۔

شروع کرنے سے پہلے الفاظ کی ایک بات، کیونکہ یہ اصل غلطیوں سے بچاتا ہے۔ پبلک کلید خفیہ نہیں ہے۔ آپ اسے کسی ٹکٹ میں پیسٹ کر سکتے ہیں، ای میل سے بھیج سکتے ہیں، یا شائع کر سکتے ہیں، اور کوئی بھی اس سے لاگ اِن نہیں ہو سکتا۔ پرائیویٹ کلید وہ راز ہے۔ جو کوئی بھی اس فائل کو کاپی کر لیتا ہے، اور اگر اس کا پاس فریز ہے تو وہ جانتا ہے، وہ آپ کے سرورز کے نقطہ نظر سے آپ ہی ہے۔

کلید بنائیں: 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، کو قبول کریں۔ پھر یہ پاس فریز مانگتا ہے۔ ایک مقرر کریں؛ نیچے پاس فریز والا حصہ وضاحت کرتا ہے کہ یہ روزمرہ میں آپ کی کیا قیمت لیتا ہے۔ آپ کے پاس دو فائلیں بن جاتی ہیں: ~/.ssh/id_ed25519 پرائیویٹ کلید ہے، اور ~/.ssh/id_ed25519.pub پبلک کلید ہے۔ پبلک حصہ دیکھیں:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

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

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

سب سے پہلہ ہر کوئی یہی سوال پوچھتا ہے: کیا مجھے ہر سرور کے لیے نئی کلید چاہیے؟ نہیں۔ ہر ڈیوائس کے لیے ایک کلید بنائیں جس پر آپ ٹائپ کرتے ہیں، اور وہ ایک پبلک کلید ہر اس سرور پر رکھیں جس تک ڈیوائس کو پہنچنا چاہیے۔ کلید ڈیوائس کی شناخت کرتی ہے۔ ہر سرور پر authorized_keys فائل ان ڈیوائسز کی فہرست ہے جنہیں داخل ہونے کی اجازت ہے۔

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

ہر ڈیوائس کے لیے ایک کلید کے ساتھ، گمشدہ لیپ ٹاپ کا نقصان ہر سرور پر صرف ایک لائن مٹانے کا ہے: authorized_keys سے لیپ ٹاپ کی لائن حذف کریں، اور ہر دوسرا ڈیوائس کام کرتا رہے گا۔ وہ تبصرہ جو آپ نے -C سے سیٹ کیا ہے اس لائن کو تلاش کرنا آسان بناتا ہے۔

اس ماڈل کے پیچھے کا اصول: پرائیویٹ کلید ایک ڈیوائس پر بنتی ہے اور اسی ڈیوائس کے ساتھ ختم ہو جاتی ہے۔ پرائیویٹ کلید کو کبھی دوسری مشین پر کاپی نہ کریں، اور کبھی اسے سرور پر اپ لوڈ نہ کریں۔ جب کسی نئے ڈیوائس کو رسائی کی ضرورت ہو، تو اس پر نئی کلید بنائیں۔

سرور پر عوامی کلید رکھیں

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

ssh-copy-id matt@10.0.0.10

یہ اس طریقے سے لاگ ان ہوتا ہے جو ابھی کام کرتا ہے، عام طور پر پاس ورڈ، آپ کی عوامی کلید کو سرور پر ~/.ssh/authorized_keys میں شامل کرتا ہے، اور اگر ڈائریکٹری اور فائل موجود نہیں ہیں تو درست اجازوں کے ساتھ انہیں بناتا ہے۔ اسے ایک نئی SSH سیشن کھول کر آزمائیں: سرور کو آپ کو اکاؤنٹ پاس ورڈ پوچھے بغیر اندر آنے دیا چاہیے۔ اگر آپ کی کلید کا پاس فریز ہے، تو آپ کا اپنا مشین اس کے لیے پوچھ سکتا ہے؛ یہ اشارہ مقامی ہے اور سرور پاس ورڈ نہیں ہے۔

جب پاس ورڈ لاگ ان پہلے ہی غیر فعال ہو، تو ssh-copy-id اندر نہیں آ سکتا، اس لیے آپ لائن ہاتھ سے شامل کرتے ہیں۔ ایسے سیشن کے ذریعے لاگ ان کریں جو ابھی کام کرتا ہے، یا اپنے فراہم کنندہ کے ویب کنسول کے ذریعے، اور سرور پر یہ چلائیں:

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

اپنی اصل عوامی کلید کو اقتباس کے اندر پیسٹ کریں، id_ed25519.pub کی مکمل واحد لائن۔ authorized_keys ہر لائن پر ایک عوامی کلید ہوتی ہے، اور یہی تمام رسائی کا ڈیٹا بیس ہے: کوئی ڈیوائس شامل کرنا ایک لائن شامل کرنا ہے، اور کسی ڈیوائس کی رسائی ختم کرنا ایک لائن مٹانا ہے۔ نئے سرور پر، یہ مرحلہ نئے VPS پر پہلے 10 منٹ میں آتا ہے، ٹھیک اس سے پہلے جب آپ پاس ورڈ لاگ ان بند کریں۔

وہ اجازتیں جو کلیدی لاگ ان کو ناکام بناتی ہیں

یہ کلیدی لاگ ان ناکام ہونے کی سب سے عام وجہ ہے، اور کلائنٹ کی طرف سے یہ خاموشی سے ناکام ہوتا ہے۔ Ubuntu 24.04 پر sshd بطورِ پیش فرض StrictModes yes کے ساتھ چلتا ہے، یعنی یہ ایسے authorized_keys فائل کو استعمال کرنے سے انکار کرتا ہے جسے دیگر صارفین میں ترمیم کر سکتے ہوں۔ اگر فائل، ~/.ssh ڈائریکٹری، یا آپ کی ہوم ڈائریکٹری آپ کے علاوہ کسی اور کے لیے قابلِ تحریر ہو، تو sshd آپ کی کلید کو نظر انداز کرتا ہے اور پاس ورڈ مانگنے پر واپس آ جاتا ہے، اور کلائنٹ میں کوئی وجہ نہیں بتاتا۔ (Ubuntu کا OpenSSH بالکل ایک مخصوص صورت کو برداشت کرتا ہے: ایسی فائل جس پر آپ کی اپنی نجی گروپ کو تحریری اجازت ہو، جس میں کوئی اور نہیں ہے۔ اس پر انحصار نہ کریں؛ نیچے دی گئی اجازتوں پر عمل کریں۔) وجہ صرف سرور کے لاگ میں ظاہر ہوتی ہے:

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

ایک کم سے کم امیج پر جس میں rsyslog نہیں ہے، وہاں کوئی auth.log نہیں ہوتا؛ وہی لائن جرنل میں موجود ہوتی ہے: sudo journalctl -u ssh | grep 'Authentication refused'۔

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

اس کا حل دو اجازتوں کی تبدیلی اور ملکیت کی جانچ ہے، جو سرور پر متاثرہ صارف کے طور پر چلائیں:

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

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

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         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 فائل ہر سرور کو ایک مختصر نام دیتی ہے اور آپ کے بار بار ٹائپ کیے جانے والے اختیارات یاد رکھتی ہے۔ اسے 600 اجازوں کے ساتھ بنائیں اور ہر سرور کے لیے ایک Host بلاک شامل کریں:

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 اصل پتہ ہے، User آپ کو اکاؤنٹ کا نام ٹائپ کرنے سے بچاتا ہے، اور IdentityFile طے کرتا ہے کہ کون سی کلید پیش کی جائے۔

IdentitiesOnly yes ایک جملے کا مستحق ہے، کیونکہ یہ ایک الجھن بھری ناکامی کو ٹھیک کرتا ہے۔ جب آپ کا ایجنٹ متعدد کلیدیں رکھتا ہے، تو کلائنٹ انہیں ایک ایک کر کے پیش کرتا ہے، اور سرور ہر پیشکش کو ایک ناکام کوشش کے طور پر شمار کرتا ہے۔ کافی کلیدیں لوڈ ہونے پر آپ کو Received disconnect: Too many authentication failures مل جاتا ہے، اس سے پہلے کہ صحیح کلید آزمائی بھی جائے۔ IdentitiesOnly yes کلائنٹ کو صرف IdentityFile میں نامزد شدہ کلید پیش کرنے پر مجبور کرتا ہے، اس لیے یہ ناکامی رونما نہیں ہو سکتی۔

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

پاس فریز ڈسک پر موجود پرائیویٹ کلید فائل کو انکرپٹ کرتا ہے۔ اس کے بغیر، فائل کاپی کرنے والا کوئی بھی شخص اسے فوراً استعمال کر سکتا ہے۔ اس کے ساتھ، چوری شدہ فائل اس وقت تک بے کار رہتی ہے جب تک پاس فریز کا اندازہ نہ لگایا جائے۔ لیپ ٹاپ پر موجود کلید کے لیے یہی وہ تحفظ درکار ہوتا ہے، کیونکہ لیپ ٹاپ چوری ہو جاتے ہیں اور ان کے بیک اپس لیک ہو جاتے ہیں۔

عملی طور پر پاس فریز کی کوئی قیمت نہ ادا کرنے کی وجہ ssh-agent ہے۔ ایجنٹ آپ کی ڈکرپٹ شدہ کلید میموری میں رکھتا ہے۔ لہٰذا آپ ہر لاگ ان سیشن میں پاس فریز ایک بار درج کرتے ہیں اور اس کے بعد ہر کنکشن فوری ہو جاتا ہے۔ زیادہ تر ڈیسک ٹاپ Linux ڈسٹریبیوشنز اور macOS پہلے ہی آپ کے لیے ایک ایجنٹ چلا رہے ہوتے ہیں۔ اپنی کلید اس میں درج ذیل کمانڈ سے لوڈ کریں:

ssh-add ~/.ssh/id_ed25519

ssh-add -l اس وقت ایجنٹ میں موجود کلیدز کی فہرست دکھاتا ہے۔ ایک احتیاط: ایجنٹ فارورڈنگ (ssh -A) ریموٹ سرور کو آپ سے کنکٹ رہنے کے دوران آگے کی تصدیق کے لیے آپ کا ایجنٹ استعمال کرنے کی اجازت دیتا ہے۔ لہٰذا اسے صرف ان سرورز کے لیے فعال کریں جن پر آپ کو مکمل اعتماد ہو، اور بطور ڈیفالٹ اسے بند رکھیں۔

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

ایک عام SSH کلید کو منسوخ کرنا اس کی لائن کو ہر اس سرور سے authorized_keys میں سے ہٹانے کے مترادف ہے۔ کوئی سرٹیفکیٹ اتھارٹی مطلع کرنے کی ضرورت نہیں ہے اور نہ کوئی ختم ہونے کی تاریخ کا انتظار کرنا ہے۔ جیسے ہی لائن حذف ہوتی ہے، اس کلید سے نئی لاگ ان ناکام ہو جاتی ہے۔

مشق ابھی انجام دیں، جبکہ یہ کوئی ایمرجنسی نہیں ہے۔ ایک سرور منتخب کریں، ~/.ssh/authorized_keys کھولیں، اور کلید کو اس کے کمنٹ سے تلاش کریں۔ ایڈیٹر سے لائن حذف کریں، یا کمنٹ کے ذریعے اسے فلٹر کر کے ہٹا دیں:

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

پھر اس ڈیوائس سے تصدیق کریں جسے آپ نے ابھی منسوخ کیا ہے کہ اب لاگ ان ناکام ہو رہا ہے، اور کسی دوسرے ڈیوائس سے تصدیق کریں کہ لاگ ان ابھی بھی کام کر رہا ہے۔ ایک تفصیل نوٹ کریں: کلید ہٹانے سے پہلے سے کھلے ہوئے سیشن بند نہیں ہوتے، کیونکہ کلید صرف لاگ ان کے وقت چیک کی جاتی ہے۔ اگر آپ کسی چوری شدہ ڈیوائس کو منسوخ کر رہے ہیں، تو سرور پر who بھی چیک کریں اور جو سیشن آپ کو پہچان نہیں آتا اسے ختم کر دیں۔

روٹیشن مختلف ترتیب میں وہی عمل ہے: ڈیوائس پر نئی کلید بنائیں، اسے ssh-copy-id سے انسٹال کریں، تصدیق کریں کہ نئی کلید سے لاگ ان ہو رہا ہے، پھر پرانی لائن حذف کر دیں۔ یہ عمل اس وقت کریں جب کوئی ڈیوائس ہاتھ بدلے، جب کوئی کلید ظاہر ہو گئی ہو، یا جب کوئی شخص ٹیم چھوڑ کر چلا جائے۔ یہ کام دو سرورز پر دستی طور پر کرنا ٹھیک ہے؛ بیس پر یہ ایک آٹومیشن کا کام ہے، اور متعدد لینکس سرورز کا انتظام بتاتا ہے کہ ایک ہی authorized_keys حالت کو پوری فلیٹ میں کیسے پش کیا جائے۔

کیا نہیں کرنا چاہیے

• اپنے تمام آلات پر ایک ہی پرائیویٹ کلید مشترک نہ کریں۔ اس سے کسی ایک چوری شدہ آلے کی رسائی منسوخ کرنا ناممکن ہو جاتا ہے کیونکہ اس کے لیے ہر جگہ کلید تبدیل کرنی پڑتی ہے۔

• پرائیویٹ کلید کو git repository میں commit نہ کریں، چاہے وہ private repository ہی کیوں نہ ہو۔ خودکار اسکینرز public repositories پر نظر رکھتے ہیں اور push کے چند منٹوں میں لیک شدہ کلیدوں کو آزماتے ہیں، اور بعد میں public ہونے والا repository اپنی پوری تاریخ لیک کر دیتا ہے۔

• اپنے لیپ ٹاپ کی پرائیویٹ کلید کو سرور پر اپ لوڈ نہ کریں تاکہ وہ سرور کسی دوسرے سرور تک پہنچ سکے۔ سرور پر خود ایک الگ کلید بنائیں، اور اس کلید کو صرف اسی جگہ اجازت دیں جہاں اس کی ضرورت ہے۔

• پرائیویٹ کلید کو چیٹ، ای میل، یا ٹکٹ میں paste نہ کریں۔ پبلک کلید، یعنی .pub فائل، وہ واحد حصہ ہے جو کبھی شیئر کی جاتی ہے۔

جب آپ کی کلید آپ کو باآسانی لاگ اپن کرنے لگے، تو اگلا قدم اٹھائیں اور پاس ورڈ authentication بند کر دیں، تاکہ آپ کے سرور کے خلاف مسلسل اندازے لگانا بالکل کامیاب نہ ہو سکے۔ اس کے لیے drop-in configuration VPS پر SSH hardening میں موجود ہے۔

FAQ

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

سرور آپ کی پبلک کلید ~/.ssh/authorized_keys میں رکھتا ہے۔ لاگ ان پر سرور ایک چیلنج بھیجتا ہے۔ آپ کا کلائنٹ اس چیلنج کو پرائیویٹ کلید سے سائن کرتا ہے۔ سرور پبلک کلید سے اس دستخط کی تصدیق کرتا ہے۔ پرائیویٹ کلیر آپ کے ڈیوائس سے کبھی باہر نہیں نکلتی۔ اس لیے ٹرانزٹ میں روکنے کے لیے کچھ نہیں ہوتا اور سرور سے چرانے کے لیے کوئی دوبارہ استعمال ہونے والی چیز نہیں ہوتی۔ خلاف ورزی والا سرور صرف پبلک کلیدز لیک کرتا ہے، جنہیں کہیں بھی لاگ ان کے لیے استعمال نہیں کیا جا سکتا۔

کیا میں اپنے تمام سرورز کے لیے ایک ہی SSH کلید استعمال کروں؟

ایک ہی کلید کو بہت سے سرورز پر استعمال کرنا درست ہے، بشرطیکہ وہ کلید ایک ہی ڈیوائس پر رہے۔ اصول ایک ڈیوائس کے لیے ایک کلید ہے، نہ کہ ایک سرور کے لیے ایک: آپ کے لیپ ٹاپ کی پبلک کلید ہر اس سرور پر جاتی ہے جس کی اس لیپ ٹاپ کو ضرورت ہے، اور آپ کے ڈیسک ٹاپ کی اپنی الگ کلید ہوتی ہے۔ اس سے منسوخی آسان رہتی ہے، کیونکہ ڈیوائس کے ضائع ہونے کا مطلب ہر سرور سے ایک شناخت شدہ لائن کو ہٹانا، اور دیگر ڈیوائسز کام کرتی رہتی ہیں۔

.ssh ڈائریکٹری اور authorized_keys کے کیا اجازتیں ہونی چاہئیں؟

~/.ssh پر 700 اور authorized_keys پر 600 اور ہر پرائیویٹ کلید پر سیٹ کریں، جو انہیں استعمال کرنے والے اکاؤنٹ کی ملکیت ہوں۔ sshd بطور ڈیفالٹ StrictModes yes کے ساتھ چلتا ہے، اس لیے کوئی بھی فائل یا ہوم ڈائریکٹری جسے آپ کے علاوہ کوئی بھی لکھ سکے، اس کی وجہ سے یہ خاموشی سے آپ کی کلید کو نظر انداز کر دیتا ہے، اور سرور کے auth لاگ یا جرنل میں Authentication refused: bad ownership or modes ہی واحد نشان ہوتا ہے۔

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

جس اکاؤنٹ کے لیے کلید مجاز تھی، وہاں ~/.ssh/authorized_keys سے اس کلید کی لائن حذف کریں۔ صحیح لائن کو اس کے کمنٹ سے تلاش کریں، جو کلید میٹیریل کے بعد والا لیبل ہوتا ہے۔ اس کلید کے ساتھ نئے لاگ ان فوراً ناکام ہو جاتے ہیں، لیکن پہلے سے کھلے سیشن کھلے رہتے ہیں، اس لیے اگر وہ ڈیوائس چوری ہوئی ہے تو اس کے کسی بھی لائیو سیشن کو بھی ختم کریں۔ ہر اس سرور پر دہرائیں جس پر کلید کاپی کی گئی تھی۔

کیا میری SSH کلید پر پاس فریز کی ضرورت ہے؟

لیپ ٹاپ یا ڈیسک ٹاپ پر کلید کے لیے، ہاں۔ پاس فریز کلید فائل کو انکرپٹ کرتا ہے، اس لیے چوری شدہ یا لیک ہونے والی کاپی اپنے طور پر بے کار ہے، اور ssh-agent کا مطلب ہے کہ آپ اسے ہر کنکشن پر کے بجائے فی سیشن ایک بار ٹائپ کرتے ہیں۔ سرور پر بغیر نگرانی کے آٹومیشن کے ذریعے استعمال ہونے والی کلیدز کا عام طور پر کوئی پاس فریز نہیں ہوتا، کیونکہ ٹائپ کرنے کے لیے کوئی انسان موجود نہیں ہوتا؛ انہیں ٹارگٹ اکاؤنٹ کی صلاحیتوں کو محدود کر کے محفوظ کریں۔