Ubuntu-வில் Post-Quantum SSH மாற்றங்கள் என்ன?

Post-quantum SSH-ல் என்ன மாற்றங்கள் செய்யப்பட்டுள்ளன

பெரும்பாலான பயனர்களுக்கு Post-quantum SSH ஏற்கனவே செயல்படுத்தப்பட்டுவிட்டது, இதற்காக யாரும் எந்த அமைப்பையும் (configuration) மாற்ற வேண்டியதில்லை. தற்போதைய OpenSSH client மற்றும் OpenSSH server ஆகியவற்றுக்கு இடையேயான தொடர்பில், இயல்பாகவே hybrid post-quantum key exchange பயன்படுத்தப்படுகிறது. இதனால், இன்றைய network traffic-ஐப் பதிவு செய்து, வருங்காலத்தில் அதை decrypt செய்ய முயற்சிக்கும் தாக்குதல் நடத்துபவர்களிடமிருந்து session key பாதுகாக்கப்படுகிறது. இந்த பாதுகாப்பு உண்மையானது, ஆனால் "quantum-safe SSH" என்ற சொல் குறிப்பதைப் போல இது ஒரு குறிப்பிட்ட எல்லைக்கு உட்பட்டது.

முதலில் இரண்டு கலைச்சொற்களைப் புரிந்துகொள்வோம். SSH (secure shell) என்பது நீங்கள் server-க்குள் நுழையப் பயன்படுத்தும் protocol ஆகும். Key exchange, பொதுவாக "kex" என்று அழைக்கப்படுகிறது, இது ஒவ்வொரு SSH இணைப்பின் முதல் கட்டமாகும்: இதில் இரு முனைகளும் ஒரு பொதுவான ரகசியத்தை (shared secret) ஒப்புக்கொள்கின்றன, அந்த ரகசியமே அதன் பிறகு வரும் அனைத்துத் தரவுகளையும் encrypt செய்கிறது. இந்த key exchange பகுதியில் மட்டுமே மாற்றம் செய்யப்பட்டுள்ளது. மற்ற எந்தப் பகுதியிலும் மாற்றம் இல்லை.

இந்த பக்கத்தை நம்ப வேண்டாம், கட்டளைகளை நீங்களே இயக்கவும்

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

உங்கள் build எவற்றை ஆதரிக்கிறது என்பதிலிருந்து தொடங்கவும்.

ssh -V
ssh -Q kex

ssh -V என்பது OpenSSH_-ல் தொடங்கி, Ubuntu package suffix மற்றும் OpenSSL version-ஐத் தொடர்ந்து ஒரு version வரியை அச்சிடுகிறது. ssh -Q kex ஒவ்வொரு வரியிலும் ஒரு key exchange algorithm-ஐ அச்சிடுகிறது. Post-quantum ஆதரவு கொண்ட build-ல், curve25519-sha256 போன்ற பாரம்பரிய பெயர்களுக்கு அருகில் mlkem768x25519-sha256 மற்றும் sntrup761x25519-sha512@openssh.com போன்ற பெயர்களை அந்தப் பட்டியலில் நீங்கள் காணலாம்.

உங்கள் build எதை ஆதரிக்கிறது என்பது அது எதை வழங்குகிறது என்பதல்ல

பெரும்பாலான பதிவுகள் தவிர்க்கும் முக்கியமான வேறுபாடு இது. ssh -Q kex ஒரு கேள்விக்கு மட்டுமே பதிலளிக்கிறது: இந்த binary என்ன செய்ய முடியும். நீங்கள் கவலைப்படும் கேள்விக்கு இது பதிலளிக்காது: இந்த connection உண்மையில் எதை முன்மொழியும். இந்த இரண்டு பட்டியல்களும் வெவ்வேறானவை, அவற்றுக்கு இடையேயான இடைவெளியில்தான் பழைய ஆலோசனைகள் உண்மையான பாதிப்பை ஏற்படுத்துகின்றன.

ssh -G example.com | grep -i '^kexalgorithms'
sudo sshd -T | grep -i '^kexalgorithms'

