OpenSSH அவசரத் தீர்வு: Alpine Linux லாகின் பைபாஸ் விளக்கம், ஒரு செய்முறை உதாரணத்துடன்

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

இன்று 2026 நவம்பர் 6, மேலும் இது இப்போது மிகவும் முக்கியமானது, ஏனெனில் Portable OpenSSH 10.6p2 நேற்றுதான் (நவம்பர் 5 அன்று) இத்திட்டத்தின் அவசரக் கோரிக்கையுடன் வெளியானது. கடவுச்சொல் அங்கீகரிப்பு இயக்கப்பட்ட musl-அடிப்படையிலான Linux சர்வர்களை நீங்கள் இயக்குகிறீர்கள் என்றால், நீங்கள் நடவடிக்கை எடுக்கும் வரை கடவுச்சொல் உள்நுழைவுகளை அல்லது SSH-ஐ உடனடியாக முடக்குமாறு டெவலப்பர்கள் விரும்புகிறார்கள்.

பல குழுக்கள் அந்தத் தலைப்பைப் படித்துவிட்டு பீதியடையலாம் அல்லது அலட்சியப்படுத்தலாம். இரண்டுமே தவறுகள். பெரும்பாலான Linux சர்வர்கள் பாதிக்கப்படவில்லை, ஆனால் பாதிக்கப்படும் சர்வர்களில் நீங்கள் எப்போதும் "key-only" என்று அழைக்கும் சர்வர்களும் அடங்கும். இந்த வழிகாட்டி பிழையை எளிய மொழியில் விளக்குகிறது, ஒரு சர்வரை எவ்வாறு சரிபார்ப்பது என்பதைத் துல்லியமாகக் காட்டுகிறது, மற்றும் கண்டறிதல் முதல் சரிபார்க்கப்பட்ட தீர்வு வரையிலான முழுமையான உதாரணத்தை விளக்குகிறது.

என்ன நடந்தது, எளிய வார்த்தைகளில்

SSH என்பது தொலைவிலிருந்து சர்வர்களில் உள்நுழைய நிர்வாகிகள் பயன்படுத்தும் கருவியாகும். OpenSSH என்பது அதன் மிகவும் பரவலாகப் பயன்படுத்தப்படும் பதிப்பாகும்.

ஒவ்வொரு Linux நிரலும் அடிப்படை செயல்பாடுகளின் பகிரப்பட்ட தொகுப்பான C லைப்ரரியை நம்பியுள்ளது. பெரும்பாலான Linux அமைப்புகள் glibc எனப்படும் ஒன்றைப் பயன்படுத்துகின்றன. Alpine Linux ஆனது musl எனப்படும் சிறிய ஒன்றைப் பயன்படுத்துகிறது, இதுவே கொள்கலன்கள் (containers) மற்றும் சிறிய கிளவுட் சர்வர்களுக்கு Alpine மிகவும் பிரபலமாக இருப்பதற்கான முக்கிய காரணமாகும்.

அந்த இரண்டு மென்பொருள்களுக்கு இடையேயான சந்திப்புப் புள்ளியில் இந்த பிழை உள்ளது. OpenSSH-இன் டெவலப்பர்கள் இதன் அடிப்படைக் காரணம் OpenSSH-க்கு வெளியே இருப்பதாகக் கருதுகின்றனர், ஆனால் SSH சர்வர்தான் இதைத் தவறாகப் பயன்படுத்துவதற்கான வழியை வழங்குகிறது என்பதையும், அதைத் தடுப்பதற்கான நடைமுறை இடமாக உள்ளது என்பதையும் அவர்கள் ஒப்புக்கொள்கிறார்கள். எனவே 10.6p2 ஒரு தீர்வை (workaround) சேர்க்கிறது. இந்த குறைபாட்டை வேக்ஃபீல்டின் Özgün Kültekin கண்டறிந்தார்.

ஒரு பிழை எவ்வாறு வெற்றிகரமான உள்நுழைவாக மாறுகிறது

எக்ஸ்ப்ளாயிட் விவரங்கள் எதுவும் இல்லாமல், படிப்படியான தர்க்கம் இதோ.

ஒரு சர்வர் PAM (உள்நுழைவுகளைக் கையாளும் பொதுவான அமைப்பான Pluggable Authentication Modules) இல்லாமல் கடவுச்சொல்லைச் சரிபார்க்கும்போது, அது ஒரு எளிய செயலைச் செய்கிறது. பயனர் தட்டச்சு செய்த கடவுச்சொல்லை ஹாஷ் செய்து, பின்னர் அந்த முடிவை அந்தக் கணக்கிற்காக சேமிக்கப்பட்ட மதிப்புடன் ஒப்பிடுகிறது.

