ssh-keyscan ne akceptas la opcion ProxyCommand de SSH. Proksio agordita por ssh do ne aŭtomate agordas la apartan skanilon.

Unu solvo estas jam establita loka TCP-relajso, kiu plenumas la bezonatan proksian aŭtentikigon kaj CONNECT-interŝanĝon kaj poste elmontras la bajtan fluon de la celata SSH-servilo. Se tiu relajso aŭskultas sur 127.0.0.1:2222:

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

La unua komando kolektas kandidatajn ŝlosilojn; la dua montras iliajn fingrospurojn. La relajso devas pasigi la SSH-fluon post konsumado de la kompleta proksia respondo, anstataŭ transdoni HTTP-kapojn al la skanilo.

La gastiga etikedo en la eligo priskribas la lokan finpunkton de la relajso. Ne aldonu ĝin senŝanĝe kaj ne supozu, ke ĝi nun identigas la malproksiman SFTP-gastigonomon.

Kontrolu la fingrospuron per fidinda registro aŭ administranto antaŭ ol ligi la ŝlosilon al la reala gastigo kaj pordo en known_hosts. ssh-keyscan kolektas tion, kion prezentas la atingebla finpunkto; sukcesa proksia konekto ne aŭtentikigas tiun ŝlosilon.

Rilataj artikoloj