Ubuntuలో Post-quantum SSH ఎలా పనిచేస్తుంది?

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

చాలామందికి Post-quantum SSH ఇప్పటికే ఆన్ చేయబడింది, దీని కోసం ఎవరూ ప్రత్యేకంగా కాన్ఫిగర్ చేయాల్సిన అవసరం లేదు. ప్రస్తుత OpenSSH క్లయింట్, ప్రస్తుత OpenSSH సర్వర్‌తో కనెక్ట్ అయినప్పుడు, డిఫాల్ట్‌గా హైబ్రిడ్ post-quantum key exchange ను ఎంచుకుంటుంది. దీనివల్ల, ఎవరైనా మీ ట్రాఫిక్‌ను ఈరోజు రికార్డ్ చేసి, భవిష్యత్తులో డీక్రిప్ట్ చేయడానికి ప్రయత్నించినా, ఆ సెషన్ కీ సురక్షితంగా ఉంటుంది. ఈ రక్షణ వాస్తవమైనది, అయితే "quantum-safe SSH" అనే పదం సూచించే దానికంటే ఇది పరిమితమైనది.

ముందుగా రెండు పదాలను అర్థం చేసుకుందాం. SSH (secure shell) అనేది మీరు సర్వర్‌లోకి లాగిన్ అవ్వడానికి ఉపయోగించే ప్రోటోకాల్. Key exchange, దీనిని సాధారణంగా "kex" అని పిలుస్తారు, ఇది ప్రతి SSH కనెక్షన్‌లో మొదటి దశ: రెండు చివరలు ఒక shared secret పై అంగీకారానికి వస్తాయి, ఆ రహస్య కీ తర్వాత జరిగే ప్రతి కమ్యూనికేషన్‌ను ఎన్‌క్రిప్ట్ చేస్తుంది. Key exchange మాత్రమే మారింది. మిగిలినవేవీ మారలేదు.

ఈ పేజీని గుడ్డిగా నమ్మకండి, కమాండ్లను మీరే రన్ చేయండి

కింద ఉన్న ప్రతి అల్గారిథమ్ పేరును మీరు స్వయంగా రన్ చేయగల కమాండ్ ద్వారా పొందవచ్చు. ఇది ఉద్దేశపూర్వకంగానే చేయబడింది. ప్రతి OpenSSH విడుదలతో డిఫాల్ట్ సెట్టింగ్‌లు మారుతుంటాయి. కాబట్టి, రెండేళ్ల క్రితం రాసిన గైడ్‌లో ఉన్న అల్గారిథమ్ మీ మెషీన్‌లో ఇప్పుడు పని చేయకపోవచ్చు, ఆ విషయాన్ని ఆ గైడ్ మీకు చెప్పలేదు. ఈ కమాండ్లను నేర్చుకుంటే, ఇలాంటి వ్యాసాల అవసరం మీకు ఉండదు, ఈ వ్యాసంతో సహా.

మీ సిస్టమ్‌కు ఏవి తెలుసో వాటితో ప్రారంభించండి.

ssh -V
ssh -Q kex

ssh -V అనేది OpenSSH_ తో మొదలై, ఆ తర్వాత Ubuntu ప్యాకేజీ సఫిక్స్ మరియు OpenSSL వెర్షన్‌ను చూపే ఒక వెర్షన్ లైన్‌ను ప్రింట్ చేస్తుంది. ssh -Q kex ప్రతి కీ ఎక్స్ఛేంజ్ అల్గారిథమ్‌ను ఒక్కో లైన్‌లో ప్రింట్ చేస్తుంది. పోస్ట్-క్వాంటం సపోర్ట్ ఉన్న బిల్డ్‌లో, మీరు mlkem768x25519-sha256 మరియు sntrup761x25519-sha512@openssh.com వంటి పేర్లను ఆ జాబితాలో చూడవచ్చు, ఇవి curve25519-sha256 వంటి సాంప్రదాయ పేర్ల పక్కనే ఉంటాయి.

మీ బిల్డ్ దేనికి మద్దతు ఇస్తుంది మరియు అది దేనిని ఆఫర్ చేస్తుంది అనేవి వేరు