ஒரு ஹாஷிற்கு சால்ட் (salt) தேவைப்படுகிறது, இது ஒரே மாதிரியான கடவுச்சொற்கள் வெவ்வேறு முடிவுகளை உருவாக்கும் வகையில் கலக்கப்படும் ஒரு சிறிய ரேண்டம் மதிப்பாகும். ஒரு கணக்கிற்காக சேமிக்கப்பட்ட மதிப்பு சால்ட்டை வழங்குவதற்கு மிகவும் குறைவாக இருந்தால், OpenSSH அதே கணினியில் உள்ள மற்றொரு கணக்கிலிருந்து ஒன்றைக் கடன் வாங்கலாம். இது ஒரு நல்ல காரணத்திற்காகவே செய்யப்படுகிறது: 2016 முதல், தாக்குபவர்கள் எந்த பயனர் பெயர்கள் உள்ளன என்று யூகிப்பதைத் தடுக்க இது முயற்சித்து வருகிறது, இது CVE-2016-6210 குறைபாட்டிற்கான பதிலாகும்.

இப்போது மோதல் ஏற்படுகிறது. musl-இன் crypt() சார்புக்கு குறிப்பிட்ட ஹாஷ் வகைகளுக்கு மிகவும் நீளமான கடவுச்சொல் வழங்கப்படும்போது, அது மறுத்துவிட்டு ஒற்றை எழுத்தான * -ஐ ஒரு பிழையைக் குறிக்கத் திருப்பி அனுப்புகிறது.

ஆனால் * என்பது கடவுச்சொல் கொண்டிருக்கக் கூடாத ஒரு கணக்கின் கடவுச்சொல் புலத்தில் பல அமைப்புகள் சேமிக்கும் ஒன்றாகவே இருக்கிறது.

எனவே சர்வர் இரண்டு மதிப்புகளை ஒப்பிடுகிறது:

• அது கணக்கிட்டது: *, இதன் உண்மையான அர்த்தம் "பிழை" என்பதாகும்.
• அது சேமித்து வைத்திருப்பது: *, இதன் உண்மையான அர்த்தம் "பயன்படுத்தக்கூடிய கடவுச்சொல் இல்லை" என்பதாகும்.

அவை பொருந்துகின்றன. உள்நுழைவு வெற்றிகரமாகிறது.

ஒரு பாதுகாவலர் ஒரு பட்டியலுடன் பெயர்களைச் சரிபார்ப்பதை நினைத்துப் பாருங்கள். ஸ்கேனர் பழுதடைந்து "ERROR" என அச்சிடுகிறது. ஊழியர்களுக்கான குறிப்பாக சேர்க்கப்பட்ட பட்டியலில் உள்ள ஒரு பதிவும் "ERROR" என்று கூறுகிறது. பாதுகாவலர் இரண்டு ஒரே மாதிரியான வார்த்தைகளைக் கண்டு அந்த நபரை உள்ளே அனுமதிக்கிறார். யாரும் பொய் சொல்லவில்லை, ஒவ்வொரு பகுதியும் தனது வேலையைச் செய்தது. ஒரு மதிப்பு இரண்டு வெவ்வேறு விஷயங்களைக் குறிப்பதில் இருந்தே ஆபத்து வந்தது.

ஆராய்ச்சியாளர் இந்த தொடர்பை 2012-இல் musl-இல் செய்யப்பட்ட மாற்றங்கள் மற்றும் 2016-இல் செய்யப்பட்ட OpenSSH மாற்றம் வரை பின்தொடர்கிறார். AI முகவர்களின் உதவியுடன், பில்ட் மற்றும் லாகின் சேர்க்கைகளில் சுமார் 17,600 சோதனை உள்நுழைவுகள் மூலம் இதைக் கண்டறிந்ததாக அவர் தெரிவிக்கிறார்.

நீங்கள் பாதிக்கப்பட்டுள்ளீர்களா? நான்கு நிபந்தனைகள்

Alpine ஆலோசனை அறிக்கை நான்கு நிபந்தனைகளைப் பட்டியலிடுகிறது, அவை அனைத்துமே முக்கியமானவை:

1. OpenSSH ஆனது PAM இல்லாமல் கடவுச்சொற்களைச் சரிபார்க்கிறது.
2. PasswordAuthentication இயக்கப்பட்டிருப்பது.
3. இலக்கு கணக்கின் கடவுச்சொல் புலத்தில் இருப்பது *.
4. மற்றொரு உள்ளூர் கணக்கில் உள்ள கடவுச்சொல் ஹாஷ் தொடங்குவது $5$ அல்லது $6$.

