SSH Connection Refused vs Timed Out: வேறுபாடுகள் என்ன?

SSH-ல் "Connection refused" மற்றும் "Connection timed out" என்பதன் பொருள்

SSH connection refused மற்றும் SSH connection timed out ஆகிய இரண்டும் முற்றிலும் மாறுபட்ட தோல்விகள். எனவே, ஒன்றிற்கான தீர்வு மற்றொன்றிற்குப் பொருந்தாது. Refused என்பது, உங்கள் packet server-ஐ அடைந்துவிட்டது, ஆனால் அங்கு எந்தச் சேவையும் இயங்கவில்லை என்று server-ன் kernel பதிலளிக்கிறது என்று பொருள். Timed out என்பது, உங்கள் packet-க்கு பதிலளிக்க யாரும் இல்லை, எனவே உங்கள் client காத்திருந்து இறுதியில் முயற்சியைக் கைவிட்டது என்று பொருள். Refused என்பது server-ல் உள்ள ஒரு service தொடர்பான சிக்கல். Timed out என்பது server-க்கு முன்னால் உள்ள network பாதையில் உள்ள சிக்கல்.

உங்கள் client காட்டும் துல்லியமான வரியைப் படியுங்கள், ஏனெனில் அந்த வாசகமே முழுமையான நோயறிதலாகும்.

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 என்பது பல வினாடிகள் காத்திருந்த பிறகே திரையில் தோன்றும், ஏனெனில் client முயற்சியைக் கைவிடும் முன் மீண்டும் மீண்டும் packet-களை அனுப்ப முயற்சிக்கும். macOS இதே நிலையை Operation timed out என்று குறிப்பிடுகிறது. இந்த protocol உங்களுக்குப் புதியது என்றால், SSH எவ்வாறு செயல்படுகிறது மற்றும் sshd என்ன செய்கிறது என்பது இந்த வழிகாட்டி எதிர்பார்க்கும் அடிப்படை அறிவாகும்.

"Connection refused" ஏன் ஒரு நல்ல செய்தி

Refused என்பது ஒரு TCP (transmission control protocol) reset ஆகும். உங்கள் client, port 22-க்கு ஒரு SYN packet-ஐ அனுப்புகிறது. அது இணையத்தைக் கடந்து, server-ன் network stack-ஐ வந்தடைகிறது. அந்த port-ல் எந்த socket-ம் listening நிலையில் இல்லை என்பதை kernel கண்டறிகிறது. எனவே, அது ஒரு RST (reset) packet-ஐ பதிலாக அனுப்புகிறது. உங்கள் SSH client அந்த RST-ஐ Connection refused என்ற வார்த்தைகளாக மாற்றுகிறது.

திரும்பி வரும் அந்த ஒரு packet பல விஷயங்களை உறுதிப்படுத்துகிறது. முகவரி சரியானது. host இயங்கிக்கொண்டிருக்கிறது மற்றும் routing சரியாக உள்ளது. அந்த port-க்கு வரும் traffic-ஐ வழியில் உள்ள எதுவும் மௌனமாகத் தவிர்க்கவில்லை, ஏனெனில் தொலைதூர முனையிலிருந்து ஏதோ ஒன்று திரும்பி வந்துள்ளது. எனவே, மீதமுள்ள அனைத்து சந்தேகங்களும் server-க்குள்ளேயே உள்ளன.

• sshd இயங்கவில்லை, ஏனெனில் அது தொடங்கத் தவறியிருக்கலாம் அல்லது enable செய்யப்படாமல் இருக்கலாம்.
• sshd வேறொரு port-ல் listening நிலையில் உள்ளது, இது பெரும்பாலும் பாதுகாப்பு மாற்றங்களுக்குப் பிறகு நடக்கும்.
• sshd ஒரு குறிப்பிட்ட முகவரியுடன் மட்டும் பிணைக்கப்பட்டுள்ளது (உதாரணமாக ListenAddress 127.0.0.1), எனவே server-ஆல் மட்டுமே அதை அணுக முடியும்.
• ஒரு firewall, traffic-ஐ drop செய்வதற்குப் பதிலாக reject செய்ய அமைக்கப்பட்டுள்ளது. எனவே, firewall அந்த host-ன் சார்பாக RST-ஐ அனுப்புகிறது. ufw reject action மற்றும் reject with tcp reset-ல் முடியும் ஒரு nftables rule ஆகிய இரண்டுமே இதைச் செய்கின்றன.