చాలా పోస్ట్‌లు విస్మరించే వ్యత్యాసం ఇదే. ssh -Q kex ఒక ప్రశ్నకు సమాధానమిస్తుంది: ఈ బైనరీ ఏమి చేయగలదు. మీరు ఆందోళన చెందే ప్రశ్నకు ఇది సమాధానం ఇవ్వదు: ఈ కనెక్షన్ వాస్తవానికి దేనిని ప్రతిపాదిస్తుంది. ఈ రెండు జాబితాలు భిన్నమైనవి, మరియు వాటి మధ్య ఉన్న వ్యత్యాసమే పాత సలహాలు నిజమైన నష్టాన్ని కలిగించే చోటు.

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

ssh -G <host> ఆ హోస్ట్ కోసం క్లయింట్ యొక్క ప్రభావవంతమైన కాన్ఫిగరేషన్‌ను ముద్రిస్తుంది, ఇది ~/.ssh/config మరియు /etc/ssh/ssh_config వర్తింపజేసిన తర్వాత వస్తుంది. sshd -T సర్వర్ కోసం కూడా అదే పని చేస్తుంది. ప్రతి ఒక్కటి ప్రాధాన్యత క్రమంలో ఒకే kexalgorithms లైన్‌ను ముద్రిస్తాయి, మరియు దానిపై ఉన్న మొదటి పేరు ఆ వైపు యొక్క మొదటి ఎంపిక. ఆ లైన్ మాత్రమే నెట్‌వర్క్ ద్వారా ప్రసారం అవుతుంది.

ఈ వ్యత్యాసం కేవలం సిద్ధాంతపరమైనది కాదు. 2021-03-03న విడుదలైన OpenSSH 8.5, sntrup761x25519-sha512@openssh.com ని జోడించింది మరియు దానిని డిఫాల్ట్ జాబితా నుండి ఉద్దేశపూర్వకంగా మినహాయించింది. ఆ విడుదలపై ssh -Q kex ఆ అల్గారిథమ్‌ను చూపుతుంది మరియు ssh -G చూపదు, అంటే ఆ బైనరీ పోస్ట్-క్వాంటం కీ ఎక్స్ఛేంజ్ చేయగలదు, కానీ ఏ కనెక్షన్ కూడా దానిని అడగదు.

మీ కనెక్షన్ ఏ అల్గారిథమ్‌ను చర్చించుకుందో చదవండి

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

ప్రస్తుత క్లయింట్ మరియు సర్వర్ మధ్య, ఇది ఇలా ముద్రిస్తుంది:

debug1: kex: algorithm: mlkem768x25519-sha256

mlkem768x25519-sha256 అనేది ఒక హైబ్రిడ్ పద్ధతి. ఇది 768 పారామీటర్ సెట్‌తో ML-KEM (module-lattice key encapsulation mechanism, FIPS 203గా ప్రామాణీకరించబడింది) ను, X25519 ఎలిప్టిక్ కర్వ్ Diffie-Hellman తో కలిపి నడుపుతుంది మరియు ఈ రెండింటి ఫలితాలను కలిపి సెషన్ కీని రూపొందిస్తుంది.

పాత సర్వర్‌తో కనెక్ట్ అయినప్పుడు మీకు దీనికి బదులుగా ఇలా కనిపించవచ్చు:

debug1: kex: algorithm: curve25519-sha256

ఆ పేరులో పోస్ట్-క్వాంటం భాగం ఉండదు. curve25519-sha256 అనేది కేవలం ఎలిప్టిక్ కర్వ్ Diffie-Hellman మాత్రమే, దీనిని ఒక పెద్ద క్వాంటం కంప్యూటర్ విచ్ఛిన్నం చేయగలదు. డిఫాల్ట్ సెట్టింగ్‌ను మార్చడానికి ఇదే ప్రధాన కారణం.

