Ubuntuలో Post-Quantum SSHలో ఏమి మారింది?

Post-quantum SSHలో ఏమి మారింది

చాలా మంది వినియోగదారుల కోసం post-quantum SSH ఇప్పటికే defaultగా ప్రారంభించబడి ఉంది; దీని కోసం ఎవరూ ప్రత్యేకంగా configure చేయాల్సిన అవసరం లేదు. ప్రస్తుత OpenSSH client, ప్రస్తుత OpenSSH serverతో కనెక్ట్ అయినప్పుడు, defaultగా hybrid post-quantum key exchangeను ఎంచుకుంటుంది. అందువల్ల ప్రస్తుతం మీ network trafficను రికార్డ్ చేసి, అనేక సంవత్సరాల తర్వాత decrypt చేయగల attacker‌కి session keyను ఛేదించడం కష్టమవుతుంది. ఈ protection వాస్తవమే. అయితే "quantum-safe SSH" అనే పదబంధం సూచించేంత విస్తృతమైనది కాదు.

ముందుగా రెండు పదాలను తెలుసుకుందాం. SSH (secure shell) అనేది serverలో login చేయడానికి ఉపయోగించే protocol. Key exchangeను సాధారణంగా "kex" అని రాస్తారు. ప్రతి SSH connectionలో ఇది మొదటి దశ. రెండు endpoints ఒక shared secretపై అంగీకరిస్తాయి. ఆ secret తర్వాత జరిగే మొత్తం communicationను encrypt చేస్తుంది. మారింది key exchange భాగమే. మిగతా ఏదీ మారలేదు.

ఈ పేజీని నమ్మకండి; commands ను మీరే అమలు చేయండి

క్రింద ఉన్న ప్రతి algorithm పేరు మీరు స్వయంగా అమలు చేయగల command నుంచి వచ్చింది. ఇది ఉద్దేశపూర్వకమే. ప్రతి OpenSSH release తో default మారుతుంది. అందువల్ల రెండు సంవత్సరాల క్రితం రాసిన guide లో మీ machine ఇప్పుడు ప్రాధాన్యం ఇవ్వని algorithm పేరు ఉండవచ్చు. ఆ guide కు ఇది తెలిసే మార్గం లేదు. ఈ commands నేర్చుకుంటే, ఈ విషయం గురించి రాసిన articles పై, ఈ article తో సహా, మీరు ఇక ఆధారపడాల్సిన అవసరం ఉండదు.

మీ build కు ఏవి చేయగలవో ముందుగా పరిశీలించండి.

ssh -V
ssh -Q kex

ssh -V, OpenSSH_ తో ప్రారంభమయ్యే version line ను, తరువాత Ubuntu package suffix మరియు OpenSSL version ను ముద్రిస్తుంది. ssh -Q kex ప్రతి key exchange algorithm ను ఒక్కో line లో ముద్రిస్తుంది. post-quantum support ఉన్న build లో ఆ జాబితాలో mlkem768x25519-sha256, sntrup761x25519-sha512@openssh.com వంటి పేర్లు కనిపిస్తాయి. అవి curve25519-sha256 వంటి classical పేర్ల పక్కనే ఉంటాయి.

మీ 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 కోసం ఇదే పని చేస్తుంది. ప్రతి command preference order లో ఒకే kexalgorithms line ను ముద్రిస్తుంది. ఆ line లోని మొదటి పేరు, ఆ వైపు మొదటి ఎంపిక. Network ద్వారా పంపబడేది అదే line.

ఈ తేడా కేవలం సిద్ధాంతం కాదు. 2021-03-03న విడుదలైన OpenSSH 8.5, sntrup761x25519-sha512@openssh.com ను జోడించింది. అయితే దాన్ని default list నుంచి ఉద్దేశపూర్వకంగా మినహాయించింది. ఆ releaseలో ssh -Q kex algorithm ను చూపిస్తుంది, కానీ ssh -G చూపించదు. అంటే binary post-quantum key exchange చేయగలదు, కానీ ఏ connection కూడా దాన్ని ప్రతిపాదించదు.