இதேபோல் தோன்றும் மற்றொரு சூழல் உள்ளது, ஆனால் அது இதிலிருந்து மாறுபட்டது: நீங்கள் வேறொரு இயங்கும் host-ன் முகவரியைத் தட்டச்சு செய்திருக்கலாம். அந்த host உங்கள் SYN-க்கு பதிலளிக்கிறது, ஆனால் port 22-ல் SSH இல்லை, எனவே அது உங்களை மரியாதையுடன் மறுக்கிறது. தவறான server-ல் நேரத்தை வீணடிப்பதற்கு முன் முகவரியை உறுதிப்படுத்திக் கொள்ளுங்கள். Linux-ல் listening port என்றால் என்ன என்பதைத் தெரிந்துகொள்வது, இந்தப் பகுதியின் மீதமுள்ள தகவல்களை விரைவாகப் புரிந்துகொள்ள உதவும்.

Connection refused பிழையைச் சரிசெய்தல்

SSH சேவையே செயலிழந்திருப்பதால், அதை SSH வழியாகச் சரிசெய்ய முடியாது. உங்கள் provider-ன் web console அல்லது serial console-ஐத் திறந்து, உள்நுழைந்து, பின்வரும் கட்டளைகளைப் பயன்படுத்தவும்.

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

Ubuntu மற்றும் Debian-ல் unit பெயருக்கு systemctl status ssh பயன்படுத்தப்படுகிறது. RHEL மற்றும் அதன் வழித்தோன்றல்களான AlmaLinux போன்றவற்றில், unit பெயர் sshd ஆகும். ss -tlnp கட்டளையானது listening நிலையில் உள்ள அனைத்து TCP socket-களையும், அதைக் கையாளும் process-உடன் பட்டியலிடும். இதுவே உண்மையான நிலையைத் தெரிவிக்கும்: sshd பற்றி எந்த வரியும் இல்லை என்றால், config கோப்பில் என்ன இருந்தாலும், எந்தச் சேவையும் இயங்கவில்லை என்று அர்த்தம். sshd -T கட்டளையானது அனைத்து Include கோப்புகளும் இணைக்கப்பட்ட பிறகுள்ள இறுதி configuration-ஐக் காட்டும். /etc/ssh/sshd_config.d/ கோப்பில் கவனிக்கப்படாத port ஏதேனும் இருந்தால், அது இங்கே வெளிப்படும்.

Address நெடுவரிசையை கவனமாகப் பார்க்கவும். 0.0.0.0:22 என்பது server-ல் உள்ள அனைத்து IPv4 முகவரிகளையும் குறிக்கும். [::]:22 என்பது அனைத்து IPv6 முகவரிகளையும் குறிக்கும். 127.0.0.1:22 என்பது loopback-ஐ மட்டுமே குறிக்கும்; எனவே, உள்ளூர் ssh localhost இணைப்பு சரியாக வேலை செய்தாலும், தொலைதூர இணைப்புகள் அனைத்தும் நிராகரிக்கப்படும்.

எந்தச் சேவையும் listening நிலையில் இல்லை என்றால், service-ஐத் தொடங்கி, அது தொடங்கத் தவறினால் வரும் பிழைச் செய்தியைப் படிக்கவும்.

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

sshd -t கட்டளையானது, இயங்கும் service-ஐப் பாதிக்காமல், configuration-ஐப் பகுப்பாய்வு செய்து, தவறான directive உள்ள கோப்பு மற்றும் வரி எண்ணைக் காட்டும். ஒவ்வொரு முறை restart செய்வதற்கு முன்பும் இதை இயக்கவும். ஏனெனில், தவறான config இருந்தால் sshd தொடங்காது, அதன் விளைவாக உங்கள் அடுத்த இணைப்பு நிராகரிக்கப்படும்.