ఒక పాత మెషిన్ సెషన్‌ను ఎలా వెనక్కి లాగుతుందో ఒక నెగోషియేషన్ నియమం వివరిస్తుంది. క్లయింట్ తన జాబితాను ప్రాధాన్యత క్రమంలో పంపుతుంది, సర్వర్ తన స్వంత జాబితాను పంపుతుంది. సర్వర్ జాబితాలో కూడా ఉన్న క్లయింట్ జాబితాలోని మొదటి పేరును అల్గారిథమ్‌గా ఎంచుకుంటారు. క్లయింట్ యొక్క ప్రాధాన్యత నెగ్గుతుంది, కాబట్టి రెండు చివరలలో ఏది పాతదైతే అదే జాబితాలో ఎంతవరకు వెళ్లాలో నిర్ణయిస్తుంది. ML-KEM గురించి తెలియని సర్వర్‌కు మీ ల్యాప్‌టాప్‌ను అప్‌గ్రేడ్ చేయడం వల్ల సెషన్ అప్‌గ్రేడ్ అవ్వదు.

ssh -v గురించి ఈ ఒక్క లైన్ కంటే ఎక్కువ తెలుసుకోవడం మంచిది, ఎందుకంటే లాగిన్ పూర్తిగా తిరస్కరించబడినప్పుడు Permission denied (publickey) వైఫల్యాన్ని గుర్తించడానికి ఇదే అవుట్‌పుట్ ఉపయోగపడుతుంది.

grep మరియు ssh -v ను తీసివేస్తే, నెగోషియేషన్ యొక్క మిగిలిన వివరాలు కనిపిస్తాయి, ఇందులో తదుపరి విభాగంలో చర్చించబోయే లైన్ కూడా ఉంటుంది:

debug1: kex: host key algorithm: ssh-ed25519

ఏ OpenSSH విడుదల హైబ్రిడ్ ఎక్స్ఛేంజ్‌ను డిఫాల్ట్‌గా మార్చింది

అప్‌స్ట్రీమ్ విడుదల నోట్స్ స్పష్టమైన క్రమాన్ని తెలియజేస్తాయి. వెర్షన్ నంబర్ల కంటే తేదీలు ముఖ్యమైనవి, ఎందుకంటే ఇవి ఎంత కాలంగా ఇది నిశ్శబ్దంగా నడుస్తుందో చూపిస్తాయి.

• 8.5, 2021-03-03న విడుదలైనది, sntrup761x25519-sha512@openssh.comని జోడించింది మరియు డిఫాల్ట్‌గా దీనిని డిసేబుల్ చేసింది.
• 9.0, 2022-04-08న విడుదలైనది, దీనిని ఆన్ చేసింది. OpenSSH "డిఫాల్ట్‌గా హైబ్రిడ్ Streamlined NTRU Prime + x25519 కీ ఎక్స్ఛేంజ్ పద్ధతిని ఉపయోగిస్తుంది" అని నోట్స్ పేర్కొన్నాయి. పోస్ట్-క్వాంటం కీ ఎక్స్ఛేంజ్ సాధారణ విషయంగా మారిన విడుదల ఇదే.
• 9.9, 2024-09-19న విడుదలైనది, mlkem768x25519-sha256ని రెండవ ఎంపికగా జోడించింది. ఇదే విడుదల పాత పద్ధతికి దాని IANA రిజిస్టర్డ్ పేరును, sntrup761x25519-sha512ని ఇచ్చింది, కాబట్టి కొత్త బిల్డ్‌లు దీనిని రెండు పేర్లతో జాబితా చేస్తాయి.
• 10.0, 2025-04-09న విడుదలైనది, mlkem768x25519-sha256ని కీ అగ్రిమెంట్ కోసం డిఫాల్ట్‌గా మార్చింది.
• 10.1, 2025-10-06న విడుదలైనది, కనెక్షన్ పోస్ట్-క్వాంటం హాఫ్ లేకుండా కీ ఎక్స్ఛేంజ్‌ను నెగోషియేట్ చేసినప్పుడు క్లయింట్ హెచ్చరికను జోడించింది. ఇది ssh_configలోని WarnWeakCrypto ఆప్షన్ ద్వారా నియంత్రించబడుతుంది మరియు డిఫాల్ట్‌గా ఆన్‌లో ఉంటుంది.

