SSH رابطے کا مسئلہ صحیح مرحلے پر جانچیں
Ubuntu VPS سے SSH رابطہ ناکام ہو تو آخری error کے مطابق اگلا check چنیں۔ Network، service، authentication اور host identity مختلف مراحل ہیں۔ جو رسائی ابھی چل رہی ہے اسے برقرار رکھتے ہوئے وجہ تلاش کریں۔
VPSuntu · تازہ کاری · تقریباً 5 منٹ
اس مضمون میں
ایک ناکامی ریکارڈ کریں، working access بچائیں
کام کرنے والا session کھلا رکھیں اور provider recovery console تلاش کریں۔ Client commands اپنے Linux/macOS/WSL پر چلائیں؛ server commands existing access یا authenticated console میں۔
Documentation address 203.0.113.10، user ubuntu، port 22 اور private-key path کو اپنے صحیح values سے بدلیں۔ پہلے evaluated client settings دیکھیں، پھر ایک fresh connection آزمائیں۔
ssh -G -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10hostname، user، port، identityfile اور proxy settings پڑھیں۔ دوسری command اسی کوشش کے لیے connection sharing بند کرتی ہے۔ وقت اور آخری error محفوظ کریں۔ نئی host-key prompt کو نیچے والے trusted طریقے سے جانچیں۔ Debug output share کرنے سے پہلے identifiers redact کریں؛ private key کبھی share نہ کریں۔
Error کے مرحلے سے راستہ منتخب کریں
چھوٹی اسکرین پر باقی کالم دیکھنے کے لیے جدول کو پہلو میں اسکرول کریں۔
| Message یا مرحلہ | کیا معلوم ہوتا ہے | اگلی جانچ |
|---|---|---|
| Connection timed out، اتصال سے پہلے | TCP connection مکمل نہیں ہوئی | Address، route، firewalls، provider state |
| Connection refused | اس address/port پر active rejection | صحیح port، listener، reject rules |
| Permission denied (publickey) | Authentication تک پہنچے، key قبول نہیں ہوئی | User، offered key، server policy |
| REMOTE HOST IDENTIFICATION HAS CHANGED | Presented host key محفوظ شناخت سے مختلف ہے | پہلے trusted identity verification |
یہ signs وجہ محدود کرتے ہیں، ایک ہی سبب ثابت نہیں کرتے۔ Connection established آنے کے بعد timeout ہو تو SSH handshake اور logs دیکھیں؛ تمام packets blocked فرض نہ کریں۔
Timeout میں network path دیکھیں
ssh -v کی destination کو provider کے موجودہ address سے ملائیں۔ Hostname میں پرانا DNS یا دوسری IPv6 destination ہو سکتی ہے۔ Public address، VPN یا jump host کی ضرورت معلوم کریں۔
Instance running ہو، route موجود ہو، صحیح SSH port اور آپ کا موجودہ public source IP permitted ہو۔ گھر کا IP بدلنے سے پرانا /32 غلط ہو سکتا ہے۔ Console سے guest firewall بھی دیکھیں۔
Oracle میں security lists، NSGs، routing اور image firewall سب لاگو ہیں۔ UFW install یا iptables flush تشخیص نہیں۔ Oracle network setup دیکھیں۔ Ping fail ہونا اکیلا SSH unavailable ثابت نہیں کرتا۔
Refused میں listener اور service جانچیں
Refusal اس destination کی شناخت ثابت نہیں کرتی۔ VPS اور port کی تصدیق کے بعد server پر موجودہ access یا console میں یہ read-only checks چلائیں۔
systemctl status ssh.service ssh.socket --no-pager
sudo ss -lntp
sudo /usr/sbin/sshd -t
sudo journalctl -u ssh.service -u ssh.socket --since '15 minutes ago' --no-pagerصحیح port/address کا listener دیکھیں اور اپنی کوشش کے وقت سے logs ملائیں۔ Ubuntu socket activation استعمال کر سکتا ہے؛ ssh.socket سن رہا ہو تو inactive ssh.service اکیلی failure نہیں۔
sshd -t daemon شروع کیے بغیر config اور host-key validity دیکھتا ہے۔ خاموش success، network access ثابت نہیں کرتی۔ Error آئے تو متعلقہ file/setting حل کریں؛ اندھا restart نہ کریں۔
Public key مسترد ہو تو account اور key ملائیں
Provider کا درست initial account یا اپنا بنایا administrator استعمال کریں۔ Client debug میں offered fingerprint دیکھیں۔ Agent کی اضافی keys محدود کرنے کے لیے اپنے کمپیوٹر پر:
ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10Configured IdentityFile entries اب بھی لاگو ہو سکتی ہیں؛ ssh -G دیکھیں۔ Local key unreadable یا permissions زیادہ کھلی ہوں تو اسی file کی رسائی پہلے درست کریں۔
Server پر target account اور authorized public keys دیکھیں۔ مثال /home/ubuntu فرض کرتی ہے؛ getent سے ملا home لگائیں۔
getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keysAuthorized fingerprints کو offered key سے ملائیں۔ Journal میں ownership، permissions اور policy errors دیکھیں۔ AuthorizedKeysFile، included snippets، Match rules اور provider-managed key service مختلف path دے سکتے ہیں۔ موجودہ keys محفوظ رکھیں؛ وجہ چھپانے کے لیے StrictModes بند یا passwords enable نہ کریں۔
بدلی host identity کی پہلے تصدیق
Rebuild یا IP reassignment سے host key بدل سکتی ہے، مگر غلط endpoint یا interception بھی ممکن ہے۔ Authenticated provider panel میں instance identifier اور planned rebuild دیکھیں۔
Trusted guest console میں client warning والے algorithm کی public host key دیکھیں۔ Ed25519 کے لیے:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256SHA256 کو client warning سے ملائیں۔ یہ server key ہے، login key یا console gateway key نہیں۔ Verified replacement کے بعد صرف اسی host کی saved entry بدلیں، پہلے file backup کریں اور باقی entries محفوظ رکھیں۔ known_hosts پوری حذف یا checking bypass نہ کریں۔ وجہ نہ ملے تو connection روک کر تحقیق کریں۔
صرف پہچانی گئی خرابی درست کرکے fresh session آزمائیں
غلط address، user، key، محدود network rule یا config error کو درست کریں۔ Server change کے دوران independent access بچائیں اور SSH configuration پہلے validate کریں۔ Port کی تبدیلی socket activation کو بھی متاثر کر سکتی ہے۔
Original attempt، connection sharing بند کرکے دوبارہ کریں۔ Fresh login صحیح account پر پہنچے اور ضروری sudo کام کرے۔ پرانا session برقرار رہنا یہ test نہیں۔ Failure اور correction لکھیں، پھر VPS setup جاری رکھیں۔
سوال جواب
SSH ٹھیک کرنے کے لیے Ubuntu reinstall کروں؟
پہلے وجہ معلوم کریں۔ غلط address، user یا key کے لیے reinstall ضروری نہیں، اور اس سے data ضائع ہو سکتا ہے۔ کوئی access نہ بچے تو provider recovery اپنائیں۔
Console چلنا SSH کی کامیابی ثابت کرتا ہے؟
نہیں۔ Console اور public SSH کے راستے مختلف ہیں۔ Listener، account authentication اور network rules اب بھی SSH کو اجازت دینے چاہییں۔