Alpine-இன் நிலையான openssh-server தொகுப்பு PAM-ஐப் பயன்படுத்துவதில்லை. நிறுவுதல் openssh-server-pam கூட இதைத் தீர்த்துவிடாது, ஏனெனில் UsePAM no அமைக்கப்பட்டிருந்தால் நீங்கள் இன்னும் பாதிப்பிற்கு ஆளாகியிருப்பீர்கள்.

இவை குறிப்பிடப்பட்ட வரம்பிற்கு அப்பாற்பட்டவை:

• Linux அல்லாத இயங்குதளங்கள்.
• glibc-ஐப் பயன்படுத்தும் Linux அமைப்புகள்.
• PAM மூலம் கடவுச்சொற்களைச் சரிபார்க்கும் Linux அமைப்புகள்.
• இயங்கும் SSH சர்வர் இல்லாத கொள்கலன்கள் (containers).
• கடவுச்சொல் அங்கீகரிப்பு முடக்கப்பட்ட அமைப்புகள்.
• கணக்குகள் இதைக் கொண்டு பூட்டப்பட்டிருப்பது: ! என்பதற்கு பதிலாக *.

அந்த கடைசி குழுவே, "நாங்கள் Alpine-ஐப் பயன்படுத்துகிறோம்" என்பது "நாங்கள் பாதிக்கப்படக்கூடிய நிலையில் இருக்கிறோம்" என்பதற்கு சமமானது அல்ல என்பதற்கான காரணமாகும். பெரும்பாலான Alpine கொள்கலன்கள் எந்த ஒரு SSH சர்வரையும் இயக்குவதில்லை. அதேபோல், "OpenSSH நிறுவப்பட்டுள்ளது" என்பது உங்களுக்கு மிகக் குறைவான தகவலையே தருகிறது. நீங்கள் C லைப்ரரி, தொகுப்பு, இயங்கும் கட்டமைப்பு மற்றும் கணக்குத் தரவு ஆகியவற்றை அறிந்து கொள்ள வேண்டும்.

ஆபத்தான நிலைமை: அதிகாரப்பூர்வ கிளவுட் இமேஜ்கள்

Alpine குறிப்பாக ஒரு சூழலைக் குறிப்பிடுகிறது. அதன் அதிகாரப்பூர்வ tiny-cloud இமேஜ்கள், பதிப்புகள் 3.18.11 முதல் 3.24.3 வரை, இதில் உள்ள alpine கணக்கு ஒரு * கடவுச்சொல் புலம் மற்றும் கடவுச்சொல் இல்லாத doas உரிமைகளைக் கொண்டுள்ளது. doas என்பது ஒரு சிறிய கருவி, இது போன்றது: sudo, இது ஒரு பயனரை root ஆக கட்டளைகளை இயக்க அனுமதிக்கிறது.

அந்த இமேஜ்கள் தொடக்கத்தில் பாதுகாப்பானவையாகவே இருக்கின்றன, ஏனெனில் நான்காவது நிபந்தனை அங்கு இல்லை. அந்த கணினியில் தகுதியான கடவுச்சொல் ஹாஷ் எதுவும் இல்லை.

பின்னர் யாராவது கன்சோல் அணுகலுக்காக ஒரு சாதாரண கடவுச்சொல்லுடன் ஒரு பயனரைச் சேர்க்கலாம். அந்த ஒரு வழக்கமான மாற்றம் அனைத்து நிபந்தனைகளையும் பூர்த்தி செய்துவிடும். ஒரு தாக்குபவர் alpine ஆக நுழைந்து root ஆக மாற முடியும்.

இயல்புநிலை PermitRootLogin prohibit-password அமைப்பு இங்கு உதவாது. இது root-க்கு நேரடி கடவுச்சொல் உள்நுழைவுகளைத் தடுக்கிறது, ஆனால் இந்த வழி மறைமுகமாக root-ஐ அடைகிறது.

ஒரு செய்முறை உதாரணம்: Acme-இன் ஜம்ப் ஹோஸ்ட்

ஒரு கற்பனையான நிறுவனத்தை நாம் பார்ப்போம். Acme ஒரு சிறிய Alpine சர்வரை இயக்குகிறது, bastion.example.com, உள் அமைப்புகளை அணுக ஊழியர்கள் இதன் வழியாக இணைகிறார்கள். அனைவரும் இது key-only என்று கூறுகிறார்கள். அதை நிரூபிக்குமாறு Rohit என்ற புதிய பொறியாளரிடம் கேட்கப்பட்டுள்ளது.

படி 1: பிளாட்ஃபார்மை உறுதிப்படுத்தவும்

Rohit உள்நுழைந்து கணினியைச் சரிபார்க்கிறார்:

