SSH ProxyCommand და ჰოსტზე დაფუძნებული ავთენტიფიკაცია: რომელი ჰოსტი აწერს ხელს?

სამიზნე ხედავს ბასტიონიდან მომავალ TCP კავშირს, მაშინ როცა ავთენტიფიკაციის შემსრულებელი SSH კლიენტი კვლავ სამუშაო სადგურზე მუშაობს.

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

აქ დამხმარე ბასტიონში შედის და მის SSH სერვერს სამიზნისკენ გადაცემული კავშირი სთხოვს. სამუშაო სადგურის გარე SSH კლიენტი ამ ნაკადის გავლით ცვლის სამიზნის SSH პროტოკოლს. ბასტიონი ტრანსპორტს უზრუნველყოფს; მან სამიზნისკენ მიმართული SSH კლიენტი არ გაუშვია.

ეს განსხვავება მნიშვნელოვანია ჰოსტზე დაფუძნებული ავთენტიფიკაციისთვის. OpenSSH-ის ssh-keysign დამხმარე საჭირო ხელმოწერის შესაქმნელად ლოკალურ ჰოსტის გასაღებებს მიმართავს. ბასტიონის კუთვნილი ქსელური წყაროს მისამართი არ აიძულებს სამუშაო სადგურს ბასტიონის ჰოსტის გასაღებით ხელი მოაწეროს.

შეადარეთ ამას:

ssh -t bastion ssh target

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

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