మీ కనెక్షన్ చర్చించిన algorithm ను చదవండి

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గా standardise చేయబడింది) ను X25519 elliptic curve Diffie-Hellmanతో కలిపి నడుపుతుంది. రెండు outputs ను session keyలో కలుపుతుంది.

పాత serverతో కనెక్ట్ అయినప్పుడు బదులుగా ఇది కనిపించవచ్చు:

debug1: kex: algorithm: curve25519-sha256

ఆ పేరులో post-quantum భాగం లేదు. curve25519-sha256 అనేది స్వతంత్రంగా పనిచేసే elliptic curve Diffie-Hellman. పెద్ద quantum computer దాన్ని విచ్ఛిన్నం చేయగలదు. అందుకే default మార్చబడింది.

ఒక negotiation rule వల్ల ఒక పాత machine మొత్తం sessionను వెనక్కి లాగుతుంది. client తన జాబితాను preference orderలో పంపుతుంది. server తన జాబితాను పంపుతుంది. client జాబితాలో ముందుగా ఉండి, server జాబితాలో కూడా ఉన్న మొదటి పేరే algorithmగా ఎంపిక అవుతుంది. client preferenceకు ప్రాధాన్యం ఉంటుంది. అందువల్ల రెండు endpointsలో పాతదైనది జాబితాలో ఎంతవరకు వెళ్లగలరో నిర్ణయిస్తుంది. ML-KEM గురించి ఎప్పుడూ తెలియని serverకు మీ laptopను upgrade చేయడం వల్ల ఆ session upgrade కాదు.

grep మరియు ssh -v ను తొలగిస్తే negotiationలోని మిగిలిన భాగం కనిపిస్తుంది. అందులో తదుపరి sectionకు సంబంధించిన line కూడా ఉంటుంది:

debug1: kex: host key algorithm: ssh-ed25519

ఏ OpenSSH release hybrid exchange ను default గా చేసింది

Upstream release notes ఈ క్రమాన్ని స్పష్టంగా చూపిస్తాయి. Version numbers కంటే తేదీలు ముఖ్యమైనవి. ఈ విధానం ఎంతకాలంగా నిశ్శబ్దంగా అమలులో ఉందో అవి చూపిస్తాయి.

• 8.5, 2021-03-03న విడుదలైంది. ఇది sntrup761x25519-sha512@openssh.com ను జోడించింది. అయితే దాన్ని default గా disabled గానే ఉంచింది.
• 9.0, 2022-04-08న విడుదలైంది. ఇది దాన్ని enabled చేసింది. OpenSSH "use the hybrid Streamlined NTRU Prime + x25519 key exchange method by default" అని notes లో పేర్కొంది. Post-quantum key exchange సాధారణ default గా మారిన release ఇదే.
• 9.9, 2024-09-19న విడుదలైంది. ఇది రెండో option గా mlkem768x25519-sha256 ను జోడించింది. అదే release పాత method కు IANA registered name అయిన sntrup761x25519-sha512 ను ఇచ్చింది. అందువల్ల కొత్త builds లో అది రెండు పేర్లతో కనిపిస్తుంది.
• 10.0, 2025-04-09న విడుదలైంది. ఇది key agreement కోసం mlkem768x25519-sha256 ను default గా చేసింది.
• 10.1, 2025-10-06న విడుదలైంది. Post-quantum భాగం లేని key exchange ను connection negotiate చేసినప్పుడు client warning ను జోడించింది. ఇది ssh_config లోని WarnWeakCrypto option ద్వారా నియంత్రించబడుతుంది. ఇది default గా enabled గా ఉంటుంది.

గుర్తుంచుకోవాల్సిన తేదీ April 2022. OpenSSH 9.0 లేదా అంతకంటే కొత్త version నడుపుతున్న ఏ రెండు machines అయినా అప్పటి నుంచి post-quantum key exchange ను ఉపయోగిస్తున్నాయి. దీనికి configuration అవసరం లేదు. ssh టైప్ చేస్తున్న వ్యక్తికి ఎలాంటి announcement కూడా కనిపించదు.

ఏ Ubuntu release దీన్ని అందిస్తుంది