cat /etc/alpine-release
ldd --version
apk info -e openssh-server openssh-server-pam

முதல் கட்டளை Alpine பதிப்பைக் காட்டுகிறது. இரண்டாவது musl-இன் பெயரைக் குறிப்பிடுகிறது. மூன்றாவது இரண்டு பேக்கேஜ்களில் எது நிறுவப்பட்டுள்ளது என்பதைப் பட்டியலிடுகிறது. Acme-இன் சர்வரில், openssh-server மட்டுமே தோன்றுகிறது, எனவே அங்கு PAM இல்லை.

ஒருவேளை ldd --version அதற்குப் பதிலாக glibc-ஐக் குறிப்பிட்டால், அல்லது கணினியில் SSH சர்வர் இயங்கவில்லை என்றால், அவர்கள் சோதனையை நிறுத்திவிட்டு அடுத்த கணினிக்குச் செல்லலாம்.

படி 2: sshd உண்மையில் எதைச் செயல்படுத்துகிறது என்பதைப் படியுங்கள்

இந்த படியைத்தான் பெரும்பாலான குழுக்கள் தவிர்க்கின்றன. உள்ளமைவு (config) கோப்பைப் படித்துவிட்டு அனுமானம் செய்து கொள்ளாதீர்கள். சர்வரில் நடைமுறையில் உள்ள அமைப்புகளை அதனிடமிருந்தே கேளுங்கள்:

sshd -T | grep -iE '^(passwordauthentication|usepam|permitrootlogin|authenticationmethods)'

Rohit இதைப் பார்க்கிறார்:

permitrootlogin prohibit-password
passwordauthentication yes
authenticationmethods any

அங்குதான் ஆச்சரியம் காத்திருக்கிறது. கடவுச்சொல் உள்நுழைவுகள் இயக்கத்தில் உள்ளன. ஊழியர்கள் எப்போதும் கீகளை (keys) பயன்படுத்தியதால், யாரும் இதைக் கவனிக்கவில்லை. PAM இல்லாத பில்ட் usepam என்பதை அச்சிடவே செய்யாது, அதனால்தான் இந்த வெளியீட்டில் அத்தகைய வரி இல்லை.

அமைப்புகள் ஒவ்வொரு இணைப்புக்கும் ஏற்ப Match விதிகள் மூலம் மாறக்கூடும், எனவே அவர்கள் ஒரு குறிப்பிட்ட பயனர் மற்றும் முகவரிக்கான அமைப்புகளைச் சோதிக்கிறார்கள்:

sshd -T -C user=deploy,host=bastion.example.com,addr=203.0.113.10 | grep -i '^passwordauthentication'

படி 3: கணக்குத் தரவைச் சரிபார்க்கவும்

root ஆக இயக்கப்படும்போது, இந்த இரண்டு கட்டளைகளும் கணக்கு பெயர்களை மட்டுமே அச்சிடுகின்றன, ஹாஷ்களை ஒருபோதும் அச்சிடாது:

awk -F: '$2 == "*" {print "star: " $1}' /etc/shadow
awk -F: '$2 ~ /^\$[56]\$/ {print "hash: " $1}' /etc/shadow

Rohit-இன் முடிவு:

star: deploy
hash: backup-admin

எனவே deploy, அதாவது "key-only" கணக்கு, ஒரு * புலத்தைக் கொண்டுள்ளது. மற்றும் backup-admin, கன்சோல் அணுகலுக்காக கடந்த ஆண்டு உருவாக்கப்பட்டது, ஒரு தகுதியான ஹாஷைக் கொண்டுள்ளது. நான்கு நிபந்தனைகளும் பூர்த்தியாகின்றன. இந்த சர்வர் பாதிப்பிற்கு உள்ளாகியுள்ளது.

படி 4: முதலில் வழியை அடைக்கவும், பின்னர் பேட்ச் செய்யவும்

Rohit தனது தற்போதைய அமர்வைத் திறந்து வைத்துக்கொண்டு, இரண்டாவது டெர்மினலில் இருந்து தனது கீ வேலை செய்கிறது என்பதை உறுதிப்படுத்துகிறார். இங்கு செய்யப்படும் ஒரு தவறு அனைவரையும் வெளியே பூட்டிவிடக்கூடும் (lockout), மேலும் திறந்திருக்கும் அமர்வே அவர்களின் பாதுகாப்பு கயிறாகும்.

அவர்கள் இந்த அமைப்பை இதில் சேர்க்கிறார்கள்: /etc/ssh/sshd_config:

PasswordAuthentication no