ఏప్రిల్ 2022 గుర్తుంచుకోవాల్సిన తేదీ. OpenSSH 9.0 లేదా అంతకంటే కొత్త వెర్షన్ నడుపుతున్న ఏ రెండు మెషీన్లు అయినా అప్పటి నుండి పోస్ట్-క్వాంటం కీ ఎక్స్ఛేంజ్‌ను చేస్తున్నాయి, దీని కోసం ఎటువంటి కాన్ఫిగరేషన్ అవసరం లేదు మరియు ssh టైప్ చేసే వ్యక్తికి ఎటువంటి ప్రకటన కూడా ఉండదు.

ఏ Ubuntu release దీనిని కలిగి ఉంటుంది

Ubuntu ఒక release సమయంలో OpenSSH వెర్షన్‌ను స్థిరీకరించి, వెర్షన్ నంబర్‌ను మార్చకుండానే భద్రతాపరమైన సవరణలను (security fixes) backport చేస్తుంది. కాబట్టి, మీరు వాడుతున్న Ubuntu release మీ డిఫాల్ట్ అల్గారిథమ్‌ను నిర్ణయిస్తుంది. ఏదైనా జాబితాను నమ్మే బదులు, మీ ముందున్న మెషీన్‌లో ssh -V కమాండ్‌తో తనిఖీ చేయండి. ఆగస్టు 2026 నాటికి, ఆర్కైవ్‌లో ఈ క్రింది వెర్షన్లు ఉన్నాయి:

• 22.04 LTS లో 1:8.9p1 ఉంటుంది, ఇది 9.0 డిఫాల్ట్ కంటే పాతది, కాబట్టి సాధారణ ఇన్‌స్టాలేషన్ curve25519-sha256 ను నెగోషియేట్ చేస్తుంది.
• 24.04 LTS లో 1:9.6p1 ఉంటుంది, ఇది 9.0 తర్వాత మరియు 9.9 కంటే ముందు వెర్షన్, కాబట్టి దీని డిఫాల్ట్ sntrup761x25519-sha512@openssh.com మరియు ఇందులో ML-KEM ఉండదు.
• 25.10 లో 1:10.0p1 ఉంటుంది, దీని డిఫాల్ట్ mlkem768x25519-sha256.
• 26.04 LTS లో 1:10.2p1 ఉంటుంది, ఇది డిఫాల్ట్‌గా mlkem768x25519-sha256 ను ఉపయోగిస్తుంది మరియు పోస్ట్-క్వాంటం కాని కనెక్షన్‌ల గురించి హెచ్చరిస్తుంది.

వాస్తవమైన రెండు మెషీన్ల జంటతో ప్రయత్నించండి. ఒక 26.04 ల్యాప్‌టాప్ 24.04 సర్వర్‌కు కనెక్ట్ అవుతుంది అనుకుందాం. క్లయింట్ యొక్క మొదటి ఎంపిక అయిన mlkem768x25519-sha256, 9.6 సర్వర్ జాబితాలో ఉండదు. సర్వర్‌లో అందుబాటులో ఉన్న క్లయింట్ యొక్క తదుపరి పోస్ట్-క్వాంటం ఎంపిక sntrup761x25519-sha512@openssh.com, మరియు ssh -v రిపోర్ట్ చేసే పేరు ఇదే. ఎటువంటి కాన్ఫిగరేషన్ చేయకపోయినా, 2024లో నిర్మించిన సర్వర్‌తో ఈ సెషన్ కీ ఎక్స్ఛేంజ్ విషయంలో పోస్ట్-క్వాంటం పద్ధతిలో ఉంటుంది.