ssh -G <host>, ~/.ssh/config மற்றும் /etc/ssh/ssh_config ஆகியவை பயன்படுத்தப்பட்ட பிறகு, அந்த host-க்கான client-ன் பயனுள்ள configuration-ஐ அச்சிடுகிறது. sshd -T server-க்கு இதையே செய்கிறது. ஒவ்வொன்றும் முன்னுரிமை வரிசையில் ஒரு kexalgorithms வரியை அச்சிடும், அதில் உள்ள முதல் பெயர் அந்தத் தரப்பின் முதல் தேர்வாகும். அந்த வரிதான் network-ல் செல்லும்.

இந்த இடைவெளி வெறும் கோட்பாடு அல்ல. 2021-03-03 அன்று வெளியிடப்பட்ட OpenSSH 8.5, sntrup761x25519-sha512@openssh.com-ஐச் சேர்த்தது, ஆனால் அதை default பட்டியலில் வேண்டுமென்றே சேர்க்கவில்லை. அந்த வெளியீட்டில் ssh -Q kex அந்த algorithm-ஐக் காட்டுகிறது, ஆனால் ssh -G காட்டுவதில்லை. இதன் பொருள், அந்த binary-ஆல் post-quantum key exchange செய்ய முடியும், ஆனால் எந்த connection-ம் அதைச் செய்யக் கோருவதில்லை.

உங்கள் connection எந்த algorithm-ஐ negotiate செய்தது என்பதைப் படித்தல்

ssh -v example.com 2>&1 | grep 'kex: algorithm'

தற்போதைய client மற்றும் server-க்கு இடையே, அது பின்வருவனவற்றைக் காட்டும்:

debug1: kex: algorithm: mlkem768x25519-sha256

mlkem768x25519-sha256 என்பது ஒரு hybrid ஆகும். இது parameter set 768-ல் ML-KEM (module-lattice key encapsulation mechanism, FIPS 203 என தரப்படுத்தப்பட்டது) மற்றும் X25519 elliptic curve Diffie-Hellman ஆகியவற்றை இயக்கி, இரண்டின் வெளியீடுகளையும் session key-ல் கலக்கிறது.

பழைய server-உடன் இணைக்கும்போது, அதற்குப் பதிலாக இதைக் காணலாம்:

debug1: kex: algorithm: curve25519-sha256

அந்தப் பெயரில் post-quantum பகுதி இல்லை. curve25519-sha256 என்பது elliptic curve Diffie-Hellman மட்டுமே, இதை ஒரு பெரிய quantum computer-ஆல் உடைக்க முடியும். இதுவே default முறை மாற்றப்பட்டதற்கான முழுமையான காரணம்.

ஒரு பழைய machine எப்படி session-ஐத் தடுத்து நிறுத்துகிறது என்பதை ஒரு negotiation விதி விளக்குகிறது. Client தனது பட்டியலை முன்னுரிமை வரிசையில் அனுப்பும், server தனது பட்டியலை அனுப்பும், client-ன் பட்டியலில் உள்ள பெயர்களில் server-ன் பட்டியலிலும் முதலில் இடம்பெறும் பெயரே தேர்ந்தெடுக்கப்படும். Client-ன் முன்னுரிமையே வெல்லும், எனவே இரண்டில் எது பழையதோ அதுவே பட்டியலின் எந்த அளவு வரை செல்லலாம் என்பதைத் தீர்மானிக்கிறது. உங்கள் laptop-ஐ upgrade செய்வது, ML-KEM பற்றி அறியாத server-உடனான session-ஐ upgrade செய்யாது.

grep-ஐ நீக்கினால், ssh -v மீதமுள்ள negotiation-ஐக் காட்டும், அடுத்த பகுதியில் விவாதிக்கப்படும் வரியும் இதில் அடங்கும்:

debug1: kex: host key algorithm: ssh-ed25519

எந்த OpenSSH வெளியீடு hybrid exchange-ஐ இயல்பானதாக (default) மாற்றியது

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

