SSH ProxyCommand at Host-Based Authentication: Aling Host ang Pumipirma?
Ihiwalay ang pagpapasa ng TCP stream sa isang bastion mula sa pagsisimula ng pangalawang SSH client doon kapag kasangkot ang host-based authentication.
Nakikita ng target ang koneksyon ng TCP na nagmumula sa bastion habang ang SSH client na gumagawa ng authentication ay tumatakbo pa rin sa workstation.
Host behind-bastion
ProxyCommand ssh -W %h:%p bastionDito nag-log in ang helper sa bastion at hinihiling sa SSH server nito ang isang naipasang koneksyon patungo sa target. Ang panlabas na SSH client ng workstation ay nagpapalitan ng SSH protocol ng target sa stream na iyon. Ang bastion ang nagbibigay ng transport; hindi nito sinimulan ang SSH client na nakaharap sa target.
Mahalaga ang pagkakaibang iyon para sa host-based authentication. Ang ssh-keysign helper ng OpenSSH ay uma-access sa mga lokal na host key upang makabuo ng kinakailangang lagda. Ang pagiging address ng network source na pag-aari ng bastion ay hindi nagpapapirma sa workstation gamit ang host key ng bastion.
Ihambing ito sa:
ssh -t bastion ssh targetSinisimulan nito ang isa pang SSH program sa bastion. Ang lokal na configuration at available na host key nito ay pag-aari ng makina na iyon, kaya makakasali ito sa naka-configure nang host-based trust arrangement sa pagitan ng bastion at target. Kailangan pa rin nito ang katumbas na authorization at pag-check ng pangalan ng target.
Binabago rin ng pangalawang anyo ang paraan ng paggana ng session: nagpapatakbo ito ng remote command at gumagamit ng terminal. Hindi ito transparent na kapalit para sa bawat SSH file transfer o automation transport. Piliin ang arrangement ayon sa makina na dapat mag-authenticate sa target, sa halip na pahinain ang trust check ng server upang magmukhang sapat ang source address.