ஒரு ஆபத்து: பெரும்பாலான அமைப்புகளுக்கு OpenSSH தான் முதலில் படிக்கும் மதிப்பையே பயன்படுத்துகிறது. கோப்பில் மேலே ஒரு Include வரி இருந்தால், அல்லது கீழே ஒரு Match பிளாக் (block) இருந்தால், புதிய வரி வெற்றி பெறாமல் போகலாம். அதனால்தான் திருத்தம் செய்த உடனேயே இந்த சரிபார்ப்பு செய்யப்படுகிறது:

sshd -t
sshd -T | grep -i '^passwordauthentication'

sshd -t உள்ளமைவில் பிழைகள் உள்ளதா என சோதிக்கிறது. அது வெற்றிகரமாக இருந்தால், வெளியிடப்பட்ட Alpine தீர்வை அவர்கள் பயன்படுத்துகிறார்கள். Alpine ஆனது 3.21.10, 3.22.8, 3.23.8 மற்றும் 3.24.4 பதிப்புகளை வெளியிட்டுள்ளது, மேலும் OpenRC அமைப்புகளில் இதற்கான தீர்வு:

apk upgrade -U -a
rc-service sshd restart

மறுதொடக்கம் (restart) செய்வது கட்டாயமாகும். ஒரு பேக்கேஜை நிறுவுவது நினைவகத்தில் ஏற்கனவே இயங்கிக் கொண்டிருக்கும் SSH சர்வரை மாற்றாது.

படி 5: வெளியிலிருந்து அதை நிரூபிக்கவும்

இப்போது Rohit ஒரு வெளியாள் சோதிப்பது போல, மற்றொரு கணினியிலிருந்து தனது சொந்த சர்வருக்கு எதிராகச் சோதிக்கிறார்:

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password [email protected]

அவர்கள் எதிர்பார்க்கும் பதில் இது போன்ற ஒரு மறுப்பாகும்: Permission denied (publickey). இதன் பொருள் சர்வர் இனி கடவுச்சொற்களை ஒருபோதும் அனுமதிக்காது என்பதாகும். ஊழியர்கள் இன்னும் உள்நுழைய முடிகிறதா என்பதை உறுதிப்படுத்த, அவர்கள் ஒரு புதிய டெர்மினலில் சாதாரண கீ-அடிப்படையிலான அமர்வைத் திறக்கிறார்கள்.

படி 6: கடந்த கால முறைகேடுகளைத் தேடுங்கள்

பேட்ச் செய்வது வழியை அடைக்கிறது, ஆனால் ஏற்கனவே யார் அதன் வழியாக நுழைந்தார்கள் என்பதைப் பற்றி அது எதுவும் கூறுவதில்லை. இந்த குறிப்பிட்ட பதிவிற்காக பதிவுகளை (logs) மதிப்பாய்வு செய்யுமாறு Alpine பரிந்துரைக்கிறது:

grep 'Accepted password for' /var/log/messages

ஊழியர்கள் கீகளை மட்டுமே பயன்படுத்தும் ஒரு சர்வரில், வெற்றிகரமான கடவுச்சொல் உள்நுழைவு என்பது நாம் பின்தொடர வேண்டிய சமிக்ஞையாகும். தொடர்ச்சியான தோல்விகளைக் கண்காணிக்கும் கண்காணிப்பு அமைப்புகள் இதை முற்றிலும் தவறவிடக்கூடும், ஏனெனில் இங்கு தாக்குபவரின் முயற்சி ஒரு வெற்றியாகவே தோன்றுகிறது.

Rohit-க்கு எதுவும் கிடைக்கவில்லை. ஒருவேளை deploy-க்கு அத்தகைய ஒன்று கிடைத்திருந்தால், அவர்களின் பணி பேட்ச் செய்வதிலிருந்து சம்பவ பதிலளிப்பாக (incident response) மாறியிருக்கும். சிறப்புரிமை உயர்வு (privilege escalation), புதிய பயனர்கள், புதிய கோப்புகள் மற்றும் மாற்றப்பட்ட அங்கீகரிக்கப்பட்ட கீகள் ஆகியவற்றைச் சரிபார்க்குமாறும், அங்கீகரிக்கப்படாத உள்நுழைவை நிராகரிக்க முடியாவிட்டால் அந்த ஹோஸ்ட் சமரசம் செய்யப்பட்டுவிட்டது எனக் கருதுமாறும் Alpine அறிவுறுத்துகிறது. சேமிக்கப்பட்ட நற்சான்றிதழ்கள் மற்றும் டிப்ளாய்மென்ட் ரகசியங்கள் (deployment secrets) உட்பட அந்த கணக்கு அணுகக்கூடிய அனைத்தும் மதிப்பாய்வு செய்யப்பட்டு மாற்றப்பட வேண்டும்.