Ubuntu ఒక release సమయంలో OpenSSH version ను స్థిరపరుస్తుంది. ఆ version number ను మార్చకుండా security fixes ను backport చేస్తుంది. అందువల్ల మీరు నడుపుతున్న Ubuntu release మీ default algorithm ను నిర్ణయిస్తుంది. జాబితాను నమ్మకుండా, మీ ముందున్న machine ను ssh -V తో పరిశీలించండి. August 2026 నాటికి archive లో ఈ versions ఉన్నాయి:

• 22.04 LTS లో 1:8.9p1 ఉంటుంది. ఇది 9.0 default కు పూర్వం విడుదలైనది. అందువల్ల సాధారణ 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 కాని connections గురించి ఇది హెచ్చరిస్తుంది.

నిజమైన రెండు machines మధ్య ఉదాహరణను పరిశీలించండి. 26.04 laptop, 24.04 server కు connect అవుతుంది. Client యొక్క మొదటి ఎంపిక mlkem768x25519-sha256, కానీ అది 9.6 server జాబితాలో లేదు. Server వద్ద ఉన్న client యొక్క తదుపరి post-quantum ఎంపిక sntrup761x25519-sha512@openssh.com. అదే పేరును ssh -v చూపిస్తుంది. 2024లో నిర్మించిన server కు connect అయినప్పటికీ, ఎవ్వరూ ఏ configuration చేయకుండానే key exchange post-quantum గా జరుగుతుంది.

22.04 సందర్భం దీనికి విరుద్ధంగా ఉంటుంది. ssh -Q kex ఒక్కదానిపై ఆధారపడటం ఎందుకు తప్పుదారి పట్టిస్తుందో ఇది స్పష్టంగా చూపిస్తుంది. OpenSSH 8.9 కు sntrup761x25519-sha512@openssh.com పేరు తెలుసు. అందువల్ల ఆ machine పై ssh -Q kex దాన్ని జాబితాలో చూపిస్తుంది. కానీ default proposal లో అది ఉండదు. కాబట్టి negotiation curve25519-sha256 పై స్థిరపడుతుంది. OpenSSH 10.1 లేదా ఆ తరువాత version ఉన్న client నుంచి connect చేసినప్పుడు ఇది స్పష్టంగా కనిపిస్తుంది:

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

ఆ హెచ్చరిక మీరు connect అవుతున్న server గురించి చెప్పే విషయం. అది మీ client గురించి కాదు. Server ను upgrade చేయడమే పరిష్కారం. WarnWeakCrypto no ను set చేస్తే ఆ message తొలగిపోతుంది, కానీ connection లో ఎలాంటి మార్పు ఉండదు.

హైబ్రిడ్ విధానం ఎందుకు అవసరం, harvest now decrypt later అంటే ఏమిటి

ఈ ముప్పు స్వరూపం స్పష్టంగా ఉంటుంది. మీ network traffic ను చూడగల attacker, మీరు పంపే encrypted bytes ను ఈరోజు రికార్డు చేసి నిల్వ చేస్తాడు. వాటిని ఈరోజు చదవలేడు. X25519 ను ఛేదించగలిగేంత పెద్ద quantum computer అందుబాటులోకి వచ్చే వరకు వాటిని భద్రపరుస్తాడు. తరువాత వాటిని చదువుతాడు. దీనినే harvest now, decrypt later లేదా store now, decrypt later అంటారు. ప్రస్తుతం attacker ఎలాంటి క్లిష్టమైన పద్ధతిని ఉపయోగించాల్సిన అవసరం లేదు. అతనికి disk space మరియు సహనం మాత్రమే అవసరం.

ఈ సమస్య encryption కు ఉంది; signatures కు లేదు. ఈ అసమానత మిగిలిన నిర్ణయాలన్నింటినీ ప్రభావితం చేస్తుంది. ఒక ciphertext లోని data సున్నితంగా ఉన్నంతకాలం, రికార్డు చేసిన ciphertext విలువను కలిగి ఉంటుంది. ఒక signature తనిఖీ చేసే సమయంలో forge చేయలేనిదిగా ఉంటే చాలు. 2035లో signature algorithm ను ఛేదించడం వల్ల ఎవరో 2035లో server వలె నటించగలరు. కానీ వారు 2026లో జరిగిన login ను వెనక్కి వెళ్లి forge చేయలేరు. అందువల్ల ముందుగా key exchange ను సరిచేయాలి; signature భాగాన్ని తరువాత మార్చవచ్చు.

