SSH ProxyCommand en gasheergebaseerde verifikasie: watter gasheer onderteken?

’n Teiken kan ’n TCP-verbinding sien wat van die bastion kom, terwyl die SSH-kliënt wat die verifikasie doen steeds op die werkstasie loop.

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

Hier meld die helper by die bastion aan en vra sy SSH-bediener om ’n deurgegewe verbinding na die teiken. Die werkstasie se buitenste SSH-kliënt voer die teiken se SSH-protokol deur daardie stroom. Die bastion verskaf vervoer; dit het nie die SSH-kliënt na die teiken begin nie.

Daardie onderskeid is belangrik vir gasheergebaseerde verifikasie. OpenSSH se ssh-keysign-helper kry toegang tot plaaslike gasheersleutels om die vereiste handtekening te skep. ’n Netwerkbronadres wat aan die bastion behoort, maak nie dat die werkstasie met die bastion se gasheersleutel onderteken nie.

Vergelyk dit met:

ssh -t bastion ssh target

Dit begin ’n ander SSH-program op die bastion. Sy plaaslike konfigurasie en beskikbare gasheersleutels behoort aan daardie masjien, so dit kan deelneem aan ’n reeds opgestelde gasheergebaseerde vertrouensreëling tussen bastion en teiken. Dit benodig steeds die teiken se ooreenstemmende magtiging en naamkontroles.

Die tweede vorm verander ook hoe die sessie werk: dit voer ’n afgeleë opdrag uit en gebruik ’n terminaal. Dit is nie ’n deursigtige vervanging vir elke SSH-lêeroordrag of outomatiseringsvervoer nie. Kies die reëling volgens watter masjien by die teiken moet verifieer, eerder as om die bediener se vertrouenskontroles te verswak sodat die bronadres voldoende lyk.