சந்தேகத்திற்கிடமான உள்நுழைவு நடந்த நேரத்தில் கணக்கு எவ்வாறு இருந்தது என்பதையும் சரிபார்க்கவும். அதன் தற்போதைய நிலை பிற்கால மாற்றத்தைப் பிரதிபலிக்கக்கூடும்.

படி 7: தயாரிப்பை மட்டுமல்லாமல், அதை உருவாக்கும் தொழிற்சாலையையும் சரிசெய்யவும்

Acme சேமிக்கப்பட்ட ஒரு இமேஜில் இருந்தே சர்வர்களை உருவாக்குகிறது. Rohit படி 6 உடன் நிறுத்தியிருந்தால், அடுத்த மறுஉருவாக்கம் அல்லது ஆட்டோஸ்கேலிங் நிகழ்வு பழைய அமைப்புகளை மீண்டும் அப்படியே கொண்டு வந்திருக்கும். அவர்கள் டெம்ப்ளேட்டைப் புதுப்பித்து, அங்கே PasswordAuthentication no என்று அமைத்து, ஏன் backup-admin கணக்கிற்கு கடவுச்சொல் தேவைப்படுகிறது என்று கேள்வி எழுப்புகிறார்கள்.

ஸ்கேனர் முடிவுகளை எவ்வாறு புரிந்துகொள்வது

இந்த வாரம் இரைச்சல் மிகுந்த (noisy) அறிக்கைகளை எதிர்பார்க்கலாம். இரண்டு யோசனைகளைத் தனித்தனியாகப் பிரித்துப் பார்க்கவும்.

அப்ஸ்ட்ரீம் (upstream) பதிப்பு சரம் மற்றும் ஒரு விநியோகத்தின் (distribution) பேட்ச் நிலை ஆகியவை வெவ்வேறு ஆதாரங்களாகும். ஒரு விற்பனையாளர் முதன்மை பதிப்பை மாற்றாமல் ஒரு தீர்வை பேக்போர்ட் (backport) செய்யலாம், எனவே உங்கள் விநியோகத்தின் பேக்கேஜ் வழிகாட்டுதலைப் பின்பற்றவும். நீங்களே OpenSSH-ஐ கம்பைல் செய்தால், 10.6p2 வெளியீட்டுக் குறிப்புகளைப் பயன்படுத்தவும்.

ஒவ்வொரு சர்வருக்கும் நான்கு தனித்தனி உண்மைகளைக் கண்காணிக்கவும்: பாதிக்கப்படக்கூடிய பேக்கேஜ் அடையாளம் காணப்பட்டது, மாற்று பேக்கேஜ் நிறுவப்பட்டது, சேவை மறுதொடக்கம் செய்யப்பட்டது, கட்டமைப்பு சரிபார்க்கப்பட்டது. ஒரு டிக்கெட்டில் "Patched" என்பது பெரும்பாலும் இரண்டாவது ஒன்றை மட்டுமே குறிக்கிறது.

தீர்வு ஏன் இவ்வளவு விரைவாக வந்தது

தீர்வை வெளியிடுவதற்கு முந்தைய நாள்தான் OpenSSH குழு இந்த சிக்கலைப் பற்றி அறிந்தது என்று Damien Miller கூறினார். AI முகவர்கள் சில மணிநேரங்களுக்குள் பாதிப்புகளை சுயமாக மீண்டும் கண்டறியும் சமீபத்திய நிகழ்வுகளை அவர் சுட்டிக்காட்டினார், மேலும் நீண்ட கால தடைக்காலங்கள் (embargoes) தாக்குபவர்களுக்கு சாதகமாக அமையக்கூடும் என்று வாதிட்டார்.

திட்டமிடப்பட்ட வெளியீடுகளுக்காக மாற்றங்களைத் தடுத்து வைக்காமல், அடிக்கடி திருத்தங்களை வெளியிடும் நோக்கிய நகர்வை வெளியீட்டுக் குறிப்புகள் விவரிக்கின்றன; அதே சமயம் AI உருவாக்கிய பல அறிக்கைகள் நடைமுறை பாதுகாப்பு தாக்கத்தை வெளிப்படுத்துவதில்லை என்பதையும் மனித பகுப்பாய்வு இன்னும் முக்கியமானது என்பதையும் அவை வலியுறுத்துகின்றன.

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

இந்தப் புள்ளிகள் பாதிப்பு மற்றும் அதற்கான விவேகமான பதிலளிப்பை விவரிக்கின்றன. இவை உறுதிப்படுத்தப்பட்ட தாக்குதல் நடவடிக்கைக்கான சான்றுகள் அல்ல.