Ubuntu-வில் socket activation சிக்கல்

Ubuntu 24.04, OpenSSH-க்காக systemd socket unit-ஐ வழங்குகிறது. அந்த unit enabled நிலையில் இருந்தால், systemd அந்த listening port-ஐத் தன் கட்டுப்பாட்டில் வைத்துக்கொண்டு, ஒவ்வொரு இணைப்புக்கும் sshd-ஐத் தொடங்கும். எனவே, Port 2222-ல் செய்யப்படும் மாற்றங்கள் sshd_config-ல் எந்த மாற்றத்தையும் ஏற்படுத்தாது; server பழைய port-லேயே தொடர்ந்து பதிலளிக்கும். எதையும் திருத்துவதற்கு முன், உங்கள் server எந்த முறையில் இயங்குகிறது என்பதைச் சரிபார்க்கவும்.

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

socket enabled நிலையில் இருந்தால், sshd_config-க்கு பதிலாக socket unit-லேயே port-ஐ அமைக்கவும்.

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

ListenStream= வரியை காலியாக விடுவது அவசியம். ஏனெனில், systemd list அமைப்புகள் ஏற்கனவே உள்ள configuration-உடன் புதியவற்றைச் சேர்க்கும். இதைத் தவிர்த்தால், server இரண்டு port-களிலும் listen செய்யும். sudo systemctl daemon-reload மற்றும் sudo systemctl restart ssh.socket மூலம் மாற்றத்தைச் செயல்படுத்தவும். பின்னர், புதிய port-தான் பயன்பாட்டில் உள்ளதா என்பதை sudo ss -tlnp மூலம் உறுதிப்படுத்தவும். Port-ஐ மாற்றுவது VPS-ல் SSH-ஐப் பாதுகாக்கும் வழக்கமான ஒரு படிநிலையாகும்; இதுவே பயனர்கள் பெரும்பாலும் தங்களைத்தாமே வெளியேற்றிக்கொள்ளும் (lock out) இடமாகும்.

"Connection timed out" என்பது ஏன் எந்த பதிலும் கிடைக்கவில்லை என்பதைக் குறிக்கிறது

Timeout என்பது அமைதியைக் குறிக்கும். உங்கள் client ஒரு SYN-ஐ அனுப்பியது, அதை ஒரு நிமிடம் அல்லது இரண்டு நிமிடங்களுக்குள் பலமுறை மீண்டும் அனுப்பியது, ஆனால் ஒரு packet கூட பதிலுக்கு வரவில்லை. server-லிருந்து எந்த தகவலும் கிடைக்காததால், server-ன் நிலை குறித்து இங்கே எதையும் உறுதிப்படுத்த முடியாது.

ஒரு DROP விதி உருவாக்கும் விளைவுதான் இந்த அமைதி, மேலும் packet-களை நிராகரிப்பது (dropping) என்பது திட்டமிட்டே செய்யப்படுவது. ஒரு packet-ஐ நிராகரிக்கும்போது (reject), அது அந்த host இருப்பதை ஸ்கேன் செய்பவர்களுக்குத் தெரிவித்துவிடும். எனவே, ufw மற்றும் அனைத்து cloud provider-களின் network firewall-களும் தேவையற்ற packet-களை நிராகரித்து, எந்த பதிலும் அனுப்பாமல் இருக்கின்றன. நீங்கள் திறக்க விரும்பிய port-ல் firewall தனது பணியைச் சரியாகச் செய்வதாலேயே இந்த timeout ஏற்படுகிறது.

