SSH: Connection Refused आणि Timed Out मधील फरक

SSH मधील "Connection refused" आणि "Connection timed out" यांचा अर्थ

SSH connection refused आणि SSH connection timed out हे परस्परविरुद्ध अपयश आहेत. त्यामुळे एका समस्येवरील उपाय दुसऱ्या समस्येसाठी कधीही लागू होत नाही. Refused म्हणजे तुमचे packet server पर्यंत पोहोचले आणि server च्या kernel ने “येथे काहीही listening नाही” असे उत्तर दिले. Timed out म्हणजे उत्तर देणाऱ्या कोणत्याही घटकापर्यंत तुमचे packet पोहोचले नाही. त्यामुळे तुमच्या client ने प्रतीक्षा करून शेवटी प्रयत्न सोडला. Refused ही server वरील service ची समस्या आहे. Timed out ही server च्या पुढील network path ची समस्या आहे.

तुमच्या client ने छापलेली अचूक line वाचा, कारण त्या wording मधून संपूर्ण diagnosis मिळते.

ssh: connect to host 203.0.113.10 port 22: Connection refused
ssh: connect to host 203.0.113.10 port 22: Connection timed out

Timing हा दुसरा संकेत आहे. Refused लगेच परत येते, साधारण एका round trip साठी लागणाऱ्या वेळेत. Timed out संदेश दिसण्यापूर्वी अनेक seconds तसेच राहते, कारण client प्रयत्न सोडेपर्यंत packet पुन्हा पुन्हा पाठवत राहतो. त्याच condition साठी macOS Operation timed out छापते. हा protocol तुमच्यासाठी नवीन असल्यास, SSH कसे कार्य करते आणि sshd काय करते हा या guide मध्ये गृहीत धरलेला background आहे.

"Connection refused" ही चांगली बातमी का आहे

Refused म्हणजे TCP (transmission control protocol) reset होय. तुमचा client port 22 कडे SYN packet पाठवतो. तो इंटरनेटमधून प्रवास करून server च्या network stack पर्यंत पोहोचतो. Kernel ला त्या port वर ऐकणारा socket सापडत नाही. त्यामुळे तो RST (reset) packet ने उत्तर देतो. तुमचा SSH client त्या RST चे रूपांतर Connection refused या संदेशात करतो.

परत आलेला तो एक packet अनेक गोष्टी सिद्ध करतो. Address बरोबर आहे. Host सुरू आहे आणि routing कार्यरत आहे. त्या port कडे जाणारा traffic मार्गातील कोणतीही यंत्रणा शांतपणे टाकून देत नाही. कारण दूरच्या टोकाकडून काहीतरी उत्तर आले आहे. त्यामुळे उरलेली सर्व संभाव्य कारणे server वरच आहेत.

• sshd चालू नाही. ते सुरू होताना अपयशी ठरले किंवा ते enable केलेले नव्हते.
• sshd दुसऱ्या port वर listening करत आहे. हे सहसा hardening बदलानंतर घडते.
• sshd एका address शी bind केलेले आहे, जसे ListenAddress 127.0.0.1. त्यामुळे फक्त server स्वतः त्यापर्यंत पोहोचू शकतो.
• Firewall drop करण्याऐवजी reject करण्यासाठी सेट केलेला आहे. त्यामुळे firewall host च्या वतीने RST पाठवतो. ufw मधील reject action आणि reject with tcp reset ने समाप्त होणारा nftables rule हे दोन्ही असेच कार्य करतात.

यासारखे दिसणारे आणखी एक प्रकरण आहे, पण त्याचे कारण वेगळे आहे: तुम्ही वेगळ्या सुरू असलेल्या host चा address टाइप केला आहे. त्या host ने तुमच्या SYN ला उत्तर दिले, परंतु त्याच्या port 22 वर SSH उपलब्ध नाही. त्यामुळे त्याने तुम्हाला विनम्रपणे नकार दिला. चुकीच्या server वर एक तास खर्च करण्यापूर्वी address निश्चित करा. Linux वर listening port प्रत्यक्षात काय असतो हे समजल्यास हा section अधिक जलद समजतो.

Connection refused कसे दुरुस्त करावे