22.04 విషయంలో ఇది భిన్నంగా ఉంటుంది, మరియు ssh -Q kex మాత్రమే ఎందుకు తప్పుదారి పట్టిస్తుందో ఇది చూపిస్తుంది. OpenSSH 8.9 కు sntrup761x25519-sha512@openssh.com పేరు తెలుసు, కాబట్టి ఆ బాక్సులో ssh -Q kex దానిని చూపిస్తుంది, కానీ డిఫాల్ట్ ప్రతిపాదనలో అది ఉండదు, కాబట్టి నెగోషియేషన్ curve25519-sha256 వద్ద స్థిరపడుతుంది. OpenSSH 10.1 లేదా అంతకంటే కొత్త క్లయింట్ నుండి కనెక్ట్ అయినప్పుడు, కనెక్షన్ ఇలా చెబుతుంది:

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

ఆ హెచ్చరిక మీరు చేరుకుంటున్న సర్వర్ గురించి, మీ క్లయింట్ గురించి కాదు. దీనికి పరిష్కారం సర్వర్‌ను అప్‌గ్రేడ్ చేయడం. WarnWeakCrypto no సెట్ చేయడం వల్ల ఆ సందేశం తొలగిపోతుంది కానీ కనెక్షన్‌లో ఎటువంటి మార్పు ఉండదు.

హైబ్రిడ్ ఎందుకు, మరియు harvest now decrypt later అంటే ఏమిటి

ఈ ముప్పు చాలా స్పష్టంగా ఉంటుంది. మీ నెట్‌వర్క్ ట్రాఫిక్‌ను గమనించే ఒక దాడి చేసే వ్యక్తి (attacker), ప్రస్తుతం ఎన్‌క్రిప్ట్ చేయబడిన బైట్‌లను రికార్డ్ చేసి భద్రపరుచుకుంటాడు. ప్రస్తుతానికి వాటిని చదవడం అతనికి సాధ్యం కాదు. X25519 ను ఛేదించగల సామర్థ్యం ఉన్న క్వాంటం కంప్యూటర్ అందుబాటులోకి వచ్చే వరకు అతను వాటిని దాచి ఉంచుతాడు, ఆ తర్వాత వాటిని డీక్రిప్ట్ చేస్తాడు. దీనినే harvest now, decrypt later లేదా store now, decrypt later అని పిలుస్తారు. దీనికి దాడి చేసే వ్యక్తి ప్రస్తుత సమయంలో ఎటువంటి తెలివైన పని చేయాల్సిన అవసరం లేదు. అతనికి కావలసింది కేవలం డిస్క్ స్పేస్ మరియు ఓపిక మాత్రమే.

ఎన్‌క్రిప్షన్ విషయంలో ఈ సమస్య ఉంది, కానీ డిజిటల్ సిగ్నేచర్ల విషయంలో లేదు. ఈ అసమానతే మిగిలిన అన్ని అంశాలను ప్రభావితం చేస్తుంది. రికార్డ్ చేయబడిన సైఫర్‌టెక్స్ట్ (ciphertext) లోని సమాచారం ఎంతకాలం సున్నితమైనదిగా ఉంటుందో, అంతకాలం ఆ రికార్డింగ్ విలువ అలాగే ఉంటుంది. ఒక సిగ్నేచర్ అనేది అది తనిఖీ చేయబడిన సమయంలో మాత్రమే ఫోర్జరీ చేయలేనిదిగా ఉండాలి. 2035లో ఒక సిగ్నేచర్ అల్గారిథమ్‌ను ఛేదించడం వల్ల, 2035లో ఒక సర్వర్‌ను ఎవరైనా అనుకరించవచ్చు. కానీ, దానివల్ల వారు వెనక్కి వెళ్లి 2026 నాటి లాగిన్‌ను ఫోర్జరీ చేయలేరు. అందుకే కీ ఎక్స్ఛేంజ్ (key exchange) విధానాన్ని ముందుగా సరిచేయాల్సి వచ్చింది, సిగ్నేచర్ అంశాన్ని తర్వాత చూసుకోవచ్చు.

