SSH ProxyCommand మరియు హోస్ట్-ఆధారిత ప్రమాణీకరణ: ఏ హోస్ట్ సంతకం చేస్తుంది?

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

Host behind-bastion
    ProxyCommand ssh -W %h:%p bastion

ఇక్కడ సహాయకుడు బాస్టియన్‌లోకి లాగిన్ అయి దాని SSH సర్వర్‌ను లక్ష్యం వైపు పంపబడిన కనెక్షన్ కోసం అడుగుతాడు. వర్క్‌స్టేషన్ బయటి SSH క్లయింట్ ఆ స్ట్రీమ్ ద్వారా లక్ష్యం SSH ప్రోటోకాల్‌ను మార్పిడి చేస్తుంది. బాస్టియన్ రవాణాను అందిస్తుంది; అది లక్ష్యం వైపు ఉన్న SSH క్లయింట్‌ను ప్రారంభించలేదు.

హోస్ట్-ఆధారిత ప్రమాణీకరణకు ఈ భేదం ముఖ్యం. OpenSSH యొక్క ssh-keysign సహాయకుడు అవసరమైన సంతకాన్ని సృష్టించడానికి స్థానిక హోస్ట్ కీలను ఉపయోగిస్తాడు. బాస్టియన్‌కు చెందిన నెట్‌వర్క్ మూల చిరునామా కావడం వర్క్‌స్టేషన్‌ను బాస్టియన్ హోస్ట్ కీతో సంతకం చేయించదు.

దీనితో పోల్చండి:

ssh -t bastion ssh target

ఇది బాస్టియన్‌లో మరొక SSH ప్రోగ్రామ్‌ను ప్రారంభిస్తుంది. దాని స్థానిక కాన్ఫిగరేషన్ మరియు అందుబాటులో ఉన్న హోస్ట్ కీలు ఆ మెషీన్‌కు చెందినవి, కాబట్టి బాస్టియన్ నుండి లక్ష్యం వరకు ఇప్పటికే కాన్ఫిగర్ చేసిన హోస్ట్-ఆధారిత విశ్వాస ఏర్పాటులో పాల్గొనగలదు. లక్ష్యం యొక్క సంబంధిత అనుమతి మరియు పేరు తనిఖీలు ఇంకా అవసరం.

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