हे SSH द्वारे दुरुस्त करता येणार नाही, कारण बिघाड SSH मध्येच आहे. तुमच्या provider चे web console किंवा serial console उघडा. तेथे sign in करा. त्यानंतर हे commands क्रमाने चालवा.

systemctl status ssh
sudo ss -tlnp
sudo sshd -T | grep -Ei '^(port|listenaddress|addressfamily)'

Ubuntu आणि Debian वर systemctl status ssh मध्ये unit name वापरले जाते. RHEL आणि AlmaLinux सारख्या त्याच्या rebuilds वर unit sshd असते. ss -tlnp listening state मधील प्रत्येक TCP socket आणि तो वापरणारी process दाखवते. हेच अंतिम प्रमाण आहे: कोणत्याही ओळीत sshd दिसत नसेल, तर configuration file काहीही सांगत असली तरी कोणतेही listening नाही. सर्व Include files merge केल्यानंतरची effective configuration sshd -T दाखवते. /etc/ssh/sshd_config.d/ मधील विसरलेला port येथे दिसतो.

address column काळजीपूर्वक वाचा. 0.0.0.0:22 म्हणजे या मशीनवरील प्रत्येक IPv4 address. [::]:22 म्हणजे प्रत्येक IPv6 address. 127.0.0.1:22 म्हणजे फक्त loopback. त्यामुळे स्थानिक ssh localhost उत्तम प्रकारे कार्यरत असले तरी त्यावरील प्रत्येक remote connection refused होते.

काहीही listening नसेल, तर service सुरू करा. ती सुरू न झाल्यास failure message वाचा.

sudo sshd -t
sudo systemctl enable --now ssh
sudo journalctl -u ssh -n 50 --no-pager

sshd -t configuration parse करते आणि running service मध्ये बदल न करता चुकीच्या directive ची file आणि line number दाखवते. प्रत्येक restart पूर्वी ते चालवा. नाकारलेली configuration असल्यास sshd सुरू होताना बंद होते आणि तुमचे पुढील connection refused होते.

Ubuntu वरील socket activation मधील अडचण

Ubuntu 24.04 मध्ये OpenSSH साठी systemd socket unit उपलब्ध असते. ही unit enabled असल्यास systemd listening port स्वतःकडे ठेवते आणि प्रत्येक connection साठी sshd सुरू करते. त्यामुळे Port 2222 मधील sshd_config बदलल्याने काहीही बदलत नाही आणि server जुन्या port वर प्रतिसाद देत राहतो. कोणतीही configuration संपादित करण्यापूर्वी तुमचा server कोणत्या mode मध्ये आहे ते तपासा.

systemctl is-enabled ssh.socket
systemctl status ssh.socket

socket enabled असल्यास, port sshd_config ऐवजी socket unit मध्ये सेट करा.

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

रिकामी ListenStream= line आवश्यक आहे, कारण systemd मधील list settings आधीपासून configured असलेल्या settings मध्ये भर घालतात. ती line वगळल्यास server दोन्ही ports वर listening करेल. sudo systemctl daemon-reload आणि sudo systemctl restart ssh.socket वापरून बदल लागू करा. त्यानंतर sudo ss -tlnp वापरून नवीन port systemd कडे held आहे याची खात्री करा. VPS वर SSH hardening करताना port बदलणे ही नेहमीची पायरी आहे. मात्र, याच पायरीमुळे लोक स्वतःला server च्या बाहेर लॉक करून घेतात.

"Connection timed out" म्हणजे कोणत्याही बाजूने उत्तर मिळाले नाही

Timeout म्हणजे शांतता. तुमच्या client ने SYN पाठवला, तो एक-दोन मिनिटांत अनेक वेळा पुन्हा पाठवला, पण प्रत्युत्तर म्हणून एकही packet मिळाला नाही. येथे server बद्दल काहीही सिद्ध होत नाही, कारण server कडून कोणतेही उत्तर मिळालेले नाही.

