SSH ProxyCommand en host-basearre autentikaasje: hokker host ûndertekenet?

Unterskied it trochjaan fan in TCP-stream fia in bastion fan it starten fan in twadde SSH-klient dêr, as host-basearre autentikaasje yn it spul is.

In doel kin in TCP-ferbining sjen dy't fan it bastion komt, wylst de SSH-klient dy't de autentikaasje docht noch op it wurkstasjon draait.

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

Hjir meldt de helper him oan by it bastion en freget syn SSH-tsjinner om in trochjûne ferbining nei it doel. De bûtenste SSH-klient fan it wurkstasjon wikselet it SSH-protokol fan it doel út fia dy stream. It bastion leveret it transport; it hat de SSH-klient rjochte op it doel net start.

Dat ûnderskied is wichtich foar host-basearre autentikaasje. De ssh-keysign-helper fan OpenSSH brûkt lokale hostkaaien om de fereaske hantekening te meitsjen. In netwurkboarneadres dat by it bastion heart, makket net dat it wurkstasjon mei de hostkaai fan it bastion ûndertekenet.

Fergelykje dat mei:

ssh -t bastion ssh target

Dit start in oar SSH-programma op it bastion. Syn lokale konfiguraasje en beskikbere hostkaaien hearre by dy masine, sadat it dielnimme kin oan in al konfigurearre host-basearre fertrouwensregeling tusken bastion en doel. It hat noch altyd de oerienkommende autorisaasje en nammerkontrôles fan it doel nedich.

De twadde foarm feroaret ek hoe't de sesje wurket: it fiert in opdracht op ôfstân út en brûkt in terminaal. It is gjin transparante ferfanging foar elke SSH-bestânsoerdracht of automatisearringstransport. Kies de regeling neffens hokker masine him by it doel autentisearje moat, ynstee fan de fertrouwenskontrôles fan 'e tsjinner te ferswakjen sadat it boarneadres genôch liket.

Relatearre artikelen