SSH कनेक्शन की समस्या का सही कारण खोजें
SSH कनेक्शन की समस्या में पहले error का प्रकार पहचानें। Network timeout, service refusal, rejected public key और बदली हुई host identity के checks अलग हैं। जो access अभी काम करता है उसे बचाकर कारण खोजें।
VPSuntu · अपडेट · लगभग 5 मिनट में पढ़ें
इस गाइड में
एक failure दर्ज करें और working access बचाएँ
मौजूदा SSH session खुला रखें और provider recovery console ढूँढें। Client commands अपने Linux/macOS/WSL computer पर और server commands existing session या authenticated console में चलाएँ।
203.0.113.10, ubuntu, port 22 और key path को अपने असली values से बदलें। पहले evaluated settings देखें, फिर connection sharing बंद करके एक नया प्रयास करें।
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 पढ़ें। समय और अंतिम error लिखें। नई host prompt को आगे बताए trusted तरीके से verify करें। Debug output साझा करने से पहले पहचान योग्य paths/addresses हटाएँ; private key कभी साझा न करें।
Error के अनुसार सही दिशा चुनें
छोटी स्क्रीन पर सभी कॉलम देखने के लिए तालिका को बगल में स्क्रॉल करें।
| Message या चरण | संकेत | अगली जाँच |
|---|---|---|
| Connection timed out, TCP बनने से पहले | Connection पूर्ण नहीं हुई | Address, routing, firewall और instance state |
| Connection refused | उस port/address पर active rejection | सही port, listener और reject rules |
| Permission denied (publickey) | Authentication तक पहुँचे, key नहीं मानी गई | User, offered key और policy |
| REMOTE HOST IDENTIFICATION HAS CHANGED | Saved और presented host identity अलग | पहले trusted fingerprint verification |
ये observations कारण सीमित करते हैं, एक कारण साबित नहीं करते। यदि debug में पहले Connection established लिखा है और बाद में timeout है, तो handshake और logs देखें; केवल packet block मान लेना गलत होगा।
Timeout में network path जाँचें
ssh -v की destination को current provider address से मिलाएँ। Hostname में stale DNS या अलग IPv6 address हो सकता है। देखें कि VPS public address, VPN या jump host चाहता है।
Instance running, public route मौजूद, सही destination port और आपका current public source IP allowed होना चाहिए। Home IP बदलने पर पुराना /32 rule बेकार हो सकता है। Console से guest firewall भी देखें।
Oracle में security lists, NSGs, routing और image firewall सभी लागू हैं। UFW install करना या iptables flush करना diagnosis नहीं है। Oracle networking प्रक्रिया देखें। Ping fail होने से अकेले SSH बंद साबित नहीं होता।
Refused connection में listener और service देखें
Refusal destination को आपका intended VPS प्रमाणित नहीं करती। Identity तथा port पुष्टि करके existing 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 और attempt के समय के logs देखें। Ubuntu socket activation इस्तेमाल कर सकता है: ssh.socket सुन रहा हो तो inactive ssh.service अकेले failure का प्रमाण नहीं।
sshd -t configuration और host keys की validity देखता है, daemon शुरू नहीं करता। Silent success network reachability साबित नहीं करता। Error हो तो उसी file/setting का कारण समझें; service को अंधाधुंध restart न करें।
Public key reject हो तो account और key मिलाएँ
Provider का initial account या अपना बनाया administrator चुनें। Client debug में offered fingerprint देखें। Agent की अनावश्यक keys कम करने के लिए client पर यह retry करें।
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 पढ़ें। Client private key unreadable हो या permissions बहुत खुली हों तो पहले उसी local file का access ठीक करें।
Server पर target user तथा authorized public keys जाँचें। यहाँ /home/ubuntu माना है; getent से मिला असली home path लगाएँ।
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 और offered fingerprints मिलाएँ। Journal, ownership, permissions, AuthorizedKeysFile, included snippets और Match rules देखें। Provider-managed key service हो तो उसका तरीका अलग हो सकता है। पुरानी keys बचाएँ; StrictModes बंद करके या passwords enable करके कारण न छिपाएँ।
बदली host identity को पहले सत्यापित करें
Rebuild या reassigned IP से host key बदल सकती है; unexpected बदलाव गलत endpoint या interception भी हो सकता है। Authenticated provider panel में instance identifier और planned rebuild देखें।
Guest के trusted console में client वाले algorithm की public host key देखें। Ed25519 के लिए:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256यह server key है, आपकी login key या console gateway की key नहीं। Trusted SHA256 fingerprint client warning से मिलाएँ। Verified replacement के बाद उसी server की saved entry बदलें और unrelated entries बचाएँ। पूरा known_hosts हटाना या checking bypass करना समाधान नहीं। Identity अस्पष्ट हो तो कनेक्शन रोकें।
सुधार को नई session में जाँचें
पहचाने गए address, user, key, narrow network rule या configuration को ठीक करें। Server change के दौरान independent access बचाएँ और configuration apply करने से पहले validate करें। Port बदलने में socket activation settings भी शामिल हो सकती हैं।
Connection sharing बंद करके वही attempt दोहराएँ। Expected account और आवश्यक sudo access जाँचें। पुराना session जुड़ा रहना यह परीक्षण नहीं है। कारण और बदलाव लिखें, फिर deployment प्रक्रिया पर लौटें।
सवाल-जवाब
क्या SSH ठीक करने के लिए Ubuntu reinstall करना चाहिए?
पहले diagnosis करें। गलत address, user या key के लिए reinstall आवश्यक नहीं और उससे डेटा नष्ट हो सकता है। Access न बचे तो provider recovery प्रक्रिया अपनाएँ।
Console काम करे तो क्या SSH भी चलना चाहिए?
Console और public SSH के रास्ते अलग हैं। Listener, user authentication तथा network rules फिर भी सही होने चाहिए।