VPS-ல் SSH பாதுகாப்பை பலப்படுத்துவது எப்படி?

SSH-ஐ ஏன் முதலில் பலப்படுத்த வேண்டும்

உங்கள் server-ஐக் கட்டுப்படுத்தும் கருவி SSH என்பதால், ஒவ்வொரு தாக்குதல் நடத்துபவரும் முதலில் உடைக்க முயலும் பூட்டு இதுவே. ஒரு VPS இணையத்தில் இணைக்கப்பட்ட அடுத்த நொடியே, port 22-ல் பயனர்பெயர் மற்றும் கடவுச்சொற்களை ஊகிக்கும் ஸ்கேனர்கள் (scanners) செயல்படத் தொடங்கிவிடும். சில நிமிடங்களிலேயே உங்கள் logs-ல் இது நடப்பதைக் கவனிக்க முடியும். SSH-ஐப் பலப்படுத்துவது என்பது அவர்கள் ஊகிக்கக்கூடிய வழிகளை நீக்குவதாகும்: கடவுச்சொல் மூலம் உள்நுழைவதை (password login) முழுமையாக முடக்கவும், root உள்நுழைவை முடக்கவும், cryptographic keys-ஐ மட்டும் அனுமதிக்கவும். இதைச் செய்தவுடன், கடவுச்சொல் என்று எதுவும் இல்லாததால், தொடர்ச்சியான ஊகங்கள் வெற்றிபெற வாய்ப்பில்லை.

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

படி 1: Key authentication முதலில் வேலை செய்கிறதா என்பதை உறுதிப்படுத்தவும்

Key authentication என்பது கடவுச்சொல்லுக்குப் பதிலாக key pair-ஐப் பயன்படுத்துகிறது: உங்கள் கணினியில் இருக்கும் private key மற்றும் server-ல் நீங்கள் பதிவேற்றும் public key. உங்கள் கணினியை விட்டு private key வெளியேறாமலேயே, உங்களிடம் அது இருப்பதை server உறுதிப்படுத்தும். கடவுச்சொற்களை முடக்கும் முன், key சரியாக வேலை செய்கிறதா என்று சரிபார்க்கவும்; இல்லையெனில், நீங்கள் server-க்குள் நுழைய முடியாமல் பூட்டப்படுவீர்கள்.

உங்கள் கணினியில், உங்களிடம் key இல்லையென்றால், ஒன்றை உருவாக்கவும்:

ssh-keygen -t ed25519

Public key-ஐ server-க்கு நகலெடுக்கவும்:

ssh-copy-id user@your-server

பிறகு, புதிய SSH session-ஐத் தொடங்கவும். கடவுச்சொல் கேட்காமல் உங்களை உள்ளே அனுமதித்தால், உங்கள் key சரியாக வேலை செய்கிறது என்று அர்த்தம்; இப்போது நீங்கள் கடவுச்சொற்களைப் பாதுகாப்பாக முடக்கலாம். ஒருவேளை Permission denied (publickey) பிழை ஏற்பட்டால், அந்த ஒரு பிழை ஐந்து வெவ்வேறு கோளாறுகளை மறைக்கும், மேலும் எதையும் மாற்றுவதற்கு முன் ssh -v வெளியீடு உங்களுக்கு எந்தப் பிரச்சினை என்பதைத் தெரிவிக்கும். உங்களுக்கு key-கள் புதியவை என்றாலோ அல்லது ஒன்றுக்கும் மேற்பட்ட கணினிகளைப் பயன்படுத்தினாலோ, SSH key மேலாண்மை அடிப்படைகள் முழுமையான முறையை விளக்குகிறது: ஒரு சாதனத்திற்கு ஒரு key, sshd கோரும் அனுமதிகள், மற்றும் ஒரு laptop தொலைந்துவிட்டால் key-ஐ எவ்வாறு ரத்து செய்வது போன்றவை இதில் அடங்கும்.

படி 2: drop-in கோப்பைப் பயன்படுத்தி sshd-ஐ வலுப்படுத்துதல்