Hybrid అంటే రెండు algorithms అమలవుతాయి, అలాగే వాటి రెండు results session key కు input గా ఉపయోగించబడతాయి. mlkem768x25519-sha256 వెనుక ఉన్న secret ను పొందడానికి attacker, ML-KEM 768 మరియు X25519 రెండింటినీ ఛేదించాలి. ఈ కలయిక ఉద్దేశపూర్వకమైనది. ML-KEM, X25519 కంటే చాలా కొత్తది. Cryptanalysts దాని పై దాడులు చేయడానికి కూడా చాలా తక్కువ సమయం లభించింది. అందువల్ల కొత్త algorithm లో flaw కనుగొనబడినా, ఇప్పటికే మీకు ఉన్న protection కోల్పోరు.

ఏవి రక్షించబడతాయి, ఏవి రక్షించబడవు

Key exchange రక్షించబడుతుంది. మీ session ను encrypt చేసే shared secret hybrid exchange ద్వారా ఏర్పడింది. అందువల్ల ఈ session ను ఈరోజు record చేసినా, భవిష్యత్తులో quantum computers అందుబాటులోకి వచ్చినప్పుడు అది చదవగలిగే విధంగా మారదు.

Host key రక్షించబడదు. debug1: kex: host key algorithm: ssh-ed25519 line ఒక classical signature ను సూచిస్తుంది. rsa-sha2-512 మరియు ECDSA (elliptic curve digital signature algorithm) రకాలు కూడా అదే విధంగా ఉంటాయి. పనిచేసే quantum computer ఉన్న attacker ఆ signature ను forge చేసి మీ server వలె నటించగలడు. అయితే అది భవిష్యత్తులో జరిగే live connection సమయంలో మాత్రమే సాధ్యం. ప్రస్తుతం record చేసిన traffic పై అది ఎప్పటికీ ప్రభావం చూపదు.

మీ login key కూడా రక్షించబడదు. ~/.ssh/id_ed25519 లోని key అదే రకమైన classical signature. అందువల్ల ఇదే కారణం దీనికీ వర్తిస్తుంది. ఈ సంవత్సరం ఆ key ను రక్షించేది అది ఎక్కడ నిల్వ ఉందో, దాన్ని ఎవరు చదవగలరో అన్నదే. కాబట్టి సరైన SSH key నిర్వహణ ఈ పేజీలోని ఏ algorithm పేరు కంటే మీ వాస్తవ ప్రమాదాన్ని మరింతగా తగ్గిస్తుంది.

ఈ రెండింటి విషయంలో మీరు చేయాల్సింది ఏమీ లేదు. ఎందుకంటే ప్రస్తుతం మారడానికి వేరే ఎంపిక లేదు. భవిష్యత్తు release లో post-quantum signature support వస్తుందని OpenSSH తెలిపింది. అది విడుదలయ్యే వరకు OpenSSH లో post-quantum host key type లేదా post-quantum user key type ఉండదు. ssh-keygen కూడా మీకు అలాంటి ఎంపికను అందించదు. ఒకటి generate చేయమని చెప్పే guide, ఇంకా ఉనికిలోకి రాని software గురించి వివరిస్తోంది.

అదే server పై TLS ఒక ప్రత్యేక ప్రశ్న. దానికి సమాధానం కూడా వేరు. TLS (transport layer security) మీ web server port 443 పై ఉపయోగించే protocol. ఇది వేరే codebase, వేరే schedule పై అభివృద్ధి చెందుతుంది. OpenSSH ను upgrade చేయడం వల్ల TLS పై ఎలాంటి మార్పు ఉండదు. అదే VPS పై private service కోసం self-signed certificate ఉపయోగిస్తుంటే, దాని signature మరియు key exchange ను OpenSSL, మీ web server నిర్ణయిస్తాయి. కాబట్టి ఆ stack ను దాని స్వంత పరంగా పరిశీలించాలి.