DROP rule मुळे अशीच शांतता निर्माण होते आणि packet drop करणे हा जाणीवपूर्वक केलेला निर्णय असतो. Rejection दिल्यास scanning करणाऱ्या व्यक्तीला host अस्तित्वात असल्याचे समजते. त्यामुळे ufw आणि प्रत्येक cloud provider चे network firewall अवांछित packets discard करतात आणि कोणतेही उत्तर पाठवत नाहीत. तुम्हाला उघडा हवा असलेल्या port वर firewall योग्यरित्या काम करत असल्यामुळे तुमचा timeout सहसा येतो.

• Address चुकीचा आहे: DNS record अजूनही तुम्ही rebuild केलेल्या server कडे निर्देश करत आहे किंवा typo मुळे कोणीही वापरत नसलेल्या address कडे विनंती जात आहे.
• Host सुरू नाही: तो बंद आहे किंवा reboot प्रक्रियेच्या मध्ये आहे. Billing मुळे provider ने केलेले suspension बाहेरून अगदी असेच दिसते.
• Host firewall port 22 वरील traffic drop करत आहे. हे बहुतेक वेळा कोणताही allow rule तयार होण्यापूर्वी ufw enable चालवल्यामुळे होते.
• Instance च्या समोर असलेला provider firewall packet drop करत आहे. त्यामुळे operating system ला तो packet मुळीच दिसत नाही.
• तुमचे स्वतःचे network outbound port 22 block करत आहे. Office आणि hotel connections वर हे सामान्य आहे.

कनेक्शनच्या योग्य बाजूने चाचणी चालवा

सर्वाधिक वेळ वाया घालवणारी चूक ही आहे. पॅकेट ज्या मशीनपर्यंत पोहोचतच नाहीत, त्याच मशीनमधून dropped packet चे निदान करता येत नाही. कमांड चालवण्यासाठी तुम्ही login करू शकत असाल, तर ही समस्या उद्भवलीच नसती. या विभागातील प्रत्येक कमांड तुमच्या स्वतःच्या मशीनवर चालवा.

getent hosts vps.example.com
ssh -G vps.example.com | grep -Ei '^(hostname|port|user)'
ssh -vvv -o ConnectTimeout=10 user@vps.example.com
nc -vz -w 5 203.0.113.10 22

getent hosts तुमची मशीन प्रत्यक्षात वापरणार असलेला address दाखवते. त्यामुळे जुना DNS record काही सेकंदांत शोधता येतो. ssh -G, ~/.ssh/config वाचल्यानंतर तुमचा client लागू करत असलेली settings दाखवते. त्यामुळे hostname, port किंवा user शांतपणे बदलणारा जुना Host block शोधता येतो. ssh -vvv प्रयत्न कितपत पुढे गेला ते दाखवते: address शी connect होत असल्याची शेवटची ओळ दिसल्यानंतर बराच वेळ थांबत असेल, तर तो timeout आहे. त्याउलट, remote OpenSSH version दाखवणारी ओळ दिसत असेल, तर TCP आधीच यशस्वी झाले आहे आणि खरी समस्या authentication ची आहे. Windows वर PowerShell मधील Test-NetConnection 203.0.113.10 -Port 22 हे nc ची जागा घेते.

Host ची नव्हे, port ची चाचणी करा. ping अयशस्वी झाले, तरी त्यातून काहीही सिद्ध होत नाही, कारण अनेक providers edge वर ICMP (internet control message protocol) filter करतात. ping यशस्वी झाला, तरी त्यातूनही काहीही सिद्ध होत नाही, कारण तो port 22 बद्दल काहीही सांगत नाही.

यानंतर अशी एकच variable बदला जी कोणतीही command तुमच्यासाठी बदलू शकत नाही: तुमचे network. Phone hotspot वरून पुन्हा प्रयत्न करा. Hotspot वरून connection होत असेल आणि desk network वरून होत नसेल, तर block इंटरनेटच्या तुमच्या बाजूला आहे किंवा तुमच्या office address वर server ने बंदी घातली आहे.

सर्व्हरवरून दिसत नसलेला provider firewall