உண்மையான பாடம்: ஒன்றுபோலத் தோன்றும் ஆனால் ஒரே மாதிரியாக இல்லாத மூன்று சொற்றொடர்கள்

"SSH கீகளைப் பயன்படுத்துகிறது", "கடவுச்சொல் அமைக்கப்படவில்லை" மற்றும் "கடவுச்சொல் மூலம் அங்கீகரிக்க முடியாது" ஆகியவை ஒரே மாதிரியாகத் தோன்றினாலும், அவை வெவ்வேறு விஷயங்களை விவரிக்கின்றன. முதலாவது ஒரு பழக்கம். இரண்டாவது தரவின் நிலை. மூன்றாவது மட்டுமே நடைமுறைப்படுத்தப்பட்ட ஒரு கட்டுப்பாடாகும், மேலும் இயங்கும் சர்வரைச் சோதிப்பதன் மூலம் மட்டுமே நீங்கள் அதை அறிய முடியும்.

முடிவுரை

இது ஒரு கூர்மையான முனையைக் கொண்ட ஒரு குறுகிய பிழையாகும். பெரும்பாலான Linux அமைப்புகள் இதற்கு அப்பாற்பட்டவை, ஆனால் நான்கு நிபந்தனைகளையும் பூர்த்தி செய்யும் ஒரு musl-அடிப்படையிலான சர்வர், கடவுச்சொல்லைக் கொண்டிருக்கவே கூடாத ஒரு கணக்கிற்கான உள்நுழைவை ஏற்கக்கூடும். புதுப்பிக்கவும், மறுதொடக்கம் செய்யவும், இதை அமைக்கவும்: PasswordAuthentication no, வெளியிலிருந்து சரிபார்க்கவும், உங்கள் பதிவுகளைப் படித்து உங்கள் டெம்ப்ளேட்டுகளை சரிசெய்யவும். பின்னர் உங்கள் நிறுவனத்தில் "key-only" என்றால் என்ன என்பதை எழுதி வைத்து, அதைச் சோதிக்கவும்.

நன்மைகள்

• பாதிப்பு குறிப்பிட்ட ஒன்றாக இருப்பதால், குழுக்கள் பெரும்பாலான அமைப்புகளை விரைவாக விலக்கிவிட முடியும்.
• சரிசெய்யப்பட்ட Alpine வெளியீடுகள் மற்றும் எளிய தற்காலிக தணிப்பு முறை ஏற்கனவே கிடைக்கின்றன.
• சரிபார்ப்புகள் நிலையான கருவிகளைப் பயன்படுத்துகின்றன மற்றும் ஒரு சர்வருக்கு சில நிமிடங்கள் மட்டுமே ஆகும்.
• உள்நுழைவுகள் மற்றும் கணக்குத் தரவை மதிப்பாய்வு செய்வது இந்த ஒரு பிழையைத் தாண்டி பாதுகாப்பை மேம்படுத்துகிறது.

குறைபாடுகள்

• "OpenSSH நிறுவப்பட்டுள்ளது" என்று மட்டுமே காட்டும் சொத்துப் பட்டியல்களால் (asset lists) இந்தக் கேள்விக்கு பதிலளிக்க முடியாது.
• கடவுச்சொல் பயனரைச் சேர்ப்பது போன்ற ஒரு வழக்கமான மாற்றம், பாதுகாப்பான கணினியை பாதிப்பிற்கு உள்ளாக்கக்கூடும்.
• SSH அமைப்புகளில் ஏற்படும் தவறுகள் நிர்வாகிகளை வெளியே பூட்டிவிடக்கூடும் (lockout).
• பேட்ச் செய்வது முந்தைய அங்கீகரிக்கப்படாத அணுகலை வெளிப்படுத்தவோ அல்லது செயல்தவிர்க்கவோ செய்யாது.

எச்சரிக்கை

இந்தக் கட்டுரை கல்வி நோக்கங்களுக்கானது மற்றும் எழுதும் நேரத்தில் கிடைக்கப்பெற்ற வெளியிடப்பட்ட ஆலோசனைகள் மற்றும் அறிக்கைகளை அடிப்படையாகக் கொண்டது. Acme, Rohit, deploy, backup-admin, hostname மற்றும் IP முகவரி ஆகியவை கற்பனையான ஒதுக்கிடங்கள் (placeholders) என்பதால், அவற்றை உங்கள் சொந்த மதிப்புகளால் மாற்றவும். SSH அமைப்புகளை மாற்றும்போது செயலில் உள்ள ஒரு session-ஐத் திறந்து வைத்திருக்கவும், நீங்கள் சோதிக்க அங்கீகரிக்கப்பட்ட அமைப்புகளை மட்டுமே சோதிக்கவும், மேலும் அவற்றை நம்புவதற்கு முன் தற்போதைய OpenSSH மற்றும் Alpine ஆலோசனைகள் அல்லது உங்கள் சொந்த விற்பனையாளரின் வழிகாட்டுதலுக்கு ஏற்ப விவரங்களைச் சரிபார்க்கவும்.