హైబ్రిడ్ అంటే రెండు అల్గారిథమ్‌లు పనిచేసి, వాటి ఫలితాలు రెండూ కలిసి సెషన్ కీని రూపొందిస్తాయి. mlkem768x25519-sha256 వెనుక ఉన్న రహస్యాన్ని తిరిగి పొందాలంటే, దాడి చేసే వ్యక్తి ML-KEM 768 మరియు X25519 రెండింటినీ ఛేదించాలి. ఈ జత చేయడం ఉద్దేశపూర్వకంగానే జరిగింది: ML-KEM అనేది X25519 కంటే చాలా కొత్తది మరియు క్రిప్టానలిస్టుల నుండి దీనికి తక్కువ కాలమే పరీక్షలు ఎదురయ్యాయి. కాబట్టి, కొత్త అల్గారిథమ్‌లో ఏదైనా లోపం దొరికినా, మీకు ఇప్పటికే ఉన్న రక్షణ కవచం దెబ్బతినదు.

ఏది సురక్షితం, ఏది కాదు

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 ఉంటే, వారు ఆ signature ను ఫోర్జరీ చేసి మీ సర్వర్‌లా నటించగలరు. అయితే ఇది భవిష్యత్తులో live connection ఉన్నప్పుడు మాత్రమే సాధ్యం, ప్రస్తుతం రికార్డ్ చేసిన traffic పై ఇది పనిచేయదు.

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

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

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

తెలివైన ఆపరేటర్ ఇప్పుడు ఏమి చేయాలి

OpenSSH ను ఎప్పటికప్పుడు అప్‌డేట్‌గా ఉంచండి, అంతటితో ఆగిపోండి. ఈ సమస్యకు ఇదే పూర్తి వ్యూహం. sudo apt update && sudo apt upgrade మిమ్మల్ని మీ Ubuntu రిలీజ్ అందించే వెర్షన్‌లోనే ఉంచుతుంది, మరియు కొత్త Ubuntu రిలీజ్‌కు మారడం ద్వారానే మీరు కొత్త OpenSSH వెర్షన్‌కు చేరుకుంటారు. unattended security upgrades ను ఆన్ చేయడం ద్వారా, మీరు గుర్తుంచుకోవాల్సిన అవసరం లేకుండానే ఆ ప్యాచెస్ అప్లై అవుతాయి. కేవలం ఒక అల్గారిథమ్ పేరు కోసం OpenSSH ను సోర్స్ నుండి బిల్డ్ చేయడం సరైన పద్ధతి కాదు, ఎందుకంటే అలా చేయడం వల్ల సర్వర్‌లోని అత్యంత ప్రమాదకరమైన సేవకు అందాల్సిన డిస్ట్రిబ్యూషన్ సెక్యూరిటీ అప్‌డేట్‌లను మీరు కోల్పోతారు. ఒకవేళ మీరు సోర్స్‌ను డౌన్‌లోడ్ చేసినా, బిల్డ్ చేసే ముందు దాని పబ్లిష్ చేసిన చెక్‌సమ్‌తో డౌన్‌లోడ్‌ను సరిచూసుకోండి.

KexAlgorithms లైన్‌ను సొంతంగా రాయకండి. ఇది పరిస్థితిని ఖచ్చితంగా దిగజార్చే ఒకే ఒక్క పని. 2018 నాటి ఒక హార్డెనింగ్ గైడ్ ఆ సమయంలో సరైనదైన జాబితాను ఇస్తుంది, దానిని కాపీ చేసి sshd_config లో పేస్ట్ చేస్తే, అది డిఫాల్ట్ జాబితాకు అదనంగా చేరడానికి బదులుగా దానిని పూర్తిగా భర్తీ చేస్తుంది. అప్పటి నుండి కనిపెట్టిన ప్రతి అల్గారిథమ్ ఇప్పుడు మినహాయించబడుతుంది, కాబట్టి సాధారణంగా mlkem768x25519-sha256 ను నెగోషియేట్ చేయగల సర్వర్, పిన్ చేసిన జాబితాలో మిగిలి ఉన్న వాటికి మాత్రమే పరిమితమవుతుంది. మీరు బాధ్యత తీసుకున్న ఏదైనా సర్వర్‌లో sudo sshd -T | grep -i '^kexalgorithms' ను రన్ చేయండి. ఒకవేళ ఆ లైన్, అదే రిలీజ్ ఉన్న కొత్త ఇన్‌స్టాల్‌లోని లైన్ కంటే చిన్నదిగా ఉంటే, ఎవరో దానిని పిన్ చేశారని అర్థం.