बहुतेक VPS panels मध्ये network firewall असतो. त्याला security group किंवा cloud firewall असेही म्हणतात. हा firewall तुमच्या instance च्या upstream वर चालतो आणि स्वतःची rule list ठेवतो. ufw status सर्व्हरवरून हा firewall पाहू शकत नाही. त्यामुळे “पण मी port 22 आधीच allow केला आहे” हे वाक्य वारंवार ऐकायला मिळते. box वरील एकही rule पुन्हा लिहिण्यापूर्वी panel उघडा आणि ती list तपासा.

हा प्रश्न एका command ने निश्चित करता येतो. त्यासाठी console access आवश्यक आहे. सर्व्हरवर तो command सुरू करा. तो चालू असताना तुमच्या laptop वरून connect करण्याचा प्रयत्न करा.

sudo tcpdump -ni any tcp port 22

तुमचा client प्रयत्न करत असताना काहीही दिसत नसेल, तर packets operating system पर्यंत पोहोचण्यापूर्वीच discard होत आहेत. त्यामुळे fault provider firewall मध्ये किंवा host कडे जाणाऱ्या route मध्ये आहे. SYN packets पोहोचत असतील आणि कोणताही reply बाहेर जात नसेल, तर drop स्थानिक आहे आणि तो ufw किंवा nftables शी संबंधित आहे. या एकाच चाचणीमुळे timeout चा branch दोन भागांत विभागला जातो. त्यामुळे console वापरण्याचा हा प्रयत्न उपयुक्त ठरतो.

ufw क्रम, IPv6 आणि स्वतःला लावलेली बंदी

ufw च्या क्रमातील चुकीमुळे इतर कोणत्याही कारणापेक्षा जास्त वापरकर्ते लॉक आउट होतात. sudo ufw enable लगेच येणाऱ्या कनेक्शनसाठी deny ची default policy लागू करते. त्यामुळे SSH चा नियम नसल्यास तुमचे सध्याचे session established state मुळे सुरू राहते, पण प्रत्येक नवीन कनेक्शन timeout होते. आधी allow करा आणि त्यानंतर enable करा.

sudo ufw allow OpenSSH
sudo ufw status verbose

OpenSSH application profile मध्ये फक्त port 22 समाविष्ट आहे. SSH 2222 वर हलवण्याची योजना असल्यास, आवश्यक नियम sudo ufw allow 2222/tcp हा आहे. तो port बदलण्यापूर्वी जोडा; बदल केल्यानंतर नाही. विस्तृत नियमसंच VPS साठी ufw firewall ची मूलभूत माहिती मध्ये दिला आहे. सुरक्षित क्रम नवीन VPS वर पहिल्या दहा मिनिटांत काय करावे याचाही भाग आहे.

IPv6 मुळे timeout होतो आणि त्याचे कारण असामान्य वाटू शकते. hostname मध्ये AAAA record असल्यास तुमचा client प्रथम IPv6 वापरतो. त्यामुळे IPv6 चे नियम नसलेला server प्रतिसाद देत नाही, तर साधा IPv4 प्रयत्न यशस्वी होतो. दोन्हींची स्वतंत्रपणे हाताने चाचणी करा.

ssh -4 user@vps.example.com
ssh -6 user@vps.example.com

-4 कनेक्ट होते आणि -6 कनेक्ट होत नसेल, तर दुरुस्ती server वरील IPv6 नियमांमध्ये करावी लागेल. ufw मध्ये IPv6 साठी तोच port उघडणे याची प्रक्रिया दाखवते.

तुम्ही स्वतःलाच बंदी घातलेली असू शकते. fail2ban authentication log वर लक्ष ठेवते आणि वारंवार अयशस्वी होणाऱ्या addresses विरुद्ध firewall rule घालते. त्यामुळे चुकीची key किंवा पार्श्वभूमीत पुन्हा प्रयत्न करणारी script संपूर्ण कार्यालयाच्या address ला लॉक आउट करू शकते. कनेक्शन टाकून देणारी बंदी timeout सारखी दिसते. कनेक्शन नाकारणारी बंदी त्याऐवजी No route to host परत करते. Console मधून:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 198.51.100.24

तुमचा स्वतःचा address ignoreip मध्ये जोडणे हे Ubuntu 24.04 वर कार्यरत fail2ban setup चा भाग आहे.

नकारलेली किंवा वेळ संपल्याने अपयशी न झालेली त्रुटी

