SSH میں Permission denied (publickey) کو ٹھیک کریں

اصل میں Permission denied (publickey) کا مطلب

Permission denied (publickey) کا مطلب ہے کہ آپ کے client نے ایک یا زیادہ public keys بھیجیں، لیکن server نے ان میں سے کوئی بھی قبول نہیں کی۔ Network درست ہے اور sshd چل رہا ہے؛ انکار authentication کے آخری مرحلے میں ہو رہا ہے۔ حل اندازے سے نہیں کیا جا سکتا، کیونکہ ssh -v بتاتا ہے کہ پانچ میں سے کون سی وجہ موجود ہے۔

قوسین کے اندر موجود الفاظ ان methods کو ظاہر کرتے ہیں جنہیں server قبول کرنے کے لیے تیار تھا۔ صرف Permission denied (publickey) کا مطلب ہے کہ اس server پر password login بند ہے، اس لیے password سے fallback کرنے کا کوئی طریقہ نہیں۔ Permission denied (publickey,password) کا مطلب ہے کہ passwords دستیاب تھے، لیکن وہ بھی ناکام رہے۔

ایک ہی message پانچ الگ faults کا احاطہ کرتا ہے، اور اسے جان بوجھ کر مبہم رکھا گیا ہے۔ اگر server "no such user" یا "that key is not installed" کا جواب دیتا تو valid accounts تلاش کرنے والے کسی بھی شخص کو مدد مل جاتی۔ اس لیے فوراً keys تبدیل کرنا اور config files میں ترمیم کرنا شروع نہ کریں۔ ایک command چلائیں، output کی تین lines پڑھیں، اور پانچ ممکنہ وجوہات میں سے صرف ایک باقی رہ جائے گی۔

پہلے ssh -v چلائیں اور تین لائنیں پڑھیں

جو کمانڈ ناکام ہوئی تھی، اسے `-v` شامل کرکے دوبارہ چلائیں:

ssh -v deploy@203.0.113.10

مختصر مگر حقیقی صورتِ حال سے قریب output اس طرح دکھائی دیتا ہے:

OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.13 30 Jan 2024
debug1: Connecting to 203.0.113.10 [203.0.113.10] port 22.
debug1: Connection established.
debug1: Authenticating to 203.0.113.10:22 as 'deploy'
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
deploy@203.0.113.10: Permission denied (publickey).

آپ کو درکار تمام معلومات ان تین لائنوں میں موجود ہوتی ہیں۔

`Authenticating to 203.0.113.10:22 as 'deploy' وہ username ہے جو حقیقت میں استعمال ہوگا۔ یہ ضروری نہیں کہ وہی username ہو جسے آپ استعمال کرنا چاہتے تھے۔ یہ وہ username ہے جس کا تعین ssh نے command line، ~/.ssh/config` یا آپ کے local login name سے کیا ہے۔

`Authentications that can continue: publickey سرور کے قبول کردہ methods کی فہرست ہے، جو کسی key کو آزمانے سے پہلے بھیجی جاتی ہے۔ اگر پہلی فہرست میں publickey` موجود نہ ہو تو سرور پر public key login بند ہے، اس لیے کوئی key کام نہیں کر سکتی۔

`Offering public key: ... ہر اس key کے لیے ایک لائن ہے جو آپ کے client نے حقیقتاً بھیجی۔ اس میں اس file کا نام اور اس کا SHA256 fingerprint شامل ہوتا ہے جہاں سے key حاصل ہوئی۔ جس key کے لیے Offering` لائن موجود نہ ہو، وہ سرور کو کبھی بھیجی ہی نہیں گئی۔

اب مسئلے کو دو حصوں میں تقسیم کریں:

• متوقع key کے لیے کوئی `Offering public key` لائن موجود نہیں۔ خرابی آپ کی machine پر ہے، کیونکہ سرور نے آپ کی key دیکھی ہی نہیں۔
• key offer کی گئی اور دوبارہ `Authentications that can continue: publickey` موصول ہوا۔ سرور نے وہ key وصول کی مگر اسے مسترد کر دیا، اس لیے خرابی سرور پر ہے۔

ذیل میں وجوہات اس ترتیب سے دی گئی ہیں کہ عموماً درست وجہ کتنی کثرت سے سامنے آتی ہے۔

وجہ 1: آپ غلط username کے ساتھ connect کر رہے ہیں

سب سے عام وجہ یہی ہے، اگرچہ یہ زیادہ دلچسپ نہیں۔ sshd، یعنی SSH (secure shell) server daemon، کبھی یہ نہیں بتاتا کہ کوئی account موجود نہیں۔ یہ فرضی username کے ساتھ پورا exchange چلاتا ہے اور آخر میں اسی message کے ساتھ انکار کر دیتا ہے، کیونکہ درست account names افشا ہونے سے attacker کو مدد ملتی ہے۔ username میں typo بھی بالکل خراب key جیسا دکھائی دیتا ہے۔

کسی بھی دوسری چیز سے پہلے Authenticating to ... as line چیک کریں۔ اگر اس میں server account کے بجائے آپ کے laptop کا login نام ہے تو آپ command میں username لکھنا بھول گئے ہیں۔

ssh -v deploy@203.0.113.10
ssh -v root@203.0.113.10

default account اس image پر منحصر ہوتا ہے جسے آپ کا provider تیار کرتا ہے۔ August 2026 تک Ubuntu cloud images عموماً ubuntu account کے ساتھ آتی ہیں، Debian images debian یا admin کے ساتھ، Rocky Linux اور AlmaLinux rocky اور almalinux کے ساتھ، جبکہ بہت سے VPS providers آپ کی key براہِ راست root میں install کرتے ہیں۔ آپ کے provider کا control panel بتاتا ہے کہ اس نے کون سا account بنایا ہے۔ server کے باہر سے چلنے والی کوئی command اس سے یہ معلومات نہیں لے سکتی۔

~/.ssh/config میں موجود Host block بھی username مقرر کرتا ہے، اور یہ آپ کے local login name پر ترجیح رکھتا ہے:

Host vps-prod
  HostName 203.0.113.10
  User deploy

اگر آپ نے account خود بنایا تھا اور پھر اس کے ساتھ login نہیں کر سکے تو غالباً key image کے default user کے لیے install ہوئی تھی اور اس نئے account میں copy نہیں کی گئی۔ یہ قدم نئے VPS کے ابتدائی دس منٹ کا حصہ ہے، اور اسے چھوڑ دینا آسان ہے۔

وجہ 2: آپ کے خیال میں جو key بھیجی جا رہی ہے، حقیقت میں وہ نہیں بھیجی جا رہی

بطور ڈیفالٹ، ssh صرف ssh-agent میں موجود keys اور ~/.ssh میں موجود filenames کے ایک مقررہ مجموعے کو پیش کرتا ہے: id_ed25519، id_ecdsa، id_rsa، اور ان ناموں کے hardware اور DSA variants۔ ~/.ssh/vps-prod کے طور پر محفوظ کی گئی key ssh کو اس وقت تک نظر نہیں آتی جب تک آپ اسے نام سے متعین نہ کریں۔ اسی لیے verbose output میں اس کے لیے Offering public key لائن نظر نہیں آتی۔

فائل کا نام متعین کریں اور agent کی keys کو اس کی جگہ لینے سے روکیں:

ssh -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@203.0.113.10

جب agent میں keys موجود ہوں تو صرف -i کافی نہیں ہوتا، کیونکہ ssh پہلے agent کی keys اور آخر میں نامزد فائل پیش کرتا ہے۔ یہ اہم ہے، کیونکہ server ہر مسترد شدہ key کو MaxAuthTries کی حد میں شمار کرتا ہے، جس کی default قدر 6 ہے۔ اگر agent میں سات keys موجود ہوں تو آپ کی درست key تک پہنچنے سے پہلے حد پوری ہو سکتی ہے، اور پیغام بدل کر یہ ہو جاتا ہے:

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