ఒకవేళ జాబితాను మార్చడానికి మీకు బలమైన కారణం ఉంటే, దానిని భర్తీ చేయడానికి బదులుగా దానికి అదనంగా చేర్చండి. OpenSSH ప్రారంభంలో ఉన్న + ను అపెండ్ (append) గా, - ను తొలగింపు (remove) గా, మరియు ^ ను ముందు వరుసలోకి మార్చడం (move to front) గా పరిగణిస్తుంది.

KexAlgorithms ^mlkem768x25519-sha256

ఫైల్‌పై ఆధారపడే ముందు దానిని పరీక్షించండి. sudo sshd -t కాన్ఫిగరేషన్‌ను పార్స్ చేస్తుంది మరియు అది సరైనదిగా ఉన్నప్పుడు ఏమీ ప్రింట్ చేయదు. బిల్డ్‌లో లేని అల్గారిథమ్ పేరుతో ఉన్న KexAlgorithms లైన్ sshd ప్రారంభం కాకుండా ఆపుతుంది. రిమోట్ బాక్స్‌లో అయితే మీరు తిరిగి లాగిన్ అవ్వలేరు, కాబట్టి మీరు పని చేస్తున్నప్పుడు రెండవ సెషన్‌ను ఓపెన్ చేసి ఉంచండి. రెండు వైపులా ఉన్న జాబితాలు సరిపోలడం ఆగిపోయినప్పుడు, క్లయింట్ స్పష్టంగా ఇలా చెబుతుంది:

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) గురించి చేసిన క్లెయిమ్‌గా చదవండి. ఒక వెండర్ తన ఉత్పత్తిని క్వాంటం-సేఫ్ అని పిలుస్తున్నారంటే, వారు పేర్కొన్న ఆ నిర్దిష్ట పొర గురించి మాత్రమే చెబుతున్నారని అర్థం, ఆ పొర సాధారణంగా ఏదో ఒక కీ ఎక్స్ఛేంజ్ (key exchange) అయి ఉంటుంది. అల్గారిథమ్ పేరు మరియు అది ఏ ప్రోటోకాల్‌కు వర్తిస్తుందో అడగండి. ఆగస్టు 2026 నాటికి OpenSSH కోసం నిజాయితీ గల క్లెయిమ్ ఏమిటంటే, కీ ఎక్స్ఛేంజ్ హైబ్రిడ్ పోస్ట్-క్వాంటం పద్ధతిలో ఉంటుంది, అయితే సిగ్నేచర్లు క్లాసికల్‌గా ఉంటాయి. అంతకంటే విస్తృతమైన ఏదైనా ఉంటే, అది ssh -Q kex అవుట్‌పుట్‌లో మీరు కనుగొనగలిగే పేరుతో రావాలి.

బోరింగ్ పనులను చేస్తూనే ఉండండి. పోస్ట్-క్వాంటం కీ ఎక్స్ఛేంజ్ అనేది ఊహించదగిన పాస్‌వర్డ్ లేదా దొంగిలించబడిన ల్యాప్‌టాప్‌లో కాపీ చేసిన ప్రైవేట్ కీ విషయంలో ఏమీ చేయలేదు. సర్వర్లు వాస్తవానికి వీటి వల్లే హ్యాక్ అవుతాయి, మరియు VPS పై ప్రామాణిక SSH హార్డెనింగ్ ఇప్పటికీ దాదాపు అన్ని రక్షణలను అందిస్తుంది. ఇక్కడ ఉన్న నెగోషియేషన్ దశలు మీకు తెలియకపోతే, మీరు కనెక్ట్ అయినప్పుడు SSH ఏమి చేస్తుంది అనే అంశం ఈ పేజీలో ఊహించిన దశలను వివరిస్తుంది.

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 పేరు క్లాసికల్ పద్ధతికి చెందినవి. కనెక్షన్ యొక్క రెండు చివరలా post-quantum పేరును సపోర్ట్ చేసే వెర్షన్ ఉండాలి. ఎందుకంటే, నెగోషియేషన్ ప్రక్రియలో సర్వర్ మరియు క్లయింట్ రెండూ సపోర్ట్ చేసే మొదటి ఆప్షన్‌ను ఎంచుకుంటుంది, కాబట్టి పాత మెషీన్ ఉన్నప్పుడు అది పరిమితిని నిర్ణయిస్తుంది.