• முகவரி தவறானது: நீங்கள் மீண்டும் உருவாக்கிய server-ஐ இன்னும் சுட்டிக்காட்டும் DNS record, அல்லது யாரும் பயன்படுத்தாத முகவரிக்குச் செல்லும் எழுத்துப் பிழை.
• host இயங்கவில்லை: மின்சாரம் துண்டிக்கப்பட்டிருக்கலாம் அல்லது reboot ஆகிக்கொண்டிருக்கலாம். கட்டணம் செலுத்தாததால் provider சேவையை நிறுத்தியிருந்தாலும், வெளியிலிருந்து பார்க்கும்போது இது ஒரே மாதிரியாகவே தெரியும்.
• host firewall port 22-ஐ நிராகரிக்கிறது: பெரும்பாலும் எந்த allow விதியும் உருவாக்கப்படுவதற்கு முன்பே ufw enable இயக்கப்பட்டதே இதற்குக் காரணம்.
• instance-க்கு முன்னால் உள்ள provider firewall அதை நிராகரிக்கிறது: இதனால் operating system-க்கு அந்த packet சென்றடைவதே இல்லை.
• உங்கள் சொந்த network outbound port 22-ஐத் தடுக்கிறது: அலுவலகம் மற்றும் ஹோட்டல் இணைப்புகளில் இது பொதுவாக நடக்கும் ஒன்று.

இணைப்பின் வலது பக்கத்திலிருந்து சோதனையை இயக்கவும்

இதுவே அதிக நேரத்தை வீணடிக்கும் தவறாகும். பாக்கெட்டுகள் சென்றடையாத ஒரு பெட்டிக்குள் (box) இருந்து கொண்டு, அங்கு பாக்கெட் இழப்பு ஏற்படுவதைக் கண்டறிய முடியாது. அந்த பெட்டிக்குள் லாக்-இன் செய்து கட்டளையை இயக்க முடிந்தால், உங்களுக்கு அந்தப் பிரச்சினையே இருந்திருக்காது. இந்தப் பகுதியில் உள்ள ஒவ்வொரு கட்டளையும் உங்கள் சொந்த கணினியில் இயங்க வேண்டும்.

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 உங்கள் கணினி உண்மையில் பயன்படுத்தும் முகவரியைக் காட்டுகிறது; இது காலாவதியான DNS பதிவை நொடிகளில் கண்டறிய உதவும். ssh -G, ~/.ssh/config கோப்பை வாசித்த பிறகு உங்கள் client பயன்படுத்தும் அமைப்புகளை அச்சிடுகிறது; இது hostname, port அல்லது user-ஐ அமைதியாக மாற்றும் பழைய Host தொகுதியை (block) கண்டறிய உதவும். ssh -vvv முயற்சி எவ்வளவு தூரம் சென்றது என்பதைக் காட்டுகிறது: முகவரியுடன் இணைப்பது குறித்த கடைசி வரிக்குப்பின் நீண்ட இடைவெளி இருந்தால் அது timeout ஆகும்; அதேசமயம் remote OpenSSH பதிப்பைப் புகாரளிக்கும் வரி இருந்தால், TCP ஏற்கனவே வெற்றி பெற்றுவிட்டது என்றும், உங்கள் உண்மையான பிரச்சினை authentication என்றும் அர்த்தம். Windows-ல், nc-க்கு பதிலாக PowerShell-ல் Test-NetConnection 203.0.113.10 -Port 22-ஐப் பயன்படுத்தவும்.

Host-ஐ அல்ல, port-ஐச் சோதிக்கவும். தோல்வியடைந்த ping எதையும் நிரூபிக்காது, ஏனெனில் பல சேவை வழங்குநர்கள் (providers) விளிம்பில் (edge) ICMP (internet control message protocol)-ஐ வடிகட்டுகிறார்கள். வெற்றிகரமான ping-ம் எதையும் நிரூபிக்காது, ஏனெனில் அது port 22 பற்றி எதையும் கூறாது.

பிறகு, எந்தக் கட்டளையாலும் மாற்ற முடியாத ஒரே மாறியை (variable) மாற்றவும்: அது உங்கள் network. ஒரு phone hotspot மூலம் மீண்டும் முயற்சிக்கவும். Hotspot மூலம் இணைப்பு கிடைத்து, உங்கள் மேசை கணினியில் கிடைக்கவில்லை என்றால், தடையானது இணையத்தின் உங்கள் பக்கத்தில் உள்ளது அல்லது உங்கள் அலுவலக முகவரி server-ல் தடை செய்யப்பட்டுள்ளது என்று அர்த்தம்.

server-க்கு வெளியே உள்ள provider firewall

பெரும்பாலான VPS panels ஒரு network firewall-ஐ வழங்குகின்றன. இவை security group அல்லது cloud firewall என்று அழைக்கப்படுகின்றன. இவை உங்கள் instance-க்கு முன்பாக (upstream) இயங்கி, தனிப்பட்ட விதிமுறைகளைக் (rule list) கொண்டுள்ளன. server-ல் உள்ள ufw status-ஆல் இதைக் காண முடியாது. இதனால்தான் "நான் ஏற்கனவே port 22-ஐ அனுமதித்துவிட்டேனே" என்ற புகார்கள் அடிக்கடி எழுகின்றன. server-ல் எந்த விதியையும் மாற்றுவதற்கு முன்பாக, panel-ஐத் திறந்து அந்தப் பட்டியலைச் சரிபார்க்கவும்.

இந்தச் சிக்கலைத் தீர்க்க ஒரு கட்டளை உள்ளது, இதற்கு console access தேவை. server-ல் இந்தக் கட்டளையைத் தொடங்கிவிட்டு, உங்கள் laptop-லிருந்து connect செய்ய முயற்சிக்கவும்.

sudo tcpdump -ni any tcp port 22

உங்கள் client connect செய்ய முயற்சிக்கும்போது எவ்விதத் தகவலும் திரையில் தோன்றவில்லை என்றால், packets உங்கள் operating system-ஐ அடைவதற்கு முன்பே நிராகரிக்கப்படுகின்றன என்று அர்த்தம். எனவே, provider firewall அல்லது host-க்கான வழித்தடத்தில் (route) பிழை உள்ளது. ஒருவேளை SYN packets வந்து சேருகின்றன, ஆனால் பதில் செல்லவில்லை என்றால், அந்தத் தடுப்பு உள்ளூர் அளவில் (local) நடக்கிறது; இது ufw அல்லது nftables தொடர்பான சிக்கலாகும். இந்த ஒரே ஒரு சோதனை, timeout சிக்கலை இரண்டாகப் பிரித்துத் தெளிவுபடுத்துகிறது. இதற்காகவே console-க்குச் செல்வது பயனுள்ளது.

ufw வரிசைமுறை, IPv6, மற்றும் உங்களை நீங்களே தடை செய்தல்

ufw வரிசைமுறை பிழைதான் இங்கு மற்ற அனைத்தையும் விட அதிகமான பயனர்களை வெளியேற்றுகிறது. sudo ufw enable கட்டளையானது உள்வரும் இணைப்புகளை உடனடியாக மறுக்கும் (deny incoming) இயல்புநிலை கொள்கையை அமல்படுத்துகிறது. எனவே, SSH விதி (rule) இல்லாத நிலையில், உங்களின் தற்போதைய session தொடர்ந்து இயங்கினாலும், புதிய இணைப்புகள் அனைத்தும் காலாவதியாகிவிடும் (timeout). முதலில் அனுமதி வழங்கவும், அதன் பிறகு enable செய்யவும்.

sudo ufw allow OpenSSH
sudo ufw status verbose

OpenSSH application profile ஆனது port 22-ஐ மட்டுமே உள்ளடக்கியது. நீங்கள் SSH-ஐ port 2222-க்கு மாற்றத் திட்டமிட்டால், port மாற்றத்திற்கு முன்பே sudo ufw allow 2222/tcp விதியைச் சேர்க்க வேண்டும். விரிவான விதித் தொகுப்புகள் 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-ஐக் கண்காணித்து, மீண்டும் மீண்டும் தோல்வியடையும் முகவரிகளுக்கு எதிராக firewall விதியைச் சேர்க்கிறது. தவறான key அல்லது பின்னணியில் இயங்கும் script காரணமாக அலுவலகத்தின் IP முகவரி முழுவதுமே தடை செய்யப்படலாம். தடை செய்யப்பட்டால் இணைப்பு காலாவதியாவது போலத் தோன்றும். தடை செய்யப்பட்ட இணைப்பை நிராகரித்தால் (reject) No route to host பிழை கிடைக்கும். Console மூலம் சரிபார்க்க:

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

உங்கள் முகவரியை ignoreip-ல் சேர்ப்பது Ubuntu 24.04-ல் fail2ban-ஐ முறையாக அமைப்பது என்பதன் ஒரு பகுதியாகும்.

நிராகரிக்கப்படாத மற்றும் காலாவதியாகாத பிழைகள்

No route to host என்பது ICMP unreachable செய்தி திரும்பப் பெறப்பட்டதைக் குறிக்கிறது. உங்கள் கணினியில் அந்த network-க்கு செல்ல வழி இல்லை, அல்லது பாதையில் உள்ள ஏதேனும் ஒன்று நிர்வாக ரீதியாக நிராகரித்துள்ளது (இதுவே iptables REJECT விதி செய்யும் செயல்).

Network is unreachable என்பது உங்கள் கணினியே வழங்கும் பதில். அந்த address family-க்கு எந்த வழியும் இல்லை என்று அர்த்தம். IPv4-மட்டும் கொண்ட இணைப்பில், ஒரு hostname IPv6 முகவரிக்கு மட்டும் resolve ஆகும்போது இது வழக்கமாக நிகழும்.

kex_exchange_identification: Connection closed by remote host என்பது TCP இணைப்பு ஏற்பட்டு, key exchange முடிவதற்குள் server இணைப்பைத் துண்டித்துவிட்டது என்று பொருள். port திறந்திருக்கிறது மற்றும் sshd இயங்குகிறது, எனவே server load, MaxStartups, அல்லது நீங்கள் இணையும்போது அமல்படுத்தப்பட்ட ban ஆகியவற்றைச் சரிபார்க்கவும்.

Permission denied (publickey) என்பது நீங்கள் authentication நிலையை அடைந்து, அங்கு தோல்வியடைந்துள்ளீர்கள் என்று பொருள். network மற்றும் firewall சரியாக உள்ளன, எனவே இந்த வழிகாட்டியில் உள்ளவை இதற்குப் பொருந்தாது. அதற்குப் பதிலாக SSH-ல் Permission denied (publickey) பிழையைச் சரிசெய்தல் பகுதிக்குச் செல்லவும்.

மீண்டும் உள்நுழைவது எப்படி மற்றும் அடுத்தமுறை பூட்டப்படுவதைத் தவிர்ப்பது எப்படி

ஒவ்வொரு முறையான VPS host-ம் விருந்தினர் நெட்வொர்க்கைச் சாராத ஒரு console-ஐ வழங்குகிறது: இது serial console அல்லது browser அடிப்படையிலான VNC screen ஆக இருக்கலாம். sshd நிறுத்தப்பட்டிருந்தாலும் அல்லது firewall விதிமுறைகள் அனைத்து traffic-ஐயும் நிராகரித்தாலும் இந்த console தொடர்ந்து செயல்படும் என்பதால், இந்த வழிகாட்டியின் இரண்டு பிரிவுகளுக்கும் இதுவே மீட்பு வழியாகும். உங்கள் கட்டுப்பாட்டுப் பலகத்தில் (panel) இதைக் கண்டறிந்து, root பயனராகவோ அல்லது உங்கள் சாதாரண பயனராகவோ உள்நுழைந்து, மேலே உள்ள சோதனைகளைச் செய்யவும். நீங்கள் root password-ஐ அமைக்கவில்லை என்றால், பெரும்பாலான கட்டுப்பாட்டுப் பலகங்கள் அதை reset செய்ய உதவும்.

console வசதி இல்லாத சூழலில், அந்த நிறுவனத்தின் rescue mode-ஐப் பயன்படுத்தலாம். இது ஒரு சிறிய recovery system-ஐ boot செய்து உங்கள் disk-ஐ mount செய்யும். இதன் மூலம் நீங்கள் /etc/ssh/sshd_config-ஐத் திருத்தவோ அல்லது firewall விதியை நீக்கவோ முடியும், பின்னர் கணினியை reboot செய்யலாம்.

இரண்டு பழக்கங்கள் அடுத்தமுறை பூட்டப்படுவதைத் தடுக்கும். sshd அல்லது firewall-ஐத் திருத்தும்போது எப்போதும் இரண்டாவது SSH session-ஐத் திறந்து வைத்திருங்கள்; ஏனெனில் நீங்கள் புதிய session-ஐச் சோதிக்கும்போது, ஏற்கனவே உள்ள session தொடர்ந்து செயல்படும். மேலும், ஆபத்தான firewall மாற்றங்களைச் செய்வதற்கு முன் தானாகவே மாற்றங்களைச் செயல்தவிர்க்கும் (undo) வசதியை ஏற்படுத்திக்கொள்ளுங்கள்.

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

முதல் வரி, 10 நிமிடங்களில் ufw தானாகவே அணைக்கப்படும்படி திட்டமிடுகிறது. உங்கள் புதிய விதிகளை அமல்படுத்தி, புதிய SSH session மூலம் அவை சரியாகச் செயல்படுகின்றனவா என்பதை உறுதிப்படுத்திய பிறகு, இரண்டாவது வரியை இயக்கி இந்த rollback-ஐ ரத்து செய்யவும். ஒருவேளை நீங்கள் பூட்டப்பட்டால், 10 நிமிடங்கள் காத்திருங்கள்; firewall தானாகவே செயலிழந்துவிடும். நீங்கள் மீண்டும் ufw-ஐ இயக்கும் வரை server வடிகட்டப்படாமல் (unfiltered) இருக்கும், எனவே இதை நீங்கள் கணினிக்கு முன்னால் இருக்கும்போது மட்டும் பயன்படுத்தவும், நிரந்தரமான அமைப்பாக இதைப் பயன்படுத்த வேண்டாம்.

செயல்பட வேண்டிய வரிசைமுறை

1. பிழைச் செய்தியை வாசித்து, அது தோன்றுவதற்கு எவ்வளவு நேரம் ஆனது என்பதைக் கவனிக்கவும்.
2. Refused: console-க்குச் சென்று, listening socket, அதன் port மற்றும் அது இணைக்கப்பட்டுள்ள address ஆகியவற்றைச் சரிபார்க்க sudo ss -tlnp-ஐப் பயன்படுத்தவும்.
3. Timed out: உங்கள் கணினியிலிருந்து அந்த address-ஐ உறுதிப்படுத்தவும், பிறகு provider firewall-ஐ அதன் panel-ல் சரிபார்க்கவும், அதன்பின் host-ல் உள்ள firewall-ஐச் சரிபார்க்கவும்.
4. மேற்கூறிய இரண்டு செய்திகளும் இல்லை எனில்: உங்களிடம் ஏற்கனவே TCP இணைப்பு உள்ளது என்று பொருள். எனவே, இதை network சார்ந்த சிக்கலாகக் கருதாமல், authentication அல்லது server-load சார்ந்த சிக்கலாகக் கையாளவும்.

FAQ

sshd இயங்கிக்கொண்டிருக்கும்போது ஏன் SSH "Connection refused" என்று காட்டுகிறது?

ஏனெனில், இந்த மறுப்பு (refusal) சேவையிடமிருந்து (service) வருவதில்லை, மாறாக socket-இடமிருந்து வருகிறது. sshd இயங்கிக்கொண்டிருந்தாலும் உங்களை அது நிராகரிக்கக்கூடும். உங்கள் provider console-ஐத் திறந்து sudo ss -tlnp கட்டளையை இயக்கவும். 127.0.0.1:22-ல் உள்ள ஒரு socket, loopback-க்கு மட்டுமே பிணைக்கப்பட்டிருந்தால் (bound), அது அனைத்து remote client-களையும் நிராகரிக்கும். வேறொரு port-ல் உள்ள socket, இன்னும் 22-ஐப் பயன்படுத்தும் அனைவரையும் நிராகரிக்கும். systemd socket activation பயன்படுத்தப்பட்டால், port-ஆனது ssh.socket-லிருந்து வருகிறது, sshd_config-லிருந்து அல்ல; எனவே systemctl is-enabled ssh.socket-ஐயும் சரிபார்க்கவும். ufw reject விதியும் host-ன் சார்பாக ஒரு மறுப்பைத் தரும், எனவே எதையும் முடிவு செய்வதற்கு முன் sudo ufw status verbose-ஐப் படிக்கவும்.

ufw ஏற்கனவே port 22-ஐ அனுமதித்திருந்தும் ஏன் SSH time out ஆகிறது?

ஏனெனில், time out என்பது எந்த பதிலும் வரவில்லை என்று பொருள்; பாதையில் ufw மட்டுமே firewall அல்ல. பெரும்பாலான VPS panels, instance-க்கு முன்னால் ஒரு network firewall-ஐ இயக்குகின்றன. அந்த firewall எதைத் தடுக்கிறதோ, அதை operating system ஒருபோதும் பார்க்காது. Console-லிருந்து sudo tcpdump -ni any tcp port 22 கட்டளையை இயக்கவும்; அது இயங்கும்போது உங்கள் laptop-லிருந்து இணைக்க முயற்சிக்கவும். எந்த packet-ம் வரவில்லை என்றால், அந்தத் தடுப்பு upstream-ல், அதாவது panel-ல் உள்ளது என்று பொருள். packet-கள் வருகின்றன, ஆனால் பதில் செல்லவில்லை என்றால், அந்தத் தடுப்பு உள்ளூர் அளவில், ufw அல்லது nftables-ல் உள்ளது என்று பொருள்.

ping தோல்வியடைந்தால் என் VPS முடங்கிவிட்டதா?

இல்லை. பல providers network edge-ல் ICMP-ஐ வடிகட்டுகிறார்கள். எனவே, சாதாரணமாக traffic-ஐ வழங்கும் ஒரு server, நீங்கள் அனுப்பும் ஒவ்வொரு ping-ஐயும் புறக்கணிக்கக்கூடும். ஒரு வெற்றிகரமான ping-ம் அதே அளவு பலவீனமானது, ஏனெனில் அது port 22 திறந்திருக்கிறதா இல்லையா என்பதைப் பற்றி எதையும் கூறாது. உங்கள் கணினியிலிருந்து nc -vz -w 5 203.0.113.10 22 மூலமாகவோ அல்லது Windows-ல் PowerShell-ல் Test-NetConnection 203.0.113.10 -Port 22 மூலமாகவோ port-ஐ நேரடியாகச் சோதிக்கவும்.

நான் SSH port-ஐ மாற்றினேன், இப்போது எதுவும் இணைக்கப்படவில்லை. என்ன தவறு நடந்தது?

இரண்டு காரணங்களால் இது நிகழ்கிறது. புதிய port-க்கு firewall-ல் விதி (rule) சேர்க்கப்படவில்லை என்றால், புதிய port-க்கான முயற்சிகள் time out ஆகும், அதே சமயம் port 22 மறுப்பைத் தரும். எனவே, sudo ufw allow 2222/tcp கட்டளையை port மாற்றத்திற்குப் பிறகு அல்ல, அதற்கு முன்பே பயன்படுத்த வேண்டும். அந்த box SSH-க்கு systemd socket activation-ஐப் பயன்படுத்தினால், sshd_config-ல் உள்ள Port 2222 புறக்கணிக்கப்படும்; systemd பழைய port-ஐயே வைத்திருக்கும். இதை systemctl is-enabled ssh.socket மூலம் உறுதிப்படுத்தலாம். Provider console வழியாக மீட்டு (recover), இதில் எது பொருந்துகிறதோ அதைச் சரிசெய்யவும். பின்னர், sudo ss -tlnp புதிய socket-ஐக் காட்டிய பிறகு, ssh -p 2222 user@203.0.113.10 மூலம் இணைக்கவும்.