• 8.5, 2021-03-03 அன்று வெளியிடப்பட்டது, இது sntrup761x25519-sha512@openssh.com-ஐச் சேர்த்தது மற்றும் இயல்பாகவே அதை முடக்கியிருந்தது.
• 9.0, 2022-04-08 அன்று வெளியிடப்பட்டது, இது அதைச் செயல்படுத்தியது. OpenSSH "இயல்பாகவே hybrid Streamlined NTRU Prime + x25519 key exchange முறையைப் பயன்படுத்தும்" என்று குறிப்புகள் கூறுகின்றன. இந்த வெளியீட்டில்தான் post-quantum key exchange சாதாரணமான ஒன்றாக மாறியது.
• 9.9, 2024-09-19 அன்று வெளியிடப்பட்டது, இது mlkem768x25519-sha256-ஐ இரண்டாவது விருப்பமாகச் சேர்த்தது. அதே வெளியீடு பழைய முறைக்கு IANA பதிவு செய்த பெயரான sntrup761x25519-sha512-ஐ வழங்கியது, எனவே புதிய build-கள் அதை இரண்டு பெயர்களிலும் பட்டியலிடுகின்றன.
• 10.0, 2025-04-09 அன்று வெளியிடப்பட்டது, இது mlkem768x25519-sha256-ஐ key agreement-க்கான இயல்பான தேர்வாக மாற்றியது.
• 10.1, 2025-10-06 அன்று வெளியிடப்பட்டது, இது post-quantum பாதி இல்லாத key exchange-ஐ ஒரு connection பேச்சுவார்த்தை நடத்தும்போது client எச்சரிக்கையைச் சேர்த்தது. இது ssh_config-ல் உள்ள WarnWeakCrypto விருப்பத்தால் கட்டுப்படுத்தப்படுகிறது மற்றும் இயல்பாகவே இது செயல்பாட்டில் இருக்கும்.

ஏப்ரல் 2022 என்பது நினைவில் கொள்ள வேண்டிய தேதியாகும். OpenSSH 9.0 அல்லது அதற்குப் பிந்தைய பதிப்புகளை இயக்கும் எந்தவொரு இயந்திர ஜோடியும், எந்தவொரு உள்ளமைவும் (configuration) இல்லாமலும், ssh-ஐத் தட்டச்சு செய்யும் நபருக்கு எந்த அறிவிப்பும் இல்லாமலும், அன்றிலிருந்து post-quantum key exchange-ஐச் செய்து வருகின்றன.

எந்த Ubuntu release-ல் இது கிடைக்கிறது

Ubuntu ஒரு குறிப்பிட்ட OpenSSH version-ஐ அதன் release-ல் அப்படியே வைத்துக்கொண்டு, version எண்ணை மாற்றாமல் பாதுகாப்புத் திருத்தங்களை (security fixes) மட்டும் backport செய்கிறது. எனவே, நீங்கள் பயன்படுத்தும் Ubuntu release-தான் உங்கள் default algorithm-ஐத் தீர்மானிக்கிறது. ஒரு பட்டியலை நம்புவதை விட, ssh -V கட்டளையைப் பயன்படுத்தி உங்கள் கணினியில் உள்ள நிலையைச் சரிபார்க்கவும். ஆகஸ்ட் 2026 நிலவரப்படி, archive-ல் உள்ள version-கள் இவை:

• 22.04 LTS-ல் 1:8.9p1 உள்ளது. இது 9.0 default-க்கு முந்தையது என்பதால், ஒரு stock install curve25519-sha256-ஐ negotiate செய்கிறது.
• 24.04 LTS-ல் 1:9.6p1 உள்ளது. இது 9.0-க்கு பிந்தையது மற்றும் 9.9-க்கு முந்தையது என்பதால், இதன் default sntrup761x25519-sha512@openssh.com ஆகும்; இதில் ML-KEM இல்லை.
• 25.10-ல் 1:10.0p1 உள்ளது, இதன் default mlkem768x25519-sha256 ஆகும்.
• 26.04 LTS-ல் 1:10.2p1 உள்ளது. இது default-ஆக mlkem768x25519-sha256-ஐப் பயன்படுத்துகிறது மற்றும் post-quantum அல்லாத இணைப்புகள் குறித்து எச்சரிக்கிறது.