IdentitiesOnly=yes کوشش کو آپ کی فراہم کردہ فائل تک محدود کرتا ہے۔ ssh-add -l سے دیکھیں کہ agent میں کون سی keys موجود ہیں، اور اگر اس میں کئی سال پرانی keys جمع ہو گئی ہوں تو ssh-add -D سے انہیں صاف کریں۔ پھر settings درج کر دیں تاکہ اگلا login flags یاد رکھنے پر منحصر نہ ہو:

Host vps-prod
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/vps-prod
  IdentitiesOnly yes

client کی طرف ایک اور مسئلہ بھی ہو سکتا ہے۔ ssh ایسی private key استعمال کرنے سے انکار کرتا ہے جسے آپ کی اپنی machine پر دوسرے accounts پڑھ سکتے ہوں۔ یہ warning دکھا کر key کو نظرانداز کر دیتا ہے، اس لیے key کبھی پیش نہیں کی جاتی اور server اسے کبھی نہیں دیکھتا:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/you/.ssh/vps-prod' are too open.

chmod 600 ~/.ssh/vps-prod اس مسئلے کو درست کرتا ہے۔ USB stick یا Windows share کے ذریعے key منتقل کرنے سے عموماً اس کا mode تبدیل ہو جاتا ہے۔ Keys کہاں رکھی جائیں اور انہیں کیا نام دیا جائے، اس کی وضاحت SSH key management کی بنیادی باتیں میں ہے۔

وجہ 3: public key کبھی authorized_keys تک نہیں پہنچی

اگر ssh -v میں دکھائی دے کہ key بھیجی جا رہی ہے لیکن server پھر بھی انکار کر رہا ہے، تو اگلا سوال یہ ہے کہ آیا وہ key اکاؤنٹ کی authorized_keys file میں موجود ہے۔ اسے چیک کرنے کے لیے اپنے provider کا console کھولیں، کیونکہ آپ SSH کے ذریعے login کر کے یہ نہیں دیکھ سکتے۔

sudo ls -l /home/deploy/.ssh/
sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys

ssh-keygen -lf کسی authorized_keys file میں ہر entry کے لیے ایک fingerprint دکھاتا ہے:

256 SHA256:0eL/8sBw... you@laptop (ED25519)
3072 SHA256:9Tq2yZk... old-laptop (RSA)

ان fingerprints کا اپنے Offering public key line پر موجود fingerprint سے موازنہ کریں۔ اگر وہ list میں موجود نہیں، تو اس اکاؤنٹ پر key نصب نہیں ہے، چاہے آپ کو کچھ اور کرنے کا کتنا ہی یقین کیوں نہ ہو۔

یہ چار عام طریقے ہیں جن سے مسئلہ پیدا ہوتا ہے:

• آپ نے .pub file کے بجائے private key paste کر دی۔ public key line ssh-ed25519 یا ssh-rsa سے شروع ہوتی ہے۔ private key -----BEGIN OPENSSH PRIVATE KEY----- سے شروع ہوتی ہے۔
• paste کئی lines میں wrap ہو گیا۔ ہر entry بالکل ایک line پر ہونی چاہیے، اس لیے wrapped key کو کئی خراب entries کے طور پر پڑھا جاتا ہے اور کوئی entry match نہیں ہوتی۔
• key /root/.ssh/authorized_keys میں چلی گئی، جبکہ آپ deploy کے طور پر login کرتے ہیں، یا اس کے برعکس۔ یہ file ہر account کے لیے الگ ہوتی ہے؛ کوئی مشترکہ file نہیں ہوتی۔
• provider کے "add my key" box نے key صرف image کے default user کے لیے لکھی، اس لیے آپ کے بعد میں بنائے گئے account کی .ssh directory خالی ہے۔

