VPS SSH कनेक्शन त्रुटींचे निदान करा

एक अयशस्वी प्रयत्न नोंदवा आणि चालू प्रवेश जपा

यशस्वी SSH session बंद करू नका; provider recovery console शोधा. Client commands तुमच्या Linux/macOS/WSL संगणकावर, server commands विद्यमान SSH किंवा authenticated console मध्ये चालतात. Server commands स्थानिक terminal मध्ये चालवू नका.

203.0.113.10, ubuntu, port 22 आणि key path स्वतःच्या तपशिलांनी बदला. पत्ता उदाहरणासाठी राखीव आहे. आधी client settings, मग एक नवीन प्रयत्न पहा:

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.10

Hostname, user, port, identityfile व proxy तपासा. दुसरी command या प्रयत्नासाठी connection sharing बंद करते. वेळ व अंतिम error नोंदवा; नवीन host prompt पुढील identity पद्धतीने पडताळा. Debug output शेअर करण्याआधी username, address, paths काढा; private key कधीही शेअर करू नका.

Error शी जुळणारी शाखा निवडा

लहान स्क्रीनवर सर्व स्तंभ पाहण्यासाठी तक्ता बाजूला सरकवा.

हे निरीक्षण कारण निश्चित करत नाही. Timeout आधी Connection established दिसले असेल तर सर्व packets blocked मानण्याऐवजी handshake आणि server logs तपासा.

Timeout असल्यास network मार्ग तपासा

ssh -v मधील destination provider panel शी जुळवा. जुना DNS किंवा वेगळा IPv6 पत्ता चुकीकडे नेऊ शकतो. Public IP, VPN किंवा jump host ने प्रवेश अपेक्षित आहे का पहा. Instance running व public route तयार आहे का तपासा. Provider firewall मधील प्रत्यक्ष SSH port व सध्याचा public source तपासा; घरचा IP बदलल्यावर जुना /32 नियम अपुरा ठरतो. Guest firewall console मधून पहा.

Oracle मध्ये security lists, NSGs, routing व guest firewall सर्व महत्त्वाचे आहेत. UFW बसवणे किंवा iptables flush करणे निदान नाही. Image rules जपा; Oracle network सेटअप पहा. Ping न होणे म्हणजे SSH नक्की बंद आहे असे नाही.

Refused असल्यास listener आणि service पहा

Refusal म्हणजे समोरचा सर्व्हर तुमचाच असल्याची पडताळणी नाही. Identity/port तपासून विद्यमान server access किंवा recovery console मधून read-only commands चालवा:

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

अपेक्षित address/port वर listener आणि प्रयत्नाच्या वेळचे logs पहा. Ubuntu मध्ये socket activation असू शकते: ssh.socket ऐकत असेल तर inactive ssh.service एकट्याने SSH बंद असल्याचे सिद्ध होत नाही. Sshd -t configuration व host keys तपासतो, daemon सुरू करत नाही. Silent success network reachability सिद्ध करत नाही. Error असेल तर ती file/setting ओळखा; आंधळेपणाने restart करू नका.

Public key नाकारल्यास खाते आणि offered identity तपासा

Provider चे initial account किंवा स्वतः तयार केलेले admin वापरा; username चा अंदाज करू नका. Client debug मध्ये offered fingerprint पहा. Agent मधील इतर keys कमी करण्यासाठी स्थानिक retry:

ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

Configured IdentityFile अजून लागू असू शकतात; ssh -G पहा. Key unreadable किंवा permissions फार उघड्या असल्यास आधी स्थानिक फाइलचा प्रवेश दुरुस्त करा. Server वर 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_keys

Authorized fingerprints offered key शी जुळवा. Ownership, permissions व account policy साठी journal पहा. Default path नसल्यास AuthorizedKeysFile, included snippets व Match rules तपासा; provider-managed key service वेगळी पद्धत वापरू शकते. विद्यमान keys जपा. कारण लपवण्यासाठी StrictModes बंद किंवा password login सुरू करू नका.

बदललेली host identity आधी पडताळा

Rebuild किंवा IP reallocation मुळे key बदलू शकते; अनपेक्षित बदल चुकीचे endpoint किंवा interception देखील सूचित करतो. Authenticated panel मध्ये instance ID आणि नियोजित rebuild तपासा. Guest च्या trusted console मध्ये client ने दाखवलेल्या algorithm ची public host key पहा. Ed25519 साठी:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

SHA256 client warning शी जुळवा. ही server key आहे; login key किंवा console gateway key नाही. पडताळलेली key बदलल्यास known_hosts चा backup घेऊन फक्त त्या host ची नोंद बदला; बाकी नोंदी जपा. संपूर्ण known_hosts काढू नका किंवा checking टाळू नका. बदल समजत नसेल तर connection थांबवून कारण शोधा.

ठरावीक दुरुस्ती नवीन session मधून तपासा

ओळखलेला address, user, key, narrow network rule किंवा configuration दोष दुरुस्त करा. Server बदलताना स्वतंत्र recovery access ठेवा आणि SSH configuration लागू करण्याआधी तपासा. Port बदलताना socket activation settings लागतील का ते पहा.

Connection sharing बंद ठेवून मूळ प्रयत्न पुन्हा करा. अपेक्षित account वर fresh login आणि आवश्यक sudo चालले पाहिजे. जुने session टिकणे ही चाचणी नाही. दोष व दुरुस्ती नोंदवा आणि deployment मार्गदर्शिकेकडे परत जा.

प्रश्नोत्तरे

दस्तऐवज आणि संदर्भ

• संदर्भ: Ubuntu OpenSSH server documentation
• संदर्भ: OpenSSH client manual
• संदर्भ: OpenSSH client configuration manual
• संदर्भ: OpenSSH server test modes
• संदर्भ: OpenSSH server configuration manual
• संदर्भ: OpenSSH key fingerprint tools
• संदर्भ: Ubuntu 24.04 OpenSSH socket activation
• संदर्भ: Oracle image firewall requirements