உண்மையான இரண்டு கணினிகளை வைத்துச் சோதித்துப் பாருங்கள். ஒரு 26.04 laptop, 24.04 server-உடன் இணைகிறது. client-ன் முதல் தேர்வான mlkem768x25519-sha256, 9.6 server-ன் பட்டியலில் இல்லை. server-ல் உள்ள client-ன் அடுத்த post-quantum தேர்வு sntrup761x25519-sha512@openssh.com ஆகும்; இதைத்தான் ssh -v காட்டுகிறது. எவரும் எதையும் configure செய்யாத நிலையில், 2024-ல் உருவாக்கப்பட்ட server-உடன், key exchange-ல் இந்த session post-quantum முறையில் அமைகிறது.

22.04-ன் நிலை இதற்கு நேர்மாறானது. ssh -Q kex-ஐ மட்டும் பார்ப்பது ஏன் தவறான முடிவைத் தரும் என்பதற்கு இதுவே சான்று. OpenSSH 8.9-க்கு sntrup761x25519-sha512@openssh.com பெயர் தெரியும், எனவே அந்த கணினியில் ssh -Q kex-ஐ இயக்கினால் அது பட்டியலிடப்படும். ஆனால், default proposal-ல் அது இல்லாததால், negotiation curve25519-sha256-ல் முடிவடைகிறது. OpenSSH 10.1 அல்லது அதற்குப் பிந்தைய client-லிருந்து இணைக்கும்போது, அந்த இணைப்பு இவ்வாறு தெரிவிக்கும்:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.

இந்த எச்சரிக்கை நீங்கள் அணுகும் server-ஐப் பற்றியது, உங்கள் client-ஐப் பற்றியது அல்ல. இதற்குத் தீர்வாக server-ஐ upgrade செய்ய வேண்டும். WarnWeakCrypto no-ஐ அமைப்பது அந்தச் செய்தியை நீக்குமே தவிர, இணைப்பில் எந்த மாற்றத்தையும் ஏற்படுத்தாது.

ஹைப்ரிட் (hybrid) ஏன் தேவை, மற்றும் 'இப்போதே சேகரித்து, பின்னாளில் மறைகுறியாக்கம் செய்' என்பதன் பொருள் என்ன?

இந்த அச்சுறுத்தல் எளிமையான வடிவம் கொண்டது. உங்கள் நெட்வொர்க் டிராஃபிக்கைக் கண்காணிக்கும் ஒரு தாக்குதல் நடத்துபவர், மறைகுறியாக்கப்பட்ட தரவுகளை இப்போதே பதிவு செய்து சேமித்து வைக்கிறார். அவரால் அவற்றை இப்போதே படிக்க முடியாது. X25519-ஐ உடைக்கக்கூடிய அளவுக்கு சக்திவாய்ந்த குவாண்டம் கணினி (quantum computer) வரும் வரை அவர் காத்திருந்து, அதன் பிறகு அவற்றை வாசிப்பார். இது 'harvest now, decrypt later' அல்லது 'store now, decrypt later' என்று அழைக்கப்படுகிறது. இதற்குத் தாக்குதல் நடத்துபவர் தற்போதைய சூழலில் எந்த நுணுக்கமான வேலையும் செய்யத் தேவையில்லை. அவருக்குத் தேவை வெறும் டிஸ்க் இடவசதியும், பொறுமையும் மட்டுமே.

