SSH ProxyCommand eta ostalari oinarritutako autentifikazioa: zein ostalarik sinatzen du?

Bereizi TCP korronte bat bastioi baten bidez birbidaltzea han bigarren SSH bezero bat abiaraztetik, ostalari oinarritutako autentifikazioa tartean dagoenean.

Helburuak bastioitik datorren TCP konexioa ikus dezake, autentifikazioa egiten duen SSH bezeroa lan-estazioan ari den bitartean.

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

Hemen laguntzaileak bastioian saioa hasi eta haren SSH zerbitzariari helburura birbidalitako konexioa eskatzen dio. Lan-estazioaren kanpoko SSH bezeroak helburuaren SSH protokoloa trukatzen du korronte horren bidez. Bastioiak garraioa ematen du; ez du helburura zuzendutako SSH bezeroa abiarazi.

Bereizketa hori garrantzitsua da ostalari oinarritutako autentifikaziorako. OpenSSHren ssh-keysign laguntzaileak tokiko ostalari gakoetara iristen da behar den sinadura sortzeko. Bastioiarena den sareko iturburu helbideak ez du lan-estazioa bastioiaren ostalari gakoarekin sinatzea eragiten.

Alderatu honekin:

ssh -t bastion ssh target

Honek beste SSH programa bat abiarazten du bastioian. Haren tokiko konfigurazioa eta eskuragarri dauden ostalari gakoak makina horrenak dira, beraz, bastioiaren eta helburuaren artean aurrez konfiguratutako ostalari oinarritutako konfiantza akordio batean parte har dezake. Oraindik helburuaren baimen eta izen egiaztapen egokiak behar ditu.

Bigarren formak saioaren funtzionamendua ere aldatzen du: urruneko komando bat exekutatzen du eta terminal bat erabiltzen du. Ez da SSH fitxategi transferentzia edo automatizazio garraio bakoitzerako ordezko garden bat. Aukeratu konfigurazioa zein makinak autentifikatu behar duen helburuaren aurrean, zerbitzariaren konfiantza egiaztapenak ahuldu beharrean iturburu helbidea nahikoa dela emateko.

Erlazionatutako artikuluak