OpenVPN სერვისი კერძო გასაღების პაროლის მოთხოვნაზე ჩერდება: როგორ გამოვასწოროთ
სერვისს ტერმინალი არ აქვს, ამიტომ დაშიფრულ გასაღებს სჭირდება askpass და წაკითხვადი ფაილი. გამოყავით გასაღების პაროლი სერვერზე შესვლისგან და შეამოწმეთ unit.
OpenVPN კერძო გასაღების პაროლს ლოკალურ მანქანაზე ითხოვს, ამიტომ მუშა შესვლის ფაილი მას არასოდეს პასუხობს. სერვისში ტერმინალი არ არის აკრეფისთვის, და გაშვება ან იკიდება, ან მარცხდება ჟურნალში ჩანაწერით, რომელიც შეყვანას ასახელებს და არა მიზეზს. აქ ორი საიდუმლო მონაწილეობს და თითოეულს საკუთარი წაკითხვადი წყარო სჭირდება unit-ის ხელახლა გაშვებამდე. ქვემოთ მოცემული გზა მათ ჰყოფს, შემდეგ კი ამოწმებს იმ იდენტობას, რომელიც რეალურად ხსნის თითოეულ ფაილს.
გაარჩიეთ ორი მოთხოვნა
გასაღების პაროლი ხსნის ლოკალურ კერძო გასაღებს; ანგარიშის მონაცემები სერვერთან სესიას ამოწმებს. ისინი სხვადასხვა ადგილიდან მოდის, სხვადასხვა მომენტში მარცხდება და სხვადასხვა შეტყობინებას იძლევა. მათი არევა ადამიანებს პაროლის აღდგენის საძებნელად აგზავნის, თუმცა ანგარიში საერთოდ არ მონაწილეობდა. წაიკითხეთ მოთხოვნის ტექსტი ნებისმიერი პარამეტრის შეცვლამდე, რადგან ფორმულირება ერთადერთი საიმედო მინიშნებაა, რომელი საიდუმლო აკლია.
Community OpenVPN 2.x-ში askpass მიუთითებს ფაილზე, რომელიც გასაღების პაროლს პირველ სტრიქონში ინახავს, ხოლო auth-user-pass ფაილზე, სადაც მომხმარებლის სახელი ერთ სტრიქონშია და პაროლი მომდევნოში. არც ერთი ფაილი ვერ აკმაყოფილებს მეორე პარამეტრს. დესკტოპ აპლიკაციამ ან NetworkManager-ის პროფილმა შეიძლება ორივე საკუთარ საიდუმლოთა საცავში შეინახოს, რომელსაც ბრძანების ხაზის კლიენტი არასოდეს კითხულობს, ამიტომ სანამ რომელიმე გზას ჩაწერთ, დააფიქსირეთ რომელ კლიენტს აყენებთ.
ორივე პარამეტრი წაკითხვად ფაილებზე მიმართეთ
პროფილი, რომელსაც ორივე შეყვანა სჭირდება, საბოლოოდ სამ ფაილის ბმულს იძენს: დაშიფრულ გასაღებს, მის გამხსნელ პაროლს და შესვლის წყვილს. დაამატეთ ისინი CA-სა და იდენტობის შემოწმებებზე ხელის შეუხებლად, რადგან ისინი წყვეტენ ვინ არის სერვერი და ამ პრობლემის ნაწილი არ არიან. თუ განლაგება ანგარიშის მონაცემებს საერთოდ არ იყენებს, auth-user-pass-ის დამატება ქმნის შეყვანას, რომელსაც ვერავინ მოგვაწვდის.
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.authარგუმენტის გარეშე პარამეტრები სხვაგვარად იქცევიან, ვიდრე გზის მქონე, და სერვისში ეს განსხვავება მნიშვნელოვანია. askpass არგუმენტის გარეშე კვლავ კონსოლიდან კითხულობს, ხოლო მხოლოდ მომხმარებლის სახელის მქონე auth-user-pass ფაილი კვლავ პაროლის მოთხოვნას ტოვებს ლოდინში. როცა კლიენტი დემონად იქცევა, ის ტერმინალიდან შეყვანას საერთოდ ვერ ითხოვს, ამიტომ ასე კონფიგურირებული სერვისი არ ადის.
აბსოლუტური გზები სამუშაო დირექტორიის კითხვას აშორებს, მაგრამ წვდომას არ იძლევა. შემდეგ მოდის მფლობელობა, რეჟიმი და გავლადობა, და სამივე იმ ანგარიშის მიმართ მოწმდება, რომლის ქვეშაც პროცესი მუშაობს.
ჯერ unit-ის კონფიგურაცია წაიკითხეთ, შემდეგ პროფილი
რომელ კონფიგურაციას ჩატვირთავს ინსტანსი, unit წყვეტს და არა ის ფაილი, რომელსაც არედაქტირებდით. წაიკითხეთ მისი ბრძანების ხაზი და ყველა drop-in, შემდეგ სამუშაო დირექტორიიდან გაჰყევით რეალურად გამოყენებულ პროფილამდე. სხვა .ovpn ფაილში დამატებული პაროლის ბმული ამ ინსტანსისთვის არაფერს ცვლის.
სამი მხოლოდ-კითხვის ბრძანება პასუხობს ამის უმეტეს ნაწილს. პირველი ბეჭდავს unit-ს და ყველა drop-in-ს, მეორე იდენტობას და პროცესის შემზღუდველ sandbox პარამეტრებს, ხოლო მესამე იმას, რაზეც ბოლო გაშვებამ რეალურად იჩივლა. გამოიყენეთ ინსტანსის სახელი, რომელიც ჰოსტზე არსებობს:
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bყურადღება მიაქციეთ ProtectHome-ს და პროფილის საკუთარ user, group და chroot პარამეტრებს. სახლის დირექტორიის ქვეშ მყოფი ფაილი შეიძლება თქვენს shell-ში წაკითხვადი იყოს და სერვისის შიგნით უხილავი გახდეს, როცა სახლის დირექტორიები იმალება. ანგარიში, რომლითაც systemd იწყებს, ყოველთვის არ არის ის ანგარიში, რომელიც საბოლოოდ ხსნის გასაღებს.
დაამტკიცეთ, რომ გაშვების იდენტობას ორივე ფაილის გახსნა შეუძლია
რეჟიმის წაკითხვა საკმარისი არ არის, რადგან გზის ყოველი დირექტორია იმავე იდენტობისთვის გავლადი უნდა იყოს. გაიარეთ გზა კომპონენტ-კომპონენტ, შემდეგ გამოსცადეთ გახსნა იმ ანგარიშით, რომელსაც პროცესი იყენებს. root-ის საკუთრებაში მყოფი და 600 რეჟიმის ფაილი მუშაობს მხოლოდ მანამ, სანამ პროცესი ჯერ კიდევ root-ია, რაც არ არის მართალი მრავალი პროფილის მიერ შესრულებული პრივილეგიების დაწევის შემდეგ. ორი ბრძანება ფარავს გავლას და გახსნას:
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readableპირველი ბრძანება ბეჭდავს თითოეული კომპონენტის რეჟიმს და მარცხდება იქ, სადაც ანგარიში ვერ გაივლის; მეორე პასუხობს ერთადერთ მნიშვნელოვან კითხვას, შეუძლია თუ არა გაშვების იდენტობას ფაილის წაკითხვისთვის გახსნა. არც ერთი არ ბეჭდავს ფაილის შიგთავსს და სწორედ ეს არის აზრი, როცა ფაილი პაროლს ინახავს. გაიმეორეთ გამოცდა შესვლის ფაილისთვის, რადგან ორივე ხშირად სხვადასხვა მფლობელობით ინახება.
თუ პროცესი chroot-ს ან შეზღუდულ namespace-ს იყენებს, გაუშვით იგივე გამოცდა ამ ხედის შიგნიდან, თორემ პასუხი არასწორ ფაილურ სისტემას აღწერს. დამალული სახლის დირექტორიის ქვეშ შენახული პაროლი ჩვეულებრივი მაგალითია გამოცდისა, რომელიც unit-ის გარეთ გადის და შიგნით მარცხდება.
შეამოწმეთ პირველი გაშვება, შემდეგ ხელახალი დაკავშირება
გაუშვით ინსტანსი ერთხელ და წაიკითხეთ პირველი მარცხი და არა ბოლო. აკლია შეყვანის ფაილი, ვერ მოხერხდა გასაღების გაშიფვრა და სერვერის მხრიდან AUTH_FAILED სამი სხვადასხვა მოვლენაა სამი სხვადასხვა შესწორებით. ნებართვების გაფრთხილების გასწორება არაფერს ამტკიცებს იმაზე, გაიხსნა თუ არა გასაღები.
ჟურნალის სტრიქონი გეუბნებათ, სამიდან რომელი გაქვთ. შესწორება გამომდინარეობს იქიდან, რომელი შეყვანა ჩავარდა:
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
შემდეგ გამოსცადეთ ის ცხოვრების ციკლი, რომელიც ნამდვილად გჭირდებათ: გაშვება ჩატვირთვისას და ყოველი მხარდაჭერილი ხელახალი დაკავშირება და არა მხოლოდ ხელით გაშვება თქვენი shell-იდან. auth-nocache-ით შეყვანა პირველი გამოყენების შემდეგ იშლება, ამიტომ გვიანდელ ხელახალ დაკავშირებას მაინც წაკითხვადი წყარო სჭირდება. დესკტოპზე შესვლისას გახსნილი გასაღებების რგოლი არ არის ხელმისაწვდომი იმ სერვისისთვის, რომელიც ვინმეს შესვლამდე დაიწყო, და ეს არის ჩვეულებრივი მიზეზი იმისა, რომ ხელით გამოცდა გადის, ხოლო ხელახალი ჩატვირთვა მარცხდება. თუ პირველი გაშვება წარმატებულია და გვიანდელი ხელახალი დაკავშირება ჩავარდა, ნებართვების ხელახლა შეცვლამდე წაიკითხეთ ჟურნალი ხელახალი დაკავშირების მოვლენისთვის.
პაროლის გასაღების გვერდით შენახვა ამცირებს იმას, რასაც დაშიფვრა გაძლევთ, ამიტომ შეზღუდეთ ეს ფაილი და მისი სარეზერვო ასლები. გასაღების პაროლის მოშორება განიხილეთ როგორც ცალკე სამეურვეო გადაწყვეტილება და არა როგორც აკლია შეყვანის შესწორება. განლაგებას, რომელიც ადამიანურ დამტკიცებაზე ან ინტერაქტიულ MFA-ზეა დამოკიდებული, სჭირდება მისი მხარდაჭერილი აგენტი ან მართვის ინტეგრაცია; მუდმივად შენახული ერთჯერადი კოდი ეკვივალენტური შემცვლელი არ არის.