console سے root کے طور پر key شامل کرنے کا محفوظ طریقہ یہ ہے:

sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo tee -a /home/deploy/.ssh/authorized_keys >/dev/null <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyDataHere you@laptop
EOF
sudo chown deploy:deploy /home/deploy/.ssh/authorized_keys
sudo chmod 600 /home/deploy/.ssh/authorized_keys

اس کے بعد دوبارہ sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys چلائیں۔ نئی fingerprint اب list میں ہونی چاہیے۔ ایسی machine سے، جہاں آپ اب بھی password کے ذریعے login کر سکتے ہوں، ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 یہی کام کرتا ہے اور modes بھی درست طور پر set کر دیتا ہے۔

وجہ 4: permissions بہت زیادہ کھلے ہونے پر sshd، authorized_keys کو نظرانداز کیوں کرتا ہے

StrictModes yes، sshd کی default setting ہے۔ اس کے تحت sshd، authorized_keys کو پڑھنے سے انکار کرتا ہے اگر اس file، .ssh directory، یا account کی home directory میں owner کے علاوہ کوئی بھی لکھ سکتا ہو۔ وجہ واضح ہے: اگر group یا world آپ کی home directory میں لکھ سکتا ہے تو اس access والا کوئی بھی account authorized_keys کو تبدیل کرکے login کا اختیار حاصل کر سکتا ہے۔ sshd غیر معتبر path کو ایسے سمجھتا ہے جیسے کوئی key موجود ہی نہ ہو۔

Client کو سادہ Permission denied message دکھائی دیتا ہے۔ Server log میں اصل وجہ درج ہوتی ہے:

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh

یا جب مسئلہ خود file میں ہو:

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

sshd درج ذیل permissions قبول کرے گا:

• Home directory: group-writable اور world-writable نہیں ہونی چاہیے۔ 755، 750 اور 700 کامیاب ہوتے ہیں۔ 775 اور 777 ناکام ہوتے ہیں۔
• ~/.ssh: mode 700۔
• ~/.ssh/authorized_keys: mode 600۔
• Ownership: تینوں objects اسی account کی ملکیت میں ہوں جس سے آپ login کرتے ہیں، root کی ملکیت میں نہیں۔

Ownership بھی mode جتنی اہم ہے۔ /home/deploy/.ssh کے اندر root کی ملکیت والی file اسی check میں ناکام ہوتی ہے۔ یہ اس وقت ہوتا ہے جب آپ اسے sudo nano کے ذریعے بناتے ہیں اور ownership واپس دینا بھول جاتے ہیں۔ دونوں مسائل ایک ساتھ درست کریں:

sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chmod go-w /home/deploy
ls -ld /home/deploy /home/deploy/.ssh

آخری command نتیجہ دکھاتی ہے۔ Home directory پر drwxr-xr-x یا اس سے زیادہ restrictive permission، اور .ssh پر drwx------ درکار ہے۔ اگر یہ strings ابھی واضح نہیں ہیں تو live server پر modes تبدیل کرنے سے پہلے drwxr-xr-x جیسی permission string پڑھنے کا طریقہ دیکھیں۔

Rocky Linux اور AlmaLinux پر SELinux (security-enhanced Linux) کو بھی ممکنہ وجوہات میں شامل کریں۔ غیر معمولی طریقے سے بنائی گئی .ssh directory پر غلط file label ہو سکتا ہے۔ اس صورت میں modes درست نظر آنے کے باوجود sshd کو read access سے انکار ہو جاتا ہے۔ sudo restorecon -Rv /home/deploy/.ssh labels کو دوبارہ درست کرتا ہے، اور sudo ausearch -m avc -ts recent دکھاتا ہے کہ آیا انکار کرنے والا component SELinux تھا۔

