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

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

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

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

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

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

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

ssh -V
ssh -Q kex

ssh -V என்பது OpenSSH_-ல் தொடங்கும் ஒரு version வரியையும், அதைத் தொடர்ந்து Ubuntu package suffix மற்றும் OpenSSL version-ஐயும் அச்சிடும். ssh -Q kex ஒவ்வொரு வரிக்கும் ஒரு key exchange அல்காரிதத்தை அச்சிடும். 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-ன் செயல்பாட்டு உள்ளமைவை (effective 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 ஆகும். இது ML-KEM-ஐ (module-lattice key encapsulation mechanism, FIPS 203 என தரப்படுத்தப்பட்டது) parameter set 768-ல், X25519 elliptic curve Diffie-Hellman உடன் சேர்த்து இயக்குகிறது, மேலும் இரண்டின் வெளியீடுகளையும் கலந்து session key-ஐ உருவாக்குகிறது.

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

debug1: kex: algorithm: curve25519-sha256

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

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

ssh -v என்பது இந்த ஒரு வரியைத் தாண்டித் தெரிந்துகொள்ள வேண்டியது, ஏனெனில் login நேரடியாக மறுக்கப்படும்போது, Permission denied (publickey) தோல்வியைக் கண்டறிய இதே வெளியீடுதான் பயன்படுகிறது.

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

debug1: kex: host key algorithm: ssh-ed25519

எந்த OpenSSH release-ல் hybrid exchange இயல்பான அமைப்பாக (default) மாற்றப்பட்டது

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

• 8.5, 2021-03-03 அன்று வெளியிடப்பட்டது, sntrup761x25519-sha512@openssh.com-ஐச் சேர்த்தது மற்றும் இயல்பாக அதை முடக்கியிருந்தது.
• 9.0, 2022-04-08 அன்று வெளியிடப்பட்டது, இதைச் செயல்படுத்தியது. OpenSSH "இயல்பாகவே hybrid Streamlined NTRU Prime + x25519 key exchange முறையைப் பயன்படுத்தும்" என்று குறிப்புகள் தெரிவிக்கின்றன. இந்த release-ல்தான் post-quantum key exchange பொதுவான ஒன்றாக மாறியது.
• 9.9, 2024-09-19 அன்று வெளியிடப்பட்டது, mlkem768x25519-sha256-ஐ இரண்டாவது விருப்பமாகச் சேர்த்தது. அதே release பழைய முறைக்கு IANA பதிவு செய்த பெயரான sntrup761x25519-sha512-ஐ வழங்கியது, எனவே புதிய builds இரண்டையும் பட்டியலிடுகின்றன.
• 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 ஒரு குறிப்பிட்ட release-ல் ஒரு OpenSSH version-ஐ நிலைநிறுத்திவிட்டு, அதன் version எண்ணை மாற்றாமல் பாதுகாப்புத் திருத்தங்களை (security fixes) மட்டும் backport செய்கிறது. எனவே, நீங்கள் பயன்படுத்தும் Ubuntu release-தான் உங்கள் default algorithm-ஐத் தீர்மானிக்கிறது. ஒரு பட்டியலை நம்புவதை விட, உங்கள் முன்னால் உள்ள machine-ஐ ssh -V மூலம் சரிபார்க்கவும். ஆகஸ்ட் 2026 நிலவரப்படி, archive-ல் உள்ள பதிப்புகள் இவை:

• 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 அல்லாத இணைப்புகள் குறித்து எச்சரிக்கிறது.

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

22.04-ன் நிலை இதற்கு நேர்மாறானது, இது ஏன் ssh -Q kex மட்டும் தவறான வழிகாட்டுதலைத் தருகிறது என்பதை விளக்குகிறது. OpenSSH 8.9-க்கு sntrup761x25519-sha512@openssh.com பெயர் தெரியும், எனவே அந்த box-ல் 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-ஐ அமைப்பது அந்தச் செய்தியை நீக்குமே தவிர, இணைப்பில் எந்த மாற்றத்தையும் ஏற்படுத்தாது.

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

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

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

ஹைப்ரிட் (hybrid) என்பது இரண்டு அல்காரிதம்களும் இயங்கி, அவற்றின் முடிவுகள் இரண்டும் சேர்ந்து செஷன் கீ-யை (session key) உருவாக்குவதைக் குறிக்கிறது. mlkem768x25519-sha256-க்கு பின்னால் உள்ள ரகசியத்தை மீட்டெடுக்க, ஒரு தாக்குதல் நடத்துபவர் ML-KEM 768 மற்றும் X25519 ஆகிய இரண்டையும் உடைக்க வேண்டும். இந்த இணைப்பானது திட்டமிட்டு உருவாக்கப்பட்டது: X25519-ஐ விட ML-KEM மிகவும் புதியது மற்றும் கிரிப்டோ அனலிஸ்ட்களால் (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) வகைகளும் அவ்வாறே. ஒரு தாக்குதலாளர் (attacker) சக்திவாய்ந்த quantum computer-ஐ வைத்திருந்தால், அந்த signature-ஐப் போலியாக உருவாக்கி உங்கள் server-ஆக நடிக்க முடியும். ஆனால், இது வருங்காலத்தில் நேரடி இணைப்பின் (live 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 வகையோ அல்லது user key வகையோ இல்லை; ssh-keygen-லும் உங்களுக்கு வழங்க எதுவுமில்லை. அத்தகைய key-யை உருவாக்கச் சொல்லும் வழிகாட்டி, இன்னும் உருவாக்கப்படாத மென்பொருளைப் பற்றிப் பேசுகிறது.

அதே server-ல் உள்ள TLS என்பது தனிப்பட்ட கேள்வி, அதற்குத் தனிப்பட்ட பதில் உண்டு. TLS (transport layer security) என்பது உங்கள் web server 443 port-ல் பயன்படுத்தும் தொழில்நுட்பம்; இது வேறு 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 வழங்கும் அதே version-ல் வைத்திருக்கும், மேலும் புதிய Ubuntu release-க்கு மாறுவதுதான் உங்களை புதிய OpenSSH-க்கு அழைத்துச் செல்லும். unattended security upgrades-ஐ ஆன் செய்வதன் மூலம், நீங்கள் நினைவில் கொள்ளாமலேயே அந்த patches தானாகவே அமல்படுத்தப்படும். ஒரு algorithm பெயரைத் துரத்துவதற்காக OpenSSH-ஐ source-லிருந்து build செய்வது ஒரு மோசமான பரிமாற்றம், ஏனெனில் அந்த server-ல் மிகவும் வெளிப்படையான service-க்கான distribution-ன் பாதுகாப்பு அப்டேட்களை நீங்கள் இழக்கிறீர்கள். எப்படியும் நீங்கள் source-ஐப் பதிவிறக்கினால், அதை build செய்வதற்கு முன் அதன் checksum-ஐ சரிபார்க்கவும்.

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

பட்டியலை மாற்ற உங்களுக்கு உண்மையான காரணம் இருந்தால், அதை நீக்கிவிட்டுப் புதியதைச் சேர்ப்பதற்குப் பதிலாக, ஏற்கனவே உள்ளவற்றுடன் சேர்த்துக்கொள்ளுங்கள். OpenSSH ஒரு தொடக்க +-ஐ இணைப்பாகவும் (append), தொடக்க --ஐ நீக்குவதாகவும் (remove), மற்றும் தொடக்க ^-ஐ முன்னால் கொண்டு வருவதாகவும் (move to front) கருதும்.

KexAlgorithms ^mlkem768x25519-sha256

கோப்பை நம்புவதற்கு முன் அதைச் சோதிக்கவும். sudo sshd -t configuration-ஐப் பகுப்பாய்வு செய்யும், அது சரியாக இருந்தால் எதையும் அச்சிடாது. அந்த 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" என்ற சந்தைப்படுத்தல் விளம்பரத்தை ஒரு அடுக்கு (layer) பற்றிய கூற்றாக மட்டும் பார்க்கவும். ஒரு 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 மற்றும் அதற்குப் பிந்தைய பதிப்புகள், பேச்சுவார்த்தையில் 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-ஐ அமைப்பது இந்தச் செய்தியை மறைக்கும், ஆனால் இணைப்பு முன்பு போலவே பலவீனமாகவே இருக்கும்.