/etc/ssh/sshd_config கோப்பை நேரடியாகத் திருத்த வேண்டாம். Ubuntu 24.04, /etc/ssh/sshd_config.d/ கோப்பகத்திலிருந்து drop-in கோப்புகளை வாசிக்கிறது. சிறிய கோப்புகளைப் பயன்படுத்துவது சுத்தமான முறையாகும்; இது package மேம்படுத்தல்களின் போது அழியாது, ஏதேனும் சிக்கல் ஏற்பட்டால் எளிதாக நீக்கலாம். கோப்பின் பெயர் முக்கியமானது: ஒவ்வொரு அமைப்பிற்கும் முதலில் வாசிக்கும் மதிப்பையே sshd எடுத்துக்கொள்ளும். Ubuntu cloud images, 50-cloud-init.conf கோப்பை PasswordAuthentication yes உடன் இந்த கோப்பகத்தில் வழங்குகின்றன. உங்கள் கோப்பிற்கு 00- என்று பெயரிடுங்கள், அப்போதுதான் அது மற்ற கோப்புகளுக்கு முன்பாக வரிசைப்படுத்தப்பட்டு முன்னுரிமை பெறும்; 99- கோப்பு எந்த அறிவிப்பும் இன்றி புறக்கணிக்கப்படும். ஒரு கோப்பை உருவாக்கவும்:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

அதில் பின்வருவனவற்றைச் சேர்க்கவும்:

# Key-only login: no passwords to guess.
PasswordAuthentication no
KbdInteractiveAuthentication no

# No direct root login. Log in as your user, then use sudo.
PermitRootLogin no

ஒவ்வொரு வரியும் ஒரு பாதுகாப்புக் கதவை மூடுகிறது. PasswordAuthentication no மிக முக்கியமானது: கடவுச்சொற்கள் முடக்கப்பட்டால், brute-force தாக்குதலுக்கு எந்த வழியும் இருக்காது. KbdInteractiveAuthentication no கடவுச்சொல் சார்ந்த மற்றொரு நுழைவுப் பாதையை மூடுகிறது. PermitRootLogin no அமைப்பினால், தாக்குதல் நடத்துபவர் உங்கள் பயனர் பெயரைத் தெரிந்து வைத்திருப்பதுடன், உங்கள் cryptographic key-யையும் வைத்திருக்க வேண்டும். அனைத்து கணினிகளிலும் பொதுவான root கணக்கை மட்டும் குறிவைத்து தாக்குவது இதன் மூலம் தடுக்கப்படுகிறது.

படி 3: அமைப்பைச் சரிபார்த்து, reload செய்யவும்

மாற்றங்களைச் செயல்படுத்தும் முன், தட்டச்சுப் பிழைகள் சேவையை முடக்காமல் இருக்க, அமைப்பைச் சரிபார்க்கவும்:

sudo sshd -t

எந்த வெளியீடும் வரவில்லை என்றால், அமைப்பு சரியாக உள்ளது என்று அர்த்தம். SSH-ஐ reload செய்யவும்:

sudo systemctl reload ssh

பின்பு, sshd உண்மையில் பயன்படுத்தும் அமைப்புகளைச் சரிபார்க்கவும்; அப்போதுதான் மற்றொரு கோப்பினால் உங்கள் மாற்றம் புறக்கணிக்கப்பட்டதா என்பதை அறிய முடியும்:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

இரண்டுமே no என்று காட்ட வேண்டும். இப்போது, உங்கள் தற்போதைய session-ஐ மூடாமல், மற்றொரு terminal-லிருந்து புதிய session-ஐத் தொடங்கவும். அது உங்கள் key மூலம் உங்களை உள்ளே அனுமதித்தால், பணி முடிந்தது. ஏதேனும் தவறு இருந்தால், அதைச் சரிசெய்ய உங்கள் முதல் session திறந்திருக்கும். இந்த overlap ஒரு பாதுகாப்பு வளையம், எனவே இதை ஒருபோதும் தவிர்க்க வேண்டாம்.

படி 4: விருப்பத்தேர்வாக அமையும் non-standard port

SSH-ஐ port 22-லிருந்து 2222 போன்ற வேறு port-க்கு மாற்றுவது, நடைமுறையில் பாதுகாப்பை அதிகரிக்காது. ஏனெனில், தீவிரமான தாக்குதல் நடத்துபவர்கள் அனைத்து port-களையும் scan செய்வார்கள். இது log-ல் தேவையற்ற பதிவுகளைக் குறைக்கும், ஏனெனில் பெரும்பாலான தானியங்கி scanners port 22-ஐ மட்டுமே சோதிக்கும். நீங்கள் இதைச் செய்ய விரும்பினால், உங்கள் drop-in கோப்பில் Port 2222-ஐச் சேர்க்கவும். முதலில் firewall-ல் புதிய port-ஐ அனுமதிக்கவும், பின் sudo systemctl daemon-reload && sudo systemctl restart ssh.socket-ஐ இயக்கவும், இறுதியாக ssh -p 2222 மூலம் இணைக்கவும். Ubuntu 24.04-ல், ssh.socket தான் listening port-ஐக் கட்டுப்படுத்துகிறது. எனவே, சாதாரண reload ssh கட்டளையை மட்டும் இயக்கினால் sshd port 22-லேயே இருக்கும்; socket-ஐ restart செய்தால் மட்டுமே புதிய port செயல்பாட்டுக்கு வரும். இதை ஒரு பாதுகாப்பு நடவடிக்கையாகக் கருதாமல், நிர்வாக ஒழுங்காகக் கருதவும்.