No route to host म्हणजे ICMP unreachable संदेश परत आला. तुमच्या स्वतःच्या मशीनकडे त्या नेटवर्ककडे जाणारा मार्ग नसतो किंवा मार्गातील एखाद्या घटकाने प्रशासकीय नकार दिलेला असतो. iptables मधील REJECT नियम असा प्रतिसाद पाठवतो.

Network is unreachable म्हणजे तुमचे स्वतःचे मशीन हा प्रतिसाद देत आहे. त्या address family साठी त्याच्याकडे कोणताही मार्ग नाही. IPv4-only कनेक्शनवर hostname फक्त IPv6 पत्त्यावर resolve झाल्यास सामान्यतः हा प्रतिसाद मिळतो.

kex_exchange_identification: Connection closed by remote host म्हणजे TCP कनेक्शन झाले, पण key exchange पूर्ण होण्यापूर्वी server ने कनेक्शन बंद केले. पोर्ट उघडा आहे आणि sshd सुरू आहे. त्यामुळे server load, MaxStartups किंवा तुम्ही कनेक्ट होत असताना लागू झालेला ban तपासा.

Permission denied (publickey) म्हणजे authentication टप्प्यापर्यंत कनेक्शन पोहोचले, पण तिथे अपयशी झाले. Network आणि firewall दोन्ही ठीक आहेत. त्यामुळे या मार्गदर्शकातील कोणतीही बाब लागू होत नाही. त्याऐवजी SSH वरील Permission denied (publickey) दुरुस्त करणे पहा.

पुन्हा प्रवेश कसा मिळवायचा आणि दुसऱ्यांदा लॉकआउट कसा टाळायचा

प्रत्येक गंभीर VPS होस्ट guest च्या network वर अवलंबून नसलेला console देतो: serial console किंवा browser-based VNC screen. या मार्गदर्शकातील दोन्ही शाखांसाठी हा console recovery route आहे, कारण sshd बंद असतानाही आणि firewall rule मुळे सर्व network traffic discard होत असतानाही तो कार्यरत राहतो. तो panel मध्ये शोधा आणि root किंवा आपल्या नेहमीच्या user म्हणून sign in करा. त्यानंतर वर दिलेल्या तपासण्या चालवा. आपण root password कधीही सेट केला नसेल, तर बहुतेक panel ते reset करू शकतात.

Console उपलब्ध नसल्यास provider चा rescue mode हा fallback आहे. तो एक छोटी recovery system सुरू करतो आणि तुमची disk mount करतो. त्यामुळे तुम्ही /etc/ssh/sshd_config संपादित करू शकता किंवा firewall rule offline delete करून reboot करू शकता.

पुढील lockout टाळण्यासाठी दोन सवयी उपयुक्त ठरतात. sshd किंवा firewall संपादित करताना दुसरे SSH session उघडे ठेवा, कारण नवीन session तपासत असताना established state वर आधारित ते session कार्यरत राहते. तसेच, धोकादायक firewall बदल करण्यापूर्वी आपोआप पूर्वस्थितीत आणण्याची व्यवस्था करा.

sudo systemd-run --unit=ufw-rollback --on-active=10min /usr/sbin/ufw disable
sudo systemctl stop ufw-rollback.timer

पहिली line ufw दहा मिनिटांनी स्वतः बंद होण्यासाठी schedule करते. नवीन rules लागू करा आणि त्या कार्यरत असल्याचे सिद्ध करण्यासाठी नवीन SSH session उघडा. त्यानंतर rollback रद्द करण्यासाठी दुसरी line चालवा. त्याऐवजी तुम्ही स्वतःला lock out केले, तर दहा मिनिटे थांबा; firewall आपोआप बंद होईल. ufw पुन्हा enable करेपर्यंत server वर filtering राहणार नाही. त्यामुळे ही पद्धत keyboard समोर असताना वापरा; कायमस्वरूपी व्यवस्था म्हणून वापरू नका.

काम करण्याचा क्रम

