SSH-ის დაკავშირება HTTP პროქსის მეშვეობით
გაატარეთ SSH კავშირი არსებული HTTP CONNECT პროქსის მეშვეობით, თითო ჰოსტის ProxyCommand-ით.
OpenBSD-თან თავსებადი nc-ით დაამატეთ ეს ჰოსტის ჩანაწერი SSH კლიენტის კონფიგურაციაში, მაგალითად ~/.ssh/config:
Host work-through-proxy
HostName ssh.example.com
User alex
ProxyCommand nc -X connect -x proxy.example.net:8080 %h %pამ მარშრუტისთვის გამოიყენეთ ssh work-through-proxy. დამხმარე HTTP პროქსის სთხოვს CONNECT-ს ssh.example.com-ზე და მიღებულ ნაკადს SSH-ს გადასცემს. SSH-ის უშუალოდ პროქსის პორტზე მიმართვა მის handshake-ს HTTP-ის მომლოდინე სერვისთან გაგზავნიდა.
შეცვალეთ ბოლო წერტილი, დანიშნულება და ანგარიში. საჯაროდ მისაწვდომი SSH დანიშნულებისთვის, სადაც საჯარო შუამავალი დაშვებულია, HTTP პროქსების სია გთავაზობთ კანდიდატებს ამ ჰოსტსა და პორტზე წვდომის შესამოწმებლად; აირჩიეთ ბოლო წერტილი, რომელსაც ნაჩვენები ბრძანებისთვის პროქსის ანგარიში არ სჭირდება. ეს OpenBSD nc პარამეტრები იმპლემენტაციაზეა დამოკიდებული; nc სახელის სხვა შესრულებადმა ფაილმა შეიძლება არ დაუჭიროს მხარი.
პროქსიმ შეიძლება მოითხოვოს საკუთარი შესვლა ან უარყოს მოთხოვნილი SSH პორტი. 407 სწორედ ამ პროქსის გაცვლას ეხება. გვირაბის გახსნის შემდეგ SSH მაინც ამოწმებს სამიზნე ჰოსტს და ავთენტიფიცირებს მომხმარებელს; უარყოფილი SSH გასაღები სხვა უკმარისობაა.
შეინახეთ ProxyCommand განზრახული Host სექციის ქვეშ და საჭიროებისას გამოიყენეთ არჩეული დამხმარის მიერ მხარდაჭერილი პროქსის ავთენტიფიკაციის გზა. ბრძანება ნაკადს იძლევა და არა შუამავალზე ნებართვას. თუ მხოლოდ HTTPS დანიშნულებებია დაშვებული, მიიღეთ დამტკიცებული SSH წვდომის შეთანხმება, ნაცვლად იმისა, რომ ივარაუდოთ ბრძანების სხვა დაწერის პოლიტიკის შეცვლა.