ఏ OpenSSH రిలీజ్ నుండి post-quantum కీ ఎక్స్ఛేంజ్ డిఫాల్ట్‌గా మారింది?

2022-04-08న విడుదలైన OpenSSH 9.0, sntrup761x25519-sha512@openssh.com ను డిఫాల్ట్ కీ ఎక్స్ఛేంజ్‌గా మార్చింది. 2024-09-19న విడుదలైన OpenSSH 9.9, mlkem768x25519-sha256 ను జోడించింది, మరియు 2025-04-09న విడుదలైన OpenSSH 10.0 దానిని డిఫాల్ట్‌గా మార్చింది. 2025-10-06న విడుదలైన OpenSSH 10.1, కనెక్షన్ ఏదీ నెగోషియేట్ చేయనప్పుడు హెచ్చరికలను ఇవ్వడం ప్రారంభించింది. మీ Ubuntu రిలీజ్ ఏ వెర్షన్‌ను కలిగి ఉందో తెలుసుకోవడానికి ssh -Q kex మరియు ssh -G <host> ద్వారా మీ బిల్డ్ ఏమి చేస్తుందో తనిఖీ చేయండి.

నేను post-quantum SSH కీని జనరేట్ చేయాలా?

వద్దు, ఎందుకంటే OpenSSH లో అటువంటి కీ రకం లేదు. ఇప్పటివరకు జరిగిన post-quantum పని కీ ఎక్స్ఛేంజ్‌కు మాత్రమే పరిమితమైంది, దీనికి మీ నుండి ఎటువంటి కీ ఫైల్స్ లేదా కాన్ఫిగరేషన్ అవసరం లేదు. హోస్ట్ కీలు మరియు లాగిన్ కీలు ఇప్పటికీ Ed25519 మరియు RSA వంటి క్లాసికల్ సిగ్నేచర్‌లనే ఉపయోగిస్తున్నాయి. భవిష్యత్తులో వచ్చే రిలీజ్‌లలో post-quantum సిగ్నేచర్‌లు వస్తాయని డెవలపర్లు తెలిపారు. Ed25519 కీని ఉపయోగిస్తూ, అది నిల్వ ఉన్న చోట భద్రతను పాటించండి.

నా కనెక్షన్ post-quantum కాదని ssh ఎందుకు హెచ్చరిస్తోంది?

నెగోషియేట్ చేసిన ఎక్స్ఛేంజ్‌లో post-quantum భాగం లేనప్పుడు OpenSSH 10.1 మరియు అంతకంటే కొత్త వెర్షన్లు ** WARNING: connection is not using a post-quantum key exchange algorithm. అని ప్రింట్ చేస్తాయి. ఈ హెచ్చరిక సర్వర్‌కు సంబంధించింది, మీ క్లయింట్‌కు కాదు. ఎందుకంటే మీ క్లయింట్ post-quantum పేరును ఆఫర్ చేసినప్పటికీ, సర్వర్ వాటిలో దేనినీ అంగీకరించలేదు. సర్వర్ యొక్క OpenSSH ను అప్‌గ్రేడ్ చేయండి, లేదా దాని sshd_config ఫైల్‌లో ఎవరైనా KexAlgorithms లైన్‌ను పిన్ చేసి ఆధునిక పేర్లను మినహాయించారేమో తనిఖీ చేయండి. WarnWeakCrypto no సెట్ చేయడం ద్వారా ఈ సందేశాన్ని దాచవచ్చు, కానీ కనెక్షన్ యొక్క బలహీనత అలాగే ఉంటుంది.