ఇప్పుడు ఒక బాధ్యతగల ఆపరేటర్ చేయాల్సింది

OpenSSH ను ప్రస్తుత స్థితిలో ఉంచండి. అంతటితో ఆపండి. ఈ సమస్యకు వాస్తవంగా ఇదే పూర్తి వ్యూహం. sudo apt update && sudo apt upgrade మీ Ubuntu release అందించే version లోనే ఉంచుతుంది. కొత్త OpenSSH పొందాలంటే కొత్త Ubuntu release కు మారాలి. unattended security upgrades ను ప్రారంభిస్తే, మీరు గుర్తుంచుకోకుండానే ఆ patches అమలవుతాయి. Algorithm name కోసం OpenSSH ను source నుంచి build చేయడం సరైన మార్పిడి కాదు. అలా చేస్తే system లో అత్యంత బహిర్గతమైన service కు distribution అందించే security updates ను కోల్పోతారు. అయినప్పటికీ source ను download చేస్తే, build చేయడానికి ముందు download ను ప్రచురించిన checksum తో సరిపోల్చండి.

KexAlgorithms line ను చేతితో రాయవద్దు. పరిస్థితిని నమ్మదగిన విధంగా మరింత దిగజార్చే చర్య ఇదే. 2018లోని hardening guide, 2018లో సరైన list ను ఇస్తుంది. దాన్ని sshd_config లో paste చేస్తే, default list కు జోడించదు; దాని స్థానంలో కొత్త list ను ఉంచుతుంది. అప్పటి నుంచి ప్రవేశించిన ప్రతి algorithm ఇప్పుడు మినహాయించబడుతుంది. అందువల్ల స్వయంగా mlkem768x25519-sha256 ను negotiate చేయగల server, pinned list లో మిగిలిన algorithm కు నిశ్శబ్దంగా దిగజారుతుంది. మీరు వారసత్వంగా పొందిన ఏ server పైనైనా sudo sshd -T | grep -i '^kexalgorithms' ను run చేయండి. అదే release యొక్క fresh install లో ఉన్న line కంటే ఆ line చిన్నగా ఉంటే, ఎవరో దానికి pin చేశారు.

List ను మార్చడానికి మీకు నిజమైన కారణం ఉంటే, దాన్ని భర్తీ చేయకుండా జోడించండి. OpenSSH ప్రారంభంలో ఉన్న + ను append గా, ప్రారంభంలో ఉన్న - ను remove గా, ప్రారంభంలో ఉన్న ^ ను front కు move గా అర్థం చేసుకుంటుంది.

KexAlgorithms ^mlkem768x25519-sha256

దానిపై ఆధారపడే ముందు file ను test చేయండి. sudo sshd -t configuration ను parse చేస్తుంది. అది valid అయితే ఏమీ print చేయదు. Build లో లేని algorithm పేరున్న KexAlgorithms line, sshd ప్రారంభం కాకుండా ఆపుతుంది. Remote box లో దీనివల్ల మళ్లీ login చేయలేరు. అందువల్ల పని చేస్తున్నప్పుడు రెండో session ను తెరిచి ఉంచండి. రెండు వైపుల lists లో ఇక common algorithm లేకపోతే, 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" అనే marketing పదాన్ని ఒక layer కు సంబంధించిన claim గా చూడండి. ఒక vendor product ను quantum-safe అని పిలిస్తే, వారు పేరు చెప్పిన layer ను మాత్రమే వివరిస్తున్నారు. ఆ layer సాధారణంగా ఎక్కడో ఉన్న key exchange అవుతుంది. Algorithm name మరియు అది వర్తించే protocol ను అడగండి. August 2026 నాటికి OpenSSH విషయంలో ఈ claim ను నిజాయితీగా చెప్పాలంటే, key exchange hybrid post-quantum గా ఉంటుంది. Signatures మాత్రం classical గా ఉంటాయి. దీనికంటే విస్తృతమైన ఏ claim అయినా, మీరు ssh -Q kex output లో కనుగొనగల పేరు తో రావాలి.