1. त्रुटीचा मजकूर वाचा आणि तो दिसण्यासाठी किती वेळ लागला ते लक्षात घ्या.
2. Refused: कन्सोलवर जा आणि listening socket, त्याचा port आणि तो ज्या address शी bound आहे तो तपासण्यासाठी sudo ss -tlnp तपासा.
3. Timed out: तुमच्या स्वतःच्या मशीनवरून address ची पुष्टी करा. त्यानंतर panel मधील provider firewall तपासा आणि मग त्या मशीनवरील host firewall तपासा.
4. यापैकी कोणताही string नसल्यास: तुमच्याकडे आधीच TCP connection आहे. त्यामुळे हे network संबंधी प्रकरण न मानता authentication किंवा server load संबंधी प्रकरण म्हणून हाताळा.

FAQ

SSH चालू असताना "Connection refused" असे का दिसते?

कारण refusal socket कडून येतो, सेवेच्या स्थितीकडून नाही. sshd चालू असले तरी ते कनेक्शन नाकारू शकते. Provider console उघडा आणि sudo ss -tlnp चालवा. 127.0.0.1:22 वर असलेले socket प्रत्येक remote client चे कनेक्शन नाकारते, कारण ते फक्त loopback वर bind केलेले असते. socket दुसऱ्या port वर असल्यास 22 वापरणाऱ्या सर्व कनेक्शनना नकार मिळतो. systemd socket activation वापरात असल्यास port sshd_config मधून नव्हे, तर ssh.socket मधून घेतला जातो. त्यामुळे systemctl is-enabled ssh.socket देखील तपासा. ufw मधील reject rule देखील host च्या वतीने refusal परत करू शकतो. त्यामुळे कोणताही निष्कर्ष काढण्यापूर्वी sudo ufw status verbose वाचा.

ufw मध्ये port 22 ला परवानगी असतानाही SSH timeout का होते?

कारण timeout म्हणजे कोणतेही उत्तर परत आले नाही. मार्गातील एकमेव firewall ufw नसतो. बहुतेक VPS panels instance च्या पुढे network firewall चालवतात. त्या firewall ने टाकून दिलेले traffic operating system पर्यंत पोहोचत नाही. Console मधून sudo tcpdump -ni any tcp port 22 चालवा आणि ते चालू असताना laptop वरून कनेक्ट करण्याचा प्रयत्न करा. कोणतेही packets येत नसतील, तर drop upstream, म्हणजे panel मध्ये होत आहे. Packets येत असतील पण कोणतेही reply बाहेर जात नसेल, तर drop local आहे आणि तो ufw किंवा nftables मध्ये होत आहे.

ping अपयशी झाल्याचा अर्थ माझा VPS बंद आहे का?

नाही. अनेक providers network edge वर ICMP filter करतात. त्यामुळे traffic नेहमीप्रमाणे देणारा server तुम्ही पाठवलेले प्रत्येक ping दुर्लक्षित करू शकतो. याउलट, ping यशस्वी झाला तरी त्याचा पुरावा मर्यादित असतो, कारण port 22 उघडा आहे की नाही हे त्यातून कळत नाही. स्वतःच्या machine वरून nc -vz -w 5 203.0.113.10 22 वापरून port चीच चाचणी करा. Windows वर PowerShell मध्ये Test-NetConnection 203.0.113.10 -Port 22 वापरू शकता.

SSH port बदलला आणि आता कोणतेही कनेक्शन होत नाही. काय चुकले?

दोन क्रमदोषांमुळे हे घडू शकते. Firewall मध्ये नवीन port साठी rule जोडले नसेल, तर नवीन port वरील प्रयत्न timeout होतील आणि port 22 refusal देईल. त्यामुळे sudo ufw allow 2222/tcp हे port बदलण्यापूर्वी असणे आवश्यक आहे, नंतर नव्हे. Server SSH साठी systemd socket activation वापरत असल्यास sshd_config मधील Port 2222 दुर्लक्षित केले जाते. systemd जुना port वापरत राहते. याची पुष्टी systemctl is-enabled ssh.socket ने करता येते. Provider console द्वारे प्रवेश मिळवा. लागू असलेली समस्या दुरुस्त करा. sudo ss -tlnp मध्ये नवीन socket दिसल्यानंतर ssh -p 2222 user@203.0.113.10 वापरून कनेक्ट करा.