NGINX స్ట్రీమ్ రిలే ద్వారా SSH — విచ్ఛిన్నం చేయకుండా

PROXY హెడర్ దానిని ఆశించే గ్రహీతకు సందేశం, మరియు ప్రాక్సీ చేసిన DNS రికార్డు TCP రిలే కాదు. అంచు మరియు పైప్రవాహాన్ని విడివిడిగా సరిచేయండి.

రిలే ద్వారా పబ్లిక్ SSH రెండు సంబంధం లేని సరిహద్దుల్లో విఫలమవుతుంది, ఒకదాన్ని సరిచేయడం సాధారణంగా మరొకదాన్ని వెల్లడిస్తుంది. ఒకటి అంచు స్ట్రీమ్ను మోసుకెళ్లే బదులు HTTP ప్రతిస్పందనను తిరిగి ఇస్తుంది, లేదా రిలే బ్యాకెండ్ చదవడానికి ఎప్పుడూ అంగీకరించని హెడర్ను ముందు పెడుతుంది. మీరు ఏది చూస్తున్నారో మూడు షరతులు నిర్ణయిస్తాయి: పబ్లిక్ రికార్డు నిజంగా ఏదాన్ని సూచిస్తుంది, స్ట్రీమ్ బ్లాక్ పైకి ఏమి పంపుతుంది, మరియు SSH క్లయింట్ ఏ పేరును ధృవీకరిస్తుంది. అదే క్రమంలో వాటిని నిర్వహించండి.

రెండు సరిహద్దులు, రెండు లక్షణాలు

అంచు వద్ద వైఫల్యం SSH బ్యానర్ ఉండాల్సిన చోట HTTP స్థితి పేజీ వస్తున్నట్టు కనిపిస్తుంది. కనెక్షన్ TCP స్థాయిలో పూర్తవుతుంది మరియు మొదటి బైట్లు వెబ్ సర్వర్కు చెందిన వచనం. ఇది ప్రోటోకాల్ అసమతుల్యత, పోయిన ప్యాకెట్ కాదు. ఆ పేరు కోసం అంచు ఉద్దేశపూర్వకంగా వేరే ఏదో అందిస్తోందని కూడా ఇది చెబుతుంది.

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

ఈ రెండింటిని గందరగోళపరచడం సులభం, ఎందుకంటే రెండూ కనెక్ట్ అయి తర్వాత విఫలమయ్యే క్లయింట్ను సృష్టిస్తాయి. మీరు పొందే మొదటి ప్రోటోకాల్ ప్రతిస్పందన వాటిని వేరు చేస్తుంది, అందుకే అది టికెట్లో ఉండాలి.

PROXY హెడర్ ఒక సందేశం, స్విచ్ కాదు

స్ట్రీమ్ మాడ్యూల్లో, proxy_protocol on NGINXను పేలోడ్కు ముందు పైవైపుకు PROXY ప్రోటోకాల్ హెడర్ రాయమని ఆదేశిస్తుంది. ఇది TCP ప్రాక్సీని ప్రారంభించదు, SSH ఎన్క్రిప్షన్కు ఎటువంటి సంబంధం లేదు. ఇది గ్రహీతకు ఉద్దేశించిన గమనిక. గ్రహీత దాన్ని చదవలేకపోతే, అది స్ట్రీమ్ ఆరంభంలో చెత్తగా మారుతుంది.

స్వీకరించే సేవ ఆ హెడర్ను ఉద్దేశపూర్వకంగా వినియోగించాలి. సాధారణ sshd కనెక్షన్పై మొదటి బైట్లుగా SSH గుర్తింపు మార్పిడిని ఆశిస్తుంది, కాబట్టి ఊహించని పీఠిక హ్యాండ్షేక్ను పాడైన సర్వర్లా కనిపించే విధంగా బద్దలు కొడుతుంది.

stream {
    server {
        listen 2222;
        proxy_pass 10.77.0.20:22;
    }
}

ఆ భాగం VPN ద్వారా చేరుకోగల బ్యాకెండ్ కోసం పూర్తి పనిచేసే రిలే. ఏ PROXY సూచనా కనిపించదు, ఎందుకంటే గ్రహీత ఆ ప్రోటోకాల్ మాట్లాడదు, ఆ లేమి విస్మరణ కాదు, ఒక నిర్ణయం.

రెండు దిశలను కూడా వేరు చేయండి. listen పంక్తిలో proxy_protocol సెట్ చేయడం అంటే NGINX తన స్వంత క్లయింట్ మొదట హెడర్ను పంపుతుందని ఆశిస్తుంది; సాధారణ SSH క్లయింట్ కోసం దీన్ని ప్రారంభించడం ప్రజలు సాధారణంగా పరిష్కరించడానికి ప్రయత్నించే సమస్యకు సరిగ్గా వ్యతిరేక ఫలితాన్ని ఇస్తుంది.

పబ్లిక్ హోస్ట్నామ్ నిజంగా ఎక్కడికి చేరుతుంది

SSH సెషన్లో HTTP 400 పేజీ అంచు గురించి సాక్ష్యం. మార్గంలో ఏదో HTTP మాట్లాడుతుంది, బ్యాకెండ్లో కీ లేదా ఖాతా పని ఏమైనా దాన్ని మార్చదు. అంచు పరిష్కారమయ్యే వరకు బ్యాకెండ్ను మార్చడం ఆపండి.