மறைகுறியாக்கத்திற்கு (encryption) இந்தச் சிக்கல் உள்ளது, ஆனால் டிஜிட்டல் கையொப்பங்களுக்கு (signatures) இது பொருந்தாது. இந்த வேறுபாடே மற்ற அனைத்தையும் தீர்மானிக்கிறது. பதிவு செய்யப்பட்ட ஒரு சைபர் டெக்ஸ்ட் (ciphertext), அதிலுள்ள தரவு எவ்வளவு காலம் ரகசியமாக இருக்க வேண்டுமோ, அவ்வளவு காலம் அதன் மதிப்பைத் தக்கவைத்துக் கொள்கிறது. ஒரு கையொப்பம், அது சரிபார்க்கப்படும் தருணத்தில் போலியாக உருவாக்க முடியாததாக இருந்தால் போதுமானது. 2035-ல் ஒரு கையொப்ப அல்காரிதத்தை உடைப்பது, 2035-ல் ஒரு சர்வரைப் போல ஆள்மாறாட்டம் செய்ய மட்டுமே உதவும். அது 2026-ல் நடந்த ஒரு லாகின்-ஐ போலியாக உருவாக்க உதவாது. எனவே, கீ எக்ஸ்சேஞ்ச் (key exchange) முறையை முதலில் சரிசெய்ய வேண்டியிருந்தது, கையொப்பம் தொடர்பான மாற்றங்கள் காத்திருக்கலாம்.

ஹைப்ரிட் என்பது இரண்டு அல்காரிதம்களையும் இயக்கி, இரண்டின் முடிவுகளையும் சேர்த்து செஷன் கீ-யை (session key) உருவாக்குவதைக் குறிக்கும். mlkem768x25519-sha256-க்கு பின்னால் உள்ள ரகசியத்தை மீட்டெடுக்க, ஒரு தாக்குதல் நடத்துபவர் ML-KEM 768 மற்றும் X25519 ஆகிய இரண்டையும் உடைக்க வேண்டும். இந்த இணைப்பானது திட்டமிட்டுச் செய்யப்பட்டது: ML-KEM என்பது X25519-ஐ விட மிகவும் புதியது, மேலும் கிரிப்டோ அனலிஸ்ட்களால் (cryptanalysts) தாக்குதலுக்கு உள்ளான காலமும் குறைவு. எனவே, புதிய அல்காரிதத்தில் ஏதேனும் குறைபாடு கண்டறியப்பட்டாலும், அது உங்களுக்கு ஏற்கனவே இருந்த பாதுகாப்பைப் பாதிக்காது.

எது பாதுகாக்கப்படுகிறது, எது பாதுகாக்கப்படுவதில்லை

Key exchange பாதுகாக்கப்படுகிறது. உங்கள் session-ஐ encrypt செய்யும் shared secret ஒரு hybrid exchange மூலம் உருவானது. எனவே, இன்று பதிவு செய்யப்படும் session, எதிர்காலத்தில் quantum computers வரும்போது வாசிக்கக்கூடியதாக மாறாது.

Host key பாதுகாக்கப்படுவதில்லை. debug1: kex: host key algorithm: ssh-ed25519 வரி ஒரு classical signature-ஐக் குறிப்பிடுகிறது; rsa-sha2-512 மற்றும் ECDSA (elliptic curve digital signature algorithm) வகைகளும் அவ்வாறே. ஒரு quantum computer-ஐ வைத்திருக்கும் attacker, அந்த signature-ஐப் போலியாக உருவாக்கி உங்கள் server-ஆக நடிக்க முடியும். ஆனால், இது எதிர்காலத்தில் நேரடி connection-ன் போது மட்டுமே சாத்தியம்; தற்போது பதிவு செய்யப்பட்ட traffic-க்கு எதிராக இது வேலை செய்யாது.

உங்கள் login key-யும் பாதுகாக்கப்படுவதில்லை. ~/.ssh/id_ed25519-ல் உள்ள key அதே வகையான classical signature ஆகும்; அதே காரணங்கள் இதற்கும் பொருந்தும். இந்த வருடம் அந்த key-யைப் பாதுகாப்பது, அது எங்கு சேமிக்கப்பட்டுள்ளது மற்றும் அதை யாரால் வாசிக்க முடியும் என்பதுதான். எனவே, sensible SSH key management உங்கள் உண்மையான ஆபத்தை இந்த பக்கத்தில் உள்ள எந்த algorithm பெயரை விடவும் வெகுவாகக் குறைக்கிறது.

