SSH ProxyCommand און host-based authentication: וועלכער host חתמעט?
אונטערשײדן דאס דורכפירן א TCP שטראם דורך א bastion פון אנהייבן א צווייטן SSH קליענט דארט ווען host-based authentication איז אינוואלווירט.
א ציל קען זען א TCP פֿאַרבינדונג וואס קומט פונעם bastion, בשעת דער SSH קליענט וואס פֿירט אויס די אויטענטיפֿיקאַציע לויפֿט נאך אויף דער ארבעטססטאציע.
Host behind-bastion
ProxyCommand ssh -W %h:%p bastionדא לאגירט זיך דער העלפֿער איין אין bastion און בעט זיין SSH סערווער איבערגעגעבענע פֿאַרבינדונג צום ציל. דער אויסערלעכער SSH קליענט פון דער ארבעטססטאציע טוישט אויס דעם ציל׳ס SSH פּראָטאָקאל דורך יענעם שטראם. דער bastion צושטעלט טראַנספּאָרט; ער האט נישט אנגעהויבן דעם SSH קליענט וואס קוקט צום ציל.
דער אונטערשײד איז וויכטיק פֿאַר host-based authentication. דער ssh-keysign העלפֿער פון OpenSSH באקומט צוטריט צו לאקאלע host שליסלעך צו פֿאַרזארגן די נויטיקע חתימה. א נעץ־מקור־אַדרעס וואס געהערט צום bastion מאכט נישט די ארבעטססטאציע חתמען מיטן bastion׳ס host שליסל.
פֿאַרגלײכט מיט:
ssh -t bastion ssh targetדאס הייבט אן אן אנדער SSH פּראָגראַם אויפן bastion. זיין לאקאלע קאָנפֿיגוראַציע און פֿאַראַנענע host שליסלעך געהערן צו יענער מאַשין, ממילא קען ער מיטהאלטן אין אן שוין קאָנפֿיגורירטער host-based צוטרוי־איינאָרדענונג צווישן bastion און ציל. ער דארף נאך די פּאַסיקע דערלויבעניש און נאמען־פּרופֿונגען פונעם ציל.
די צווייטע פֿאָרם ענדערט אויך וויאזוי די סעסיע ארבעט: זי לויפֿט א ווייטן באַפֿעל און נוצט א טערמינאַל. זי איז נישט קיין דורכזיכטיקער פֿאַרבײַטװײז פֿאַר יעדער SSH טעקע־איבערטראָגונג אָדער אויטאָמאַטיזירונג טראַנספּאָרט. קלײַבט די איינאָרדענונג לויט וועלכע מאַשין דארף זיך אויטענטיפֿיצירן ביים ציל, אַנשטאָט אַנטשוואכן די סערווערס צוטרוי־פּרופֿונגען כּדי דער מקור־אַדרעס זאל אויסזען גענוג.