وجہ 5: sshd آپ کو مسترد کرنے کے لیے configured ہے

موجودہ Ubuntu یا Debian سسٹم پر /etc/ssh/sshd_config پڑھنا کافی نہیں ہے۔ یہ فائل Include /etc/ssh/sshd_config.d/*.conf سے شروع ہوتی ہے، اور OpenSSH ہر setting کے لیے اسے ملنے والی پہلی value برقرار رکھتا ہے۔ اس لیے 50-cloud-init.conf جیسی drop-in فائل پہلے پڑھی جاتی ہے اور main فائل میں نیچے کی طرف کی گئی کسی بھی ترمیم پر غالب آتی ہے۔ اسی وجہ سے ترمیم درست دکھائی دے سکتی ہے، لیکن اس سے کوئی تبدیلی واقع نہیں ہوتی۔

sshd سے وہ configuration معلوم کریں جسے وہ حقیقت میں استعمال کر رہا ہے:

sudo sshd -T | grep -Ei 'pubkeyauth|authorizedkeysfile|permitrootlogin|allowusers|allowgroups|denyusers'

درست جواب کچھ اس طرح دکھائی دیتا ہے:

permitrootlogin prohibit-password
pubkeyauthentication yes
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

اپنے output میں یہ چیزیں تلاش کریں:

• pubkeyauthentication no۔ کوئی بھی key کبھی قبول نہیں کی جائے گی۔ یہ ssh -v میں پہلے Authentications that can continue: list کی صورت میں بھی ظاہر ہوتی ہے، جس میں publickey موجود نہیں ہوتا۔
• authorizedkeysfile کسی دوسری جگہ کی طرف اشارہ کر رہا ہو، مثلاً /etc/ssh/authorized_keys/%u۔ اس صورت میں home directory میں موجود آپ کی فائل مکمل طور پر نظرانداز کی جاتی ہے، اور وجہ 4 کے mode rules نئی path پر لاگو ہوتے ہیں۔
• allowusers یا allowgroups موجود ہو۔ جو account فہرست میں شامل نہیں، اسے عین اسی error کے ساتھ اور کسی وضاحت کے بغیر مسترد کر دیا جاتا ہے۔ denyusers اور denygroups اس کے برعکس یہی کام کرتے ہیں۔
• permitrootlogin no اس وقت موجود ہو جب آپ root کے طور پر login کرنے کی کوشش کر رہے ہوں۔ prohibit-password مفید درمیانی setting ہے: root key استعمال کر سکتا ہے، لیکن password نہیں۔

سادہ sshd -T میں Match blocks ظاہر نہیں ہوتے، کیونکہ ان کا نتیجہ اس بات پر منحصر ہوتا ہے کہ connection کون کر رہا ہے۔ کسی ایک مخصوص connection کے بارے میں معلوم کریں:

sudo sshd -T -C user=deploy,host=vps.example.com,addr=198.51.100.7

ایک اور setting پرانی keys کو متاثر کرتی ہے۔ OpenSSH 8.8 نے SHA-1 signatures (ssh-rsa) کو default طور پر قبول کرنا بند کر دیا۔ اس لیے جو RSA key برسوں تک کام کرتی رہی ہو، وہ server upgrade کے فوراً بعد کام کرنا بند کر سکتی ہے۔ client اس کی واضح اطلاع دیتا ہے:

debug1: send_pubkey_test: no mutual signature algorithm

درست حل نئی key بنانا ہے: ssh-keygen -t ed25519 -C "deploy@vps-prod"، پھر اوپر بتائی گئی procedure کے مطابق .pub فائل install کریں۔ server پر PubkeyAcceptedAlgorithms +ssh-rsa setting کرنے سے پرانی signatures دوبارہ فعال ہو جاتی ہیں اور آپ آج server تک رسائی حاصل کر لیتے ہیں۔ اسے عارضی رسائی کا طریقہ سمجھیں، کام کا آخری حل نہیں۔ server-side کی باقی قابلِ جائزہ settings VPS پر SSH server کو harden کرنا میں دی گئی ہیں۔

تنصیب شدہ public key کے ساتھ private key کے مطابقت رکھنے کا ثبوت کیسے حاصل کریں

اس error میں زیادہ تر قیاس آرائی اس لیے ہوتی ہے کہ معلوم نہیں ہوتا کہ دو files ایک ہی جوڑی ہیں یا نہیں۔ ایک command اس کا جواب دیتی ہے:

ssh-keygen -y -f ~/.ssh/vps-prod

یہ private key سے اخذ کردہ public key دکھاتی ہے۔ یہ اس کے ساتھ موجود .pub file کو کبھی نہیں پڑھتی، اس لیے یہ بتاتی ہے کہ private key حقیقت میں کیا ہے، نہ کہ کوئی پرانی .pub file کیا دعویٰ کرتی ہے۔ اگر key کے ساتھ passphrase ہو تو command اسے طلب کرتی ہے۔ اس سے یہ بھی ثابت ہوتا ہے کہ آپ کو اب بھی passphrase معلوم ہے۔

ssh-keygen -lf ~/.ssh/vps-prod.pub
ssh-add -l

پہلی command ایک public key file کا fingerprint دکھاتی ہے۔ دوسری command وہ fingerprints دکھاتی ہے جو آپ کا agent اپنے پاس رکھتا ہے۔ اب اسی string کے چار نتائج ملا کر دیکھیں: ssh -v کی Offering public key line پر موجود fingerprint، آپ کی .pub file کا fingerprint، server کی authorized_keys میں ssh-keygen -lf کے fingerprints، اور server log میں موجود fingerprint۔ جہاں یہ fingerprints ایک دوسرے سے مختلف ہونا شروع ہوں، مسئلہ وہیں ہے۔

سرور لاگ پڑھیں جب لاگ اِن ناکام ہو

کلائنٹ کو جان بوجھ کر کوئی مفید معلومات نہیں دی جاتی۔ سرور اصل وجہ لاگ میں لکھتا ہے۔ console session میں log follower شروع کریں، پھر اپنے laptop سے ناکام ہونے والی ssh کمانڈ چلائیں۔

sudo journalctl -u ssh -f

Ubuntu 24.04 میں rsyslog بطور ڈیفالٹ انسٹال نہیں ہوتا، اس لیے وہاں /var/log/auth.log موجود نہ ہو سکتی ہے۔ Rocky Linux اور AlmaLinux میں unit کا نام sshd ہے، اور یہی records /var/log/secure میں بھی محفوظ ہوتے ہیں۔

sshd configuration میں LogLevel VERBOSE مقرر کریں اور service reload کریں۔ اس کے بعد ہر کوشش میں وہ fingerprint لاگ ہو گا جو سرور نے حقیقت میں وصول کیا:

Failed publickey for deploy from 198.51.100.7 port 49812 ssh2: ED25519 SHA256:0eL/8sBw...

اس سطر سے معلوم ہوتا ہے کہ خرابی کس طرف ہے۔ اگر fingerprint آپ کو معلوم ہے تو آپ کی key سرور تک پہنچ گئی اور سرور نے اسے مسترد کر دیا ہے؛ اس لیے causes 3، 4 اور 5 دیکھیں۔ اگر fingerprint آپ کو معلوم نہیں تو آپ کے client نے ایسی key بھیجی ہے جس کا آپ نے ارادہ نہیں کیا تھا؛ اس لیے cause 2 پر واپس جائیں۔

اگر لاگ اب بھی واضح نہ ہو تو کسی دوسرے port پر debug mode میں دوسرا sshd چلائیں۔ یہ foreground میں رہتا ہے، ایک connection قبول کرتا ہے، اپنی reasoning دکھاتا ہے، پھر exit ہو جاتا ہے:

sudo /usr/sbin/sshd -ddd -p 2222

اسی سرور کے console session سے loopback address کے ذریعے اس سے connect کریں:

ssh -p 2222 -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@127.0.0.1

127.0.0.1 کے ذریعے connect کرنے سے firewall اس test سے خارج رہتا ہے۔ debug output اس file کا نام دکھاتا ہے جسے اس نے کھولا، وہ fingerprint دکھاتا ہے جس سے اس نے موازنہ کیا، اور refusal کی درست وجہ بتاتا ہے، جس میں Authentication refused: bad ownership or modes for directory /home/deploy جیسی lines بھی شامل ہیں۔ جواب ملنے پر Ctrl+C دبائیں۔ port 22 پر موجود اصل sshd پورے عمل کے دوران متاثر نہیں ہوتا۔

خود کو سرور سے لاک آؤٹ ہونے سے کیسے بچائیں

سرور configuration میں ترمیم کرنے والے ہر مرحلے کے لیے ایسا متبادل رسائی طریقہ ضروری ہے جو SSH پر منحصر نہ ہو۔ یہ طریقہ اس وقت ترتیب دیں جب SSH ابھی کام کر رہا ہو، اس کے خراب ہونے کے بعد نہیں۔

1. اپنے provider کا console، serial یا VNC (virtual network computing) کے ذریعے کھولیں، اور تصدیق کریں کہ آپ وہاں لاگ اِن کر سکتے ہیں۔
2. یقینی بنائیں کہ آپ کو sudo والے account کے لیے ایک درست local password معلوم ہے۔ اگر ایسا password موجود نہیں ہے تو پہلے provider console سے root password reset کریں۔
3. اپنی موجودہ SSH session کھلی رکھیں۔ کھلی session systemctl restart ssh کے بعد بھی برقرار رہتی ہے، اس لیے نئی configuration غلط ہونے کی صورت میں یہ دوبارہ رسائی کا ذریعہ رہتی ہے۔
4. restart کرنے سے پہلے syntax چیک کریں: sudo sshd -t file درست ہونے پر کچھ output نہیں دیتا، اور file غلط ہونے پر file اور line number دکھاتا ہے۔
5. پہلی terminal بند کرنے سے پہلے دوسری terminal کھولیں اور نئے سرے سے login کریں۔ خراب configuration نئے logins روک دیتی ہے اور موجودہ logins کو برقرار رکھتی ہے، اس لیے جس session میں آپ موجود ہیں وہ یہ نہیں بتا سکتی کہ تبدیلی کامیاب ہوئی یا نہیں۔

Debian اور Ubuntu پر sudo systemctl restart ssh سے، یا Rocky Linux اور AlmaLinux پر sudo systemctl restart sshd سے restart کریں۔ Ubuntu 24.04 میں sshd ایک socket unit سے start ہوتا ہے، اس لیے Port یا ListenAddress میں تبدیلی کے مؤثر ہونے سے پہلے sudo systemctl restart ssh.socket بھی چلانا ضروری ہے۔

FAQ

جب یہی key دوسرے server پر کام کرتی ہے تو مجھے Permission denied (publickey) کیوں ملتا ہے؟

کیونکہ key درست ہے، لیکن اس کے اردگرد کوئی مسئلہ موجود ہے۔ ssh -v چلائیں اور Offering public key لائن تلاش کریں۔ اگر آپ کی key درج نہیں ہے تو ssh نے اسے بھیجا ہی نہیں: file، ~/.ssh میں default نام کے تحت موجود نہیں ہے اور agent میں load بھی نہیں ہوئی، اس لیے -i /path/to/key -o IdentitiesOnly=yes شامل کریں۔ اگر key درج ہے لیکن server پھر بھی اسے مسترد کرتا ہے تو وہ key account کی authorized_keys میں موجود نہیں، اس کے path پر group کو write access حاصل ہے، یا sshd config صارف کو روک رہی ہے۔ Server log ان صورتوں میں فرق واضح کرتا ہے۔

میں کیسے دیکھوں کہ SSH حقیقت میں کون سی key بھیج رہا ہے؟

ssh -v host ہر key کے لیے ایک debug1: Offering public key: لائن دکھاتا ہے۔ ہر لائن source file اور SHA256 fingerprint بتاتی ہے۔ ssh-add -l ان fingerprints کی فہرست دکھاتا ہے جو agent کے پاس موجود ہیں۔ ssh-keygen -lf ~/.ssh/id_ed25519.pub کسی ایک key file کا fingerprint دکھاتا ہے، جبکہ ssh-keygen -y -f ~/.ssh/id_ed25519 وہ public key دکھاتا ہے جو واقعی کسی private key سے اخذ ہوتی ہے۔ Login کامیاب ہونے کے لیے Offering لائن کا fingerprint، server کی authorized_keys پر چلائے گئے ssh-keygen -lf کے output میں بھی موجود ہونا چاہیے۔

sshd میری authorized_keys file کو نظرانداز کیوں کرتا ہے؟

کیونکہ StrictModes default طور پر فعال ہے، اور file، .ssh directory، یا home directory میں سے کوئی ایک group یا world کے لیے writable ہے، یا غلط account کی ملکیت ہے۔ sshd ایسے path پر اعتماد نہیں کرے گا جسے کوئی دوسرا تبدیل کر سکتا ہو، اس لیے یہ ایسے عمل کرتا ہے جیسے کوئی key موجود ہی نہ ہو۔ Home directory کی permissions 755 یا اس سے زیادہ سخت مقرر کریں، .ssh کو 700 پر، اور authorized_keys کو 600 پر مقرر کریں۔ تینوں کی ملکیت login account کے پاس ہونی چاہیے۔ LogLevel VERBOSE کے ساتھ server Authentication refused: bad ownership or modes for directory /home/deploy/.ssh record کرتا ہے۔

Server upgrade کے فوراً بعد میری key نے کام کرنا کیوں بند کر دیا؟ کیا تبدیل ہوا؟

اگر یہ RSA key ہے تو غالباً SHA-1 میں تبدیلی اس کی وجہ ہے۔ OpenSSH 8.8 نے ssh-rsa SHA-1 signatures کو default طور پر غیر فعال کر دیا ہے، اس لیے ایسی key اب مسترد ہو جاتی ہے جو صرف اسی طریقے سے sign کر سکتی ہے۔ Verbose client output میں debug1: send_pubkey_test: no mutual signature algorithm دکھائی دیتا ہے۔ ssh-keygen -t ed25519 کے ذریعے جدید key بنائیں اور اس کی .pub file install کریں۔ اگر فوری access درکار ہو تو server پر PubkeyAcceptedAlgorithms +ssh-rsa کے ذریعے پرانی signatures دوبارہ فعال کی جا سکتی ہیں۔ نئی key کے کام کرنے کے بعد یہ line حذف کر دیں۔

میں نے sshd_config میں ترمیم کی اور اب بالکل login نہیں کر سکتا۔ واپس access کیسے حاصل کروں؟

اپنے provider کا console استعمال کریں۔ یہ SSH کے ذریعے نہیں چلتا۔ وہاں local password سے login کریں، syntax error اور اس کا line number دیکھنے کے لیے sudo sshd -t چلائیں، تبدیلی واپس کریں، اور service restart کریں۔ پھر sudo sshd -T چیک کر کے running values کی تصدیق کریں، کیونکہ /etc/ssh/sshd_config.d/ میں موجود file main config کو override کر سکتی ہے۔ اگر آپ کے پاس local password نہیں ہے تو پہلے console سے root password reset کریں، پھر file درست کریں۔