இவை இரண்டிற்கும் நீங்கள் செய்ய எதுவும் இல்லை, ஏனெனில் மாறுவதற்கு வேறு வழிகள் இல்லை. OpenSSH-ன் எதிர்கால release-ல் post-quantum signature ஆதரவு வரும் என்று அறிவிக்கப்பட்டுள்ளது. அது வெளியாகும் வரை, OpenSSH-ல் post-quantum host key வகையோ அல்லது post-quantum user key வகையோ இல்லை; ssh-keygen-ல் உங்களுக்கு வழங்க எதுவும் இல்லை. ஒன்றை உருவாக்கச் சொல்லும் வழிகாட்டி, இன்னும் உருவாக்கப்படாத மென்பொருளைப் பற்றி விவரிக்கிறது.

அதே server-ல் உள்ள TLS என்பது தனிப்பட்ட கேள்வி, அதற்குத் தனிப்பட்ட பதில் உண்டு. TLS (transport layer security) என்பது உங்கள் web server port 443-ல் பயன்படுத்தும் தொழில்நுட்பம்; இது வேறு codebase மற்றும் வேறு கால அட்டவணையைக் கொண்டது. OpenSSH-ஐ upgrade செய்வது அங்கு எதையும் மாற்றாது. நீங்கள் a self-signed certificate for a private service on the same VPS-ஐப் பயன்படுத்துகிறீர்கள் என்றால், அதன் signature மற்றும் key exchange ஆகியவற்றை OpenSSL மற்றும் உங்கள் web server தீர்மானிக்கின்றன. எனவே, அந்த stack-ஐப் பற்றித் தனியாகக் கவனிக்கவும்.

ஒரு பொறுப்பான நிர்வாகி இப்போது என்ன செய்ய வேண்டும்

OpenSSH-ஐ தற்போதைய நிலையில் வைத்திருங்கள், அதோடு நிறுத்திவிடுங்கள். இந்த சிக்கலுக்கான முழுமையான உத்தி இதுதான். sudo apt update && sudo apt upgrade உங்கள் Ubuntu release-ல் உள்ள பதிப்பிலேயே உங்களை வைத்திருக்கும், மேலும் புதிய Ubuntu release-க்கு மாறுவதுதான் உங்களை புதிய OpenSSH-க்கு கொண்டு செல்லும். unattended security upgrades-ஐ இயக்குவது, நீங்கள் நினைவில் கொள்ளாமலேயே அந்த patches-ஐ அமல்படுத்தும். ஒரு algorithm பெயரைத் துரத்துவதற்காக source-லிருந்து OpenSSH-ஐ உருவாக்குவது ஒரு மோசமான வர்த்தகம், ஏனெனில் server-ல் மிகவும் வெளிப்படையான இந்த service-க்கான distribution-ன் பாதுகாப்பு அப்டேட்களை நீங்கள் இழக்கிறீர்கள். எப்படியும் source-ஐ பதிவிறக்கம் செய்தால், அதை build செய்வதற்கு முன் அதன் checksum-ஐ சரிபார்க்கவும்.

KexAlgorithms வரியை நீங்களாக எழுத வேண்டாம். இதுதான் விஷயங்களை நிச்சயமாக மோசமாக்கும் ஒரே செயல். 2018-ன் ஒரு hardening guide உங்களுக்கு ஒரு பட்டியலைத் தரும், அது 2018-ல் சரியாக இருந்திருக்கலாம், அதை sshd_config-ல் நகலெடுத்து ஒட்டுவது, ஏற்கனவே உள்ள பட்டியலை நீக்கிவிட்டு புதியதை மாற்றும். அதற்குப் பிறகு கண்டுபிடிக்கப்பட்ட ஒவ்வொரு algorithm-ம் இப்போது நீக்கப்பட்டுவிடும், எனவே தானாகவே mlkem768x25519-sha256-ஐ negotiate செய்திருக்க வேண்டிய server, அந்தப் பட்டியலில் எஞ்சியிருக்கும் ஏதோ ஒன்றிற்குத் தரம் தாழ்ந்துவிடும். நீங்கள் பொறுப்பேற்ற எந்த server-லும் sudo sshd -T | grep -i '^kexalgorithms'-ஐ இயக்கவும். அதே release-ன் புதிய install-ல் உள்ள வரியை விட இது சிறியதாக இருந்தால், யாரோ அதை மாற்றியுள்ளனர் என்று அர்த்தம்.

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

