ssh-keyscan არ იღებს SSH-ის ProxyCommand პარამეტრს. ამიტომ ssh-ისთვის გამართული პროქსი ცალკე სკანერს ავტომატურად არ აყენებს.

ერთი ვარიანტია უკვე დამყარებული ლოკალური TCP რელე, რომელიც ასრულებს საჭირო პროქსი ავთენტიფიკაციას და CONNECT გაცვლას, შემდეგ კი ავლენს სამიზნე SSH სერვერის ბაიტურ ნაკადს. თუ ეს რელე 127.0.0.1:2222-ზე უსმენს:

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

პირველი ბრძანება აგროვებს კანდიდატ გასაღებებს, მეორე აჩვენებს მათ ანაბეჭდებს. რელემ უნდა გაატაროს SSH ნაკადი პროქსის სრული პასუხის მოხმარების შემდეგ, ნაცვლად იმისა, რომ HTTP თავსართები სკანერს გადასცეს.

გამოსავლის ჰოსტის ეტიკეტი აღწერს რელეს ლოკალურ ბოლო წერტილს. ნუ დაუმატებთ უცვლელად და ნუ ჩათვლით, რომ ის ახლა დისტანციურ SFTP ჰოსტის სახელს განსაზღვრავს.

გადაამოწმეთ ანაბეჭდი სანდო ჩანაწერის ან ადმინისტრატორის მეშვეობით, სანამ გასაღებს known_hosts-ში ნამდვილ ჰოსტსა და პორტს დაუკავშირებთ. ssh-keyscan აგროვებს იმას, რასაც ხელმისაწვდომი ბოლო წერტილი წარმოადგენს; წარმატებული პროქსი კავშირი ამ გასაღებს არ ამოწმებს.

დაკავშირებული სტატიები