Hindi tinatanggap ng ssh-keyscan ang opsiyon na ProxyCommand ng SSH. Kaya't ang proxy na naka-configure para sa ssh ay hindi awtomatikong nagsasaayos ng hiwalay na scanner.

Isang solusyon ay ang lokal na TCP relay na dati nang nakatayo, na nagsasagawa ng kinakailangang proxy authentication at CONNECT exchange, pagkatapos ay inilalantad ang byte stream ng target na SSH server. Kung nakikinig ang relay na iyon sa 127.0.0.1:2222:

ssh-keyscan -p 2222 127.0.0.1 > candidate.keys
ssh-keygen -lf candidate.keys

Kinokolekta ng unang utos ang mga kandidatong key; ipinapakita ng pangalawa ang mga fingerprint ng mga ito. Dapat ipaagos ng relay ang SSH stream pagkatapos ubusin ang kumpletong tugon ng proxy, sa halip na ibigay ang mga HTTP header sa scanner.

Inilalarawan ng host label sa output ang lokal na endpoint ng relay. Huwag itong idagdag nang walang pagbabago at huwag ipagpalagay na nakikilala na nito ang malayong SFTP hostname.

I-verify ang fingerprint sa pamamagitan ng mapagkakatiwalaang rekord o administrator bago iugnay ang key sa tunay na host at port sa known_hosts. Kinokolekta ng ssh-keyscan ang ipinapakita ng naaabot na endpoint; hindi napatutunayan ng matagumpay na proxy connection ang key na iyon.

Kaugnay na mga artikulo