KexAlgorithms ^mlkem768x25519-sha256

கோப்பை நம்புவதற்கு முன் அதைச் சோதிக்கவும். sudo sshd -t configuration-ஐ parse செய்யும், அது சரியாக இருந்தால் எதையும் அச்சிடாது. அந்த build-ல் இல்லாத ஒரு algorithm-ஐக் குறிப்பிடும் KexAlgorithms வரி sshd தொடங்குவதைத் தடுக்கும். ஒரு remote server-ல் இது நடந்தால், உங்களால் மீண்டும் உள்ளே நுழைய முடியாது, எனவே நீங்கள் வேலை செய்யும்போது இரண்டாவது session-ஐத் திறந்து வைத்திருங்கள். இரு தரப்புப் பட்டியல்களும் ஒத்துப்போகவில்லை என்றால், client அதைத் தெளிவாகக் கூறும்:

Unable to negotiate with 203.0.113.10 port 22: no matching key exchange method found. Their offer: curve25519-sha256,ecdh-sha2-nistp256

"Quantum-safe" என்ற சந்தைப்படுத்தல் வார்த்தையை ஒரு அடுக்கு பற்றிய கூற்றாக மட்டும் பார்க்கவும். ஒரு vendor தனது தயாரிப்பைக் quantum-safe என்று அழைத்தால், அவர்கள் குறிப்பிட்ட அந்த அடுக்கைப் பற்றி மட்டுமே பேசுகிறார்கள், அந்த அடுக்கு பெரும்பாலும் ஏதோ ஒரு key exchange-ஆக இருக்கும். அந்த algorithm-ன் பெயரையும் அது எந்த protocol-க்கு பொருந்தும் என்பதையும் கேட்கவும். ஆகஸ்ட் 2026-ல் OpenSSH-ஐப் பொறுத்தவரை, அந்த கூற்றின் உண்மையான பதிப்பு என்னவென்றால், key exchange என்பது hybrid post-quantum, ஆனால் signatures என்பது classical. இதைவிட விரிவான எதற்கும் ssh -Q kex output-ல் நீங்கள் காணக்கூடிய ஒரு பெயர் இருக்க வேண்டும்.

சலிப்பான வேலைகளைத் தொடர்ந்து செய்யுங்கள். ஒரு post-quantum key exchange, எளிதில் யூகிக்கக்கூடிய password-ஐயோ அல்லது திருடப்பட்ட laptop-ல் நகலெடுக்கப்பட்ட private key-யையோ ஒன்றும் செய்யாது. இவைதான் உண்மையில் server-களைப் பாதிப்பவை, மேலும் standard SSH hardening on a VPS இப்போதும் பெரும்பாலான பாதுகாப்பை வழங்குகிறது. இங்குள்ள negotiation நிலைகள் உங்களுக்குப் புரியவில்லை என்றால், what SSH does when you connect என்ற பக்கம், இந்தத் தளம் தெரிந்திருக்க வேண்டும் என்று கருதும் நிலைகளை விளக்குகிறது.

FAQ

எனது SSH இணைப்பு ஏற்கனவே post-quantum முறையில் உள்ளதா?