அடிக்கடி கேட்கப்படும் கேள்விகள்

• OpenSSH 10.6p2 என்றால் என்ன? — இது குறிப்பிட்ட musl-அடிப்படையிலான Linux அமைப்புகளைப் பாதிக்கும் login bypass-க்கான மாற்றுத் தீர்வுடன் கூடிய, 5 நவம்பர் 2026 தேதியிட்ட ஓர் அவசர Portable OpenSSH வெளியீடாகும்.
• ஒவ்வொரு Alpine Linux அமைப்பும் பாதிக்கப்படக்கூடியதா? — இல்லை. ஒரு கணினிக்கு PAM இன்றி கடவுச்சொற்களைச் சரிபார்க்கும் இயங்கும் SSH சர்வர், செயல்படுத்தப்பட்ட கடவுச்சொல் அங்கீகரிப்பு, மற்றும் ஒரு * கடவுச்சொல் புலம் கொண்ட ஓர் இலக்கு கணக்கு, மற்றும் ஒரு $5$ அல்லது $6$ hash கொண்ட மற்றொரு உள்ளூர் கணக்கு ஆகியவை தேவைப்படும்.
• Ubuntu, Debian மற்றும் பிற glibc அமைப்புகள் பாதிக்கப்பட்டுள்ளனவா? — glibc-ஐப் பயன்படுத்தும் Linux அமைப்புகள், Linux அல்லாத தளங்கள் மற்றும் PAM வழியாக கடவுச்சொற்களைச் சரிபார்க்கும் Linux அமைப்புகள் ஆகியவை குறிப்பிடப்பட்ட பாதிப்பு வரம்பிற்கு வெளியே உள்ளன.
• Alpine Docker கன்டெய்னர்கள் ஆபத்தில் உள்ளனவா? — இயங்கும் SSH சர்வர் இல்லாத கன்டெய்னர்கள் இந்தத் தாக்குதல் பாதைக்கு வெளியே உள்ளன, எனவே ஒரு கன்டெய்னர் உண்மையில் sshd-ஐ இயக்குகிறதா என்பதே கேள்வியாகும்.
• PermitRootLogin prohibit-password என்னைப் பாதுகாக்குமா? — இது root-க்கான நேரடி கடவுச்சொல் உள்நுழைவுகளைத் தடுக்கிறது, ஆனால் ஒரு தாக்குதல்தாரர் மற்றொரு கணக்கின் வழியாக நுழைந்து அதிகாரத்தை உயர்த்துவதை (escalate) இது தடுக்காது; இது tiny-cloud alpine கணக்கு சூழ்நிலையில் நிகழ்ந்தது போல.
• பேக்கேஜைப் புதுப்பிப்பது மட்டுமே போதுமானதா? — இல்லை. நீங்கள் SSH சேவையையும் மறுதொடக்கம் செய்ய வேண்டும், ஏனென்றால் நீங்கள் அவ்வாறு செய்யும் வரை பழைய சர்வர் நினைவகத்தில் தொடர்ந்து இயங்கிக்கொண்டிருக்கும்.
• இன்று என்னால் புதுப்பிக்க முடியாவிட்டால் நான் என்ன செய்ய வேண்டும்? — அமைக்கவும் PasswordAuthentication no, நடைமுறையிலுள்ள அமைப்பை இதன் மூலம் உறுதிப்படுத்தவும் sshd -T, மற்றும் ஏற்கனவே உள்ள ஒரு session-ஐத் திறந்து வைத்துக்கொண்டே key அணுகலைச் சோதிக்கவும்.
• யாராவது இதை ஏற்கனவே பயன்படுத்தியுள்ளார்களா என்பதை எவ்வாறு சரிபார்ப்பது? — தேடவும்: /var/log/messages இல் இந்த Accepted password for பதிவுகளை, கடவுச்சொற்களைப் பயன்படுத்தக்கூடாத கணக்குகளில் சரிபார்க்கவும்; மேலும் அங்கீகரிக்கப்படாத உள்நுழைவை நிராகரிக்க முடியாவிட்டால் host சமரசம் செய்யப்பட்டதாகக் கருதவும்.

குறிச்சொற்கள்

#OpenSSH #AlpineLinux #LinuxSecurity #SSH #AuthenticationBypass #Musl #DevSecOps #CloudSecurity #PatchManagement #IncidentResponse