Cloudflare యొక్క సాధారణ ప్రాక్సీ చేసిన రికార్డు దాని మద్దతు ఉన్న HTTP మరియు HTTPS ట్రాఫిక్ను నిర్దిష్ట పోర్టుల్లో మోసుకెళ్తుంది. హోస్ట్నామ్ కోసం ప్రాక్సీని ఆన్ చేయడం సాధారణ TCP రిలేను సృష్టించదు, SSHను పోర్ట్ 443కి తరలించడం దాన్ని HTTPS చేయదు.

రెండు ఆచరణీయ దిశలు ఉన్నాయి. DNS మాత్రమే రికార్డు మీ స్వంత TCP రిలేకు సూచించగలదు, ఇది బహిర్గత నిర్ణయాన్ని మీ చేతుల్లో ఉంచుతుంది. ప్రత్యామ్నాయంగా, SSH రవాణాను స్పష్టంగా పత్రీకరించే ఉత్పత్తిని ఉపయోగించండి, దాని స్వంత మూలం, క్లయింట్ మరియు యాక్సెస్ కాన్ఫిగరేషన్తో.

మీరు ఏది ఎంచుకున్నా, రిలేకు ఇంకా బ్యాకెండ్కు VPN మార్గం, అనుమతించిన కనెక్షన్ మరియు తిరిగి వచ్చే మార్గం అవసరం. పబ్లిక్ వైపు పనిచేస్తుందని మార్గం ఐచ్ఛికం కాదు.

మారుపేరు ద్వారా SSH గుర్తింపును స్థిరంగా ఉంచండి

వినియోగదారులు సాధారణంగా తమ ప్రస్తుత హోస్ట్నామ్ను టైప్ చేయడం కొనసాగించాలనుకుంటారు. SSH కాన్ఫిగరేషన్లోని మారుపేరు రిలే గురించి ఏమీ మార్చకుండా అది చేయగలదు, మరియు మార్పును అది ఉండాల్సిన క్లయింట్ వైపే ఉంచుతుంది.

Host git.example.com
    HostName ssh-entry.example.net
    Port 2222
    User git
    HostKeyAlias git.example.com

HostKeyAlias లేకుండా, OpenSSH తాను కనెక్ట్ అయ్యే పేరు కింద హోస్ట్ కీని వెతుకుతుంది, కాబట్టి నమోదు కదులుతుంది మరియు ప్రతి వినియోగదారు మొదటి వినియోగంలో కీ మారిన హెచ్చరికను చూస్తారు. మారుపేరు సెట్ చేయడం known-hosts నమోదులను స్థిరంగా ఉంచుతుంది, కనెక్షన్ ఇంకా రిలేకు వెళ్తుంది.

ఈ మారుపేరు SSH ఆధారిత రిమోట్ నిల్వలకు మాత్రమే వర్తిస్తుంది. HTTPS Git URL దాన్ని పరిగణించదు, మరియు సాధారణ రిమోట్ URL మీరు నిజంగా సిద్ధం చేసిన రవాణాకు సరిపోలాలి.

మీరు చేయకూడని పని హెచ్చరికను తీసేయడానికి హోస్ట్ కీ ధృవీకరణను నిలిపివేయడం. అది ఫార్వార్డింగ్ మరమ్మతు ఎప్పుడూ తాకమని అడగని రక్షణను తొలగిస్తుంది, మరియు కనిపించే ఇబ్బందిని నిజమైన బహిర్గతంగా మారుస్తుంది.

ప్రతి హాప్ను విడిగా ధృవీకరించండి

పబ్లిక్ లిజనర్ను ఒంటరిగా పరీక్షించండి, తర్వాత రిలే హోస్ట్ నుండి రిలే-నుండి-బ్యాకెండ్ కనెక్షన్, ఆ తర్వాత మాత్రమే క్లయింట్ను ఆరంభం నుండి ముగింపు వరకు. ఆ మూడు పరీక్షలలో ప్రతి ఒక్కటి వేరే పొరను తొలగిస్తుంది. ఒకటి దాటవేస్తే మిగిలిన రెండు ఫలితాలను వ్యాఖ్యానించలేము. మూడు పరిశీలనలు, వైఫల్యం జీవించగల మూడు ప్రదేశాలు.

ప్రతి ఫలితంతో గమ్య చిరునామా, పోర్ట్ మరియు మొదటి ప్రోటోకాల్ బైట్లను ఉంచండి. ఆ త్రికం అంచు లోపాన్ని VPN రూటింగ్ సమస్య మరియు SSH ప్రమాణీకరణ వైఫల్యం నుండి వేరు చేస్తుంది, అదే మరమ్మతు మరియు ఊహ మధ్య వ్యత్యాసం.

చివరగా, ఉద్దేశించిన బహిర్గతాన్ని పత్రీకరించండి. ప్రైవేట్ బ్యాకెండ్కు SSH మోసుకెళ్లే TCP రిలే పబ్లిక్ పరిధిలో ఉద్దేశపూర్వకంగా తెరిచిన ద్వారం, ఇది ఏ ఇతర ఇన్బౌండ్ సేవకైనా సమాన సమీక్షకు అర్హమైనది.

సంబంధిత వ్యాసాలు