ssh -v yourserver 2>&1 | grep 'kex: algorithm' கட்டளையை இயக்கி, அது காட்டும் பெயரைப் பார்க்கவும். mlkem768x25519-sha256 மற்றும் sntrup761x25519-sha512@openssh.com ஆகியவை hybrid post-quantum பரிமாற்றங்கள் ஆகும். curve25519-sha256, ecdh-sha2-nistp256 மற்றும் ஏதேனும் diffie-hellman-group பெயர்கள் classical முறையைச் சேர்ந்தவை. இரு முனைகளிலும் post-quantum பெயரை ஆதரிக்கும் ஒரு பதிப்பு இருக்க வேண்டும். ஏனெனில், negotiation செயல்பாட்டில் client-ன் முதல் விருப்பத்தை server ஆதரித்தால் மட்டுமே அது தேர்ந்தெடுக்கப்படும்; எனவே, பழைய machine-ன் திறனே உச்சவரம்பாக அமையும்.

எந்த OpenSSH வெளியீட்டில் post-quantum key exchange இயல்பாக (default) மாற்றப்பட்டது?

2022-04-08 அன்று வெளியான OpenSSH 9.0, sntrup761x25519-sha512@openssh.com-ஐ இயல்பான key exchange-ஆக மாற்றியது. 2024-09-19 அன்று வெளியான OpenSSH 9.9, mlkem768x25519-sha256-ஐச் சேர்த்தது. 2025-04-09 அன்று வெளியான OpenSSH 10.0, அதையே இயல்பானதாக மாற்றியது. 2025-10-06 அன்று வெளியான OpenSSH 10.1, எந்தவொரு post-quantum முறையும் negotiation-ல் இல்லாதபோது எச்சரிக்கையைத் தொடங்கியது. உங்கள் Ubuntu வெளியீடு எதை வழங்குகிறது என்பதைப் பொறுத்து, உங்கள் build எதைச் செய்கிறது என்பதை ssh -Q kex மற்றும் ssh -G <host> மூலம் சரிபார்க்கவும்.

நான் post-quantum SSH key-ஐ உருவாக்க வேண்டுமா?

தேவையில்லை, ஏனெனில் OpenSSH-ல் அத்தகைய key வகை இல்லை. இதுவரை நடந்துள்ள post-quantum பணிகள் key exchange-ஐ மட்டுமே உள்ளடக்கியவை; இதற்கு உங்களிடமிருந்து எந்த key கோப்புகளோ அல்லது எந்த configuration-ஓ தேவையில்லை. Host keys மற்றும் login keys இன்னும் Ed25519 மற்றும் RSA போன்ற classical signatures-ஆகவே உள்ளன. எதிர்கால வெளியீட்டில் post-quantum signatures வரும் என்று upstream தெரிவித்துள்ளது. Ed25519 key-ஐத் தொடர்ந்து பயன்படுத்தவும், அது சேமிக்கப்பட்டுள்ள இடத்தைப் பாதுகாப்பாக வைத்திருக்கவும்.

எனது இணைப்பு post-quantum முறையில் இல்லை என்று ssh ஏன் எச்சரிக்கிறது?

OpenSSH 10.1 மற்றும் அதற்குப் பிந்தைய பதிப்புகள், negotiation-ல் post-quantum பகுதி இல்லாதபோது ** WARNING: connection is not using a post-quantum key exchange algorithm. என்ற செய்தியைக் காட்டுகின்றன. இந்த எச்சரிக்கை server-ஐப் பற்றியது, உங்கள் client-ஐப் பற்றியது அல்ல. ஏனெனில் உங்கள் client ஒரு post-quantum பெயரை வழங்கியது, ஆனால் server எதையும் ஏற்கவில்லை. Server-ன் OpenSSH-ஐ upgrade செய்யவும், அல்லது அதன் sshd_config கோப்பில் உள்ள KexAlgorithms வரியில் நவீன பெயர்களைத் தவிர்க்கும் வகையில் ஏதேனும் மாற்றப்பட்டுள்ளதா என்று சரிபார்க்கவும். WarnWeakCrypto no-ஐ அமைப்பது இந்தச் செய்தியை மறைக்கும், ஆனால் இணைப்பு முன்பு போலவே பலவீனமாகவே இருக்கும்.