ვინ ხედავს სინამდვილეში თქვენს SSH პაროლს არასანდო VPN-ზე?

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

დაასახელეთ მიმღები სანამ რამეს აკრეფთ

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

ორი მიმართულება გონებაში ცალ-ცალკე შეინახეთ. ჰოსტის გასაღები პასუხობს, რომელ სერვერს მიაღწიეთ. პაროლით ან გასაღებით ავთენტიფიკაცია პასუხობს, რომელ მომხმარებელს იღებს სერვერი. მეორის გაუმჯობესება პირველს არასოდეს არ ასწორებს.

შეამოწმეთ ჰოსტის იდენტურობა, ჩანაწერი და მოლაპარაკება

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

ssh-keygen -F ssh.internal.example.net -f ~/.ssh/known_hosts
ssh -o StrictHostKeyChecking=yes ssh.internal.example.net

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

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo sshd -T | grep -E 'hostkey|kexalgorithms|cipher'

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

წაიკითხეთ მეთოდები, რომლებსაც სერვერი რეალურად იღებს

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

sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin'

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

ჰოსტის გასაღების გაფრთხილებას მოეპყარით როგორც ინციდენტის ნაბიჯს

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

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

რას არ მოიცავს ეს სახელმძღვანელო

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

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