సాధారణమైన ముఖ్యమైన పనులను కొనసాగించండి. Post-quantum key exchange guess చేయగల password సమస్యను పరిష్కరించదు. తరువాత దొంగిలించబడిన laptop లో private key copy ఉండటం వల్ల కలిగే ప్రమాదాన్నీ అది పరిష్కరించదు. Server లను వాస్తవంగా స్వాధీనం చేసుకునే కారణాలు ఇవే. VPS పై standard SSH hardening ఇప్పటికీ దాదాపు మొత్తం రక్షణను అందిస్తుంది. ఇక్కడి negotiation దశలు మీకు కొత్తగా ఉంటే, మీరు connect చేసినప్పుడు SSH చేసే పని ఈ పేజీ ముందుగా తెలిసి ఉండాలని భావించే దశలను వివరిస్తుంది.

FAQ

నా SSH connection ఇప్పటికే post-quantum గా ఉందా?

ssh -v yourserver 2>&1 | grep 'kex: algorithm' ను అమలు చేసి, అది ముద్రించే పేరును చదవండి. mlkem768x25519-sha256 మరియు sntrup761x25519-sha512@openssh.com hybrid post-quantum exchanges. curve25519-sha256, ecdh-sha2-nistp256 మరియు ఏదైనా diffie-hellman-group పేరు classical exchanges. రెండు వైపులా post-quantum పేరును అందించే version ఉండాలి. ఎందుకంటే negotiation సమయంలో client ఎంచుకున్న మొదటి ఎంపికను server కూడా support చేస్తే అదే ఎంపిక అవుతుంది. అందువల్ల పాత machine పరిమితిని నిర్ణయిస్తుంది.

ఏ OpenSSH release లో post-quantum key exchange default అయింది?

2022-04-08న విడుదలైన OpenSSH 9.0లో sntrup761x25519-sha512@openssh.com default key exchange అయింది. 2024-09-19న విడుదలైన OpenSSH 9.9లో mlkem768x25519-sha256 జోడించబడింది. 2025-04-09న విడుదలైన OpenSSH 10.0లో అది default అయింది. 2025-10-06న విడుదలైన OpenSSH 10.1లో connection ఏదీ negotiate చేయనప్పుడు warning చూపించడం ప్రారంభమైంది. మీ Ubuntu release లో వీటిలో ఏవి ఉన్నాయో నిర్ణయిస్తుంది కాబట్టి, మీ స్వంత build ఏమి చేస్తుందో ssh -Q kex మరియు ssh -G <host> తో పరిశీలించండి.

నేను post-quantum SSH key ని generate చేయాలా?

వద్దు. ఎందుకంటే OpenSSHలో అలాంటి key type లేదు. ఇప్పటివరకు post-quantum మార్పులు key exchange వరకు మాత్రమే ఉన్నాయి. దీనికి మీ key files లేదా ఎలాంటి configuration అవసరం లేదు. Host keys మరియు login keys ఇప్పటికీ Ed25519, RSA వంటి classical signatures గానే ఉన్నాయి. Post-quantum signatures భవిష్యత్ releaseలో వస్తాయని upstream తెలిపింది. Ed25519 keyనే ఉపయోగిస్తూ, అది ఎక్కడ నిల్వ చేయబడిందో సురక్షితంగా ఉంచండి.

నా connection post-quantum కాదు అని ssh ఎందుకు warning చూపిస్తుంది?

OpenSSH 10.1 మరియు తదుపరి versionsలో, negotiated exchangeలో post-quantum భాగం లేకపోతే ** WARNING: connection is not using a post-quantum key exchange algorithm. ను ముద్రిస్తాయి. ఈ warning server గురించి ఉంటుంది, మీ client గురించి కాదు. మీ client post-quantum పేరును అందించింది, కానీ server వాటిలో ఏదీ అంగీకరించలేదు. Serverలోని OpenSSHను upgrade చేయండి. లేదా దాని sshd_config లో ఆధునిక పేర్లను మినహాయించే KexAlgorithms line ను ఎవరూ నిర్దిష్టంగా అమర్చలేదో పరిశీలించండి. WarnWeakCrypto no ను సెట్ చేస్తే message దాచబడుతుంది. అయితే connection ఉన్న బలహీనతలో ఎలాంటి మార్పు ఉండదు.