படி 5: கூடுதல் பாதுகாப்பு அடுக்குகளை அமைத்தல்

Hardened SSH keys அடிப்படை பாதுகாப்பாகும், இதற்கு மேல் மேலும் இரண்டு பாதுகாப்பு அடுக்குகளைச் சேர்க்கலாம்.

Fail2ban உங்கள் logs-ஐத் தொடர்ந்து கண்காணித்து, மீண்டும் மீண்டும் தோல்வியடையும் IP addresses-ஐத் தடை செய்கிறது. இது scanner-களின் தேவையற்ற இடையூறுகளைக் குறைத்து, அவற்றை ஆரம்பத்திலேயே வெளியேற்றுகிறது. இது key-only authentication-உடன் இணைந்து சிறப்பாகச் செயல்படுகிறது: SSH தாக்குதல்களைத் தடுக்க Ubuntu-வில் Fail2ban-ஐ அமைத்தல் என்பதைப் பார்க்கவும்.

SSH-ஐ பொது இணையத்திலிருந்து (public internet) முழுமையாக மறைப்பது இன்னும் வலிமையான பாதுகாப்பாகும். நீங்கள் SSH-ஐ WireGuard VPN-க்கு பின்னால் வைத்தால் மற்றும் port 22-ஐ firewall மூலம் tunnel-க்கு மட்டும் கட்டுப்படுத்தினால், VPN-க்கு வெளியே உள்ள எவராலும் அதை அணுக முடியாது. இதனால் brute-force தாக்குதல்கள் கடினமானது மட்டுமல்ல, சாத்தியமற்றதுமாகிவிடும். இவை அனைத்திற்கும் அடிப்படையாக default-deny firewall தேவை, இது VPS-ல் UFW அமைப்பதன் மூலம் செய்யப்படுகிறது.

SSH என்பது ஒரு பெரிய சரிபார்ப்புப் பட்டியலின் (checklist) ஒரு வரி மட்டுமே: புதிய VPS-ல் முதல் 10 நிமிடங்கள் என்ற கட்டுரை இந்த படிகளை வரிசைப்படுத்துகிறது, மேலும் Ubuntu-வில் தானியங்கி பாதுகாப்பு மேம்படுத்தல்கள் மூலம் server-ஐத் தொடர்ந்து பாதுகாப்பாக வைத்திருக்க முடியும். கதவைப் பூட்டுவது மட்டும் போதாது, அதற்குப் பின்னால் இயங்கும் சேவைகளையும் பாதுகாக்க வேண்டும். எனவே, அதே VPS-ல் password vault இயங்கினால், Vaultwarden-ஐப் பாதுகாத்தல் என்ற கட்டுரை, key authentication-ஆல் பாதுகாக்க முடியாத அதன் admin token மற்றும் backup file ஆகியவற்றை எவ்வாறு பாதுகாப்பது என்பதை விளக்குகிறது.

FAQ

Ubuntu 24.04-ல் SSH-க்கான கடவுச்சொல் நுழைவை (password login) எவ்வாறு முடக்குவது?

/etc/ssh/sshd_config.d/00-hardening.conf-ல் ஒரு drop-in கோப்பை உருவாக்கவும் (00 முன்னொட்டு, 50-cloud-init.conf-க்கு முன்பாகவே இது வரிசைப்படுத்தப்படுவதை உறுதி செய்கிறது; ஏனெனில் sshd முதலில் வாசிக்கும் மதிப்பையே எடுத்துக்கொள்ளும், அதன் PasswordAuthentication yes மற்றொன்றை விட முன்னுரிமை பெறும்). அதில் PasswordAuthentication no மற்றும் KbdInteractiveAuthentication no ஆகியவற்றைச் சேர்க்கவும். அமைப்பைச் சரிபார்க்க sudo sshd -t-ஐ இயக்கவும், பிறகு sudo systemctl reload ssh-ஐ இயக்கவும். புதிய session-ல் key மூலம் நுழைவது வேலை செய்கிறதா என்பதை உறுதிப்படுத்திய பின், அதை முழுமையாக நம்பவும். sshd_config-ஐ நேரடியாகத் திருத்துவதை விட, drop-in கோப்பைத் திருத்துவது package மேம்படுத்தல்களின் போது பாதுகாப்பாக இருக்கும் மற்றும் எளிதில் மாற்றங்களை நீக்க உதவும்.

SSH வழியாக root நுழைவை முடக்க வேண்டுமா?

ஆம். PermitRootLogin no என அமைக்கவும், இதன் மூலம் யாரும் நேரடியாக root-ஆக நுழைய முடியாது. உங்கள் சாதாரண பயனர் கணக்கில் நுழைந்து, நிர்வாகப் பணிகளுக்கு sudo-ஐப் பயன்படுத்தவும். ஒவ்வொரு Linux கணினியிலும் root கணக்கு இருக்கும் என்பதால், அதை அணுக அனுமதிப்பது தாக்குதல் நடத்துபவர்களுக்குத் தெரிந்த ஒரு பயனர் பெயரை இலக்காகக் கொடுக்கிறது. அதை முடக்குவதன் மூலம், அவர்கள் உங்கள் பயனர் பெயரையும், உங்கள் key-யையும் வைத்திருக்க வேண்டிய கட்டாயம் ஏற்படும்.

SSH port-ஐ மாற்றுவது எனது server-ஐ அதிகப் பாதுகாப்பானதாக்குமா?

குறிப்பிடத்தக்க வகையில் இல்லை. 22-வது port-லிருந்து மாறுவது, 22-ஐ மட்டும் சோதிக்கும் சோம்பேறித்தனமான ஸ்கேனர்களிடமிருந்து உங்களை மறைக்கும், இது log-ல் தேவையற்ற இரைச்சலைக் குறைக்கும். ஆனால், உண்மையான தாக்குதல் நடத்துபவர் அனைத்து port-களையும் ஸ்கேன் செய்து அதைக் கண்டுபிடித்துவிடுவார். Key-only authentication மட்டுமே ஊடுருவலைத் தடுக்கும். நீங்கள் port-ஐ மாற்றினால், முதலில் firewall-ல் புதிய port-ஐத் திறக்கவும், பிறகு sudo systemctl daemon-reload && sudo systemctl restart ssh.socket-ஐ இயக்கவும்; Ubuntu 24.04-ல் socket தான் listener-ஐக் கட்டுப்படுத்துகிறது, எனவே சாதாரண reload செய்தால் sshd 22-வது port-லேயே இருக்கும்.

நான் SSH keys பயன்படுத்தினால் Fail2ban தேவையா?

இது விருப்பத்தேர்வுதான், ஆனால் பயனுள்ளது. Key-only authentication பயன்படுத்தும்போது, கடவுச்சொல்லை ஊகித்து நுழைய முடியாது, எனவே Fail2ban தாக்குதல் நடத்துபவர்களைத் தடுப்பதில்லை. இது ஒரே முகவரியிலிருந்து வரும் தொடர் தோல்விகளைக் கட்டுப்படுத்துகிறது, இது log-ல் உள்ள ஸ்கேனர் இரைச்சலைக் குறைத்து, மீண்டும் மீண்டும் தொந்தரவு செய்பவர்களை முன்கூட்டியே வெளியேற்றுகிறது; மெதுவான, பரவலான தாக்குதல்கள் அதன் ban வரம்பிற்குள் வராமல் அப்படியே தொடரும். Key auth-க்கு மேல் இதை இயக்கவும், முடிந்தால் SSH-ஐ ஒரு VPN-க்கு பின்னால் வைக்கவும்.

SSH-ல் இருந்து வெளியேற்றப்பட்டால் (lockout) எவ்வாறு மீட்பது?

உங்கள் சேவை வழங்குநரின் (provider) web console-ஐப் பயன்படுத்தவும். இது SSH வழியாகச் செல்லாத serial அல்லது VNC இணைப்பு மூலம் server-ஐ அணுகும். அங்கிருந்து நீங்கள் நுழைந்து, sshd drop-in கோப்பைச் சரிசெய்து, சேவையை reload செய்யலாம். இதற்காகத்தான் உங்கள் முதல் session-ஐ மூடுவதற்கு முன், புதிய SSH அமைப்பை இரண்டாவது terminal-ல் சோதிக்க வேண்டும்; மேலும் கடவுச்சொல் நுழைவை முடக்கும் முன்பே key authentication சரியாக வேலை செய்கிறதா என்பதை உறுதிப்படுத்த வேண்டும்.