შესწორება: OpenVPN-მ ვერ შეძლო Auth მომხმარებლის სახელის წაკითხვა სტანდარტული შეყვანიდან
OpenVPN-ის შეცდომა «could not read Auth username from stdin» ლოკალური შეყვანის ჩავარდნაა. მიეცით სერვისს წაკითხვადი რწმუნებების წყარო; script-security-ს ამასთან კავშირი არ აქვს.
could not read Auth username from stdin ავთენტიფიკაციის პრობლემად გამოიყურება და ასე არ არის. OpenVPN-მა სცადა მომხმარებლის სახელის სტანდარტული შეყვანიდან მოთხოვნა, წაკითხვადი ვერაფერი იპოვა და გაჩერდა მანამ, სანამ სერვერს დაუკავშირდებოდა. ანგარიში შეიძლება სრულიად ვალიდური იყოს; უბრალოდ პროცესს არავინ ჰყავს საკითხავი.
ამიტომ პირველი სასარგებლო ნაბიჯია იმის დადასტურება, თუ რას კითხულობს კლიენტი, და არა კავშირის ხელახლა ცდა ან სერვერის მხარეს პარამეტრების შეცვლა. გაიარეთ ქვემოთ მოცემული შემოწმებები თანმიმდევრობით და გაჩერდით პირველ ჩავარდნილზე.
წაიკითხეთ შეცდომა როგორც ლოკალური შეყვანის ჩავარდნა
როცა auth-user-pass ფაილის არგუმენტის გარეშე ჩნდება, კლიენტი კითხვას ელოდება. ინტერაქტიულ გარსში ეს მოთხოვნა მუშაობს, რადგან პროცესს ტერმინალი აქვს. systemd-ის, cron დავალების ან კონტეინერის ქვეშ სტანდარტული შეყვანა ჩვეულებრივ ცარიელია და წაკითხვა მაშინვე ბრუნდება იმ შეცდომით, რომელსაც ხედავთ.
შეტყობინება ასევე ასახელებს ჩავარდნილ ველს, მომხმარებლის სახელს ან პაროლს, რაც გვიჩვენებს, რამდენად შორს წავიდა წაკითხვა. მომხმარებლის სახელის არარსებობა ნიშნავს, რომ პროცესმა საერთოდ ვერაფერი წაიკითხა. წარმატებული მომხმარებლის სახელის შემდეგ პაროლის არარსებობა ნიშნავს, რომ შეყვანის ნაკადი ორ წაკითხვას შორის დასრულდა, რაც ტიპიურია ნახევრად დაწერილი ფაილის ან დახურული მილისთვის.
სხვა რამის შეცვლამდე დაადასტურეთ თავად კლიენტის ხედვა. გაუშვით იგი წინა პლანზე იმავე კონფიგურაციითა და იმავე მომხმარებლით და დააკვირდით, გამოჩნდება თუ არა მოთხოვნა. თუ ის თქვენს გარსში ჩნდება, მაგრამ სერვისის მენეჯერის ქვეშ არა, განსხვავება შეყვანის წყაროშია და არა რწმუნებებში. unit ფაილისა და თქვენი გარსის გარემოს სწრაფი შედარება ჩვეულებრივ აჩვენებს, რომელი აწვდის ტერმინალს.
მიეცით სერვისს მხარდაჭერილი რწმუნებების წყარო
უყურადღებო რეჟიმისთვის მხარდაჭერილი წყაროა რწმუნებების ფაილი, რომელიც არგუმენტად გადაეცემა auth-user-pass-ს. ფაილი იკითხება როგორც ჩვეულებრივი ტექსტი: პირველი ხაზი მომხმარებლის სახელია, მეორე — პაროლი. მიუთითეთ მასზე აბსოლუტური ბილიკით, მაგალითად /etc/openvpn/client/creds , რათა სერვისის ანგარიშის სამუშაო დირექტორიამ ვერ შეცვალოს დირექტივის მნიშვნელობა.
ნებართვებს იგივე მნიშვნელობა აქვს, რაც ბილიკს. ფაილი უნდა იყოს წაკითხვადი კლიენტის გამშვები ანგარიშისთვის და არა ყველასთვის, და უნდა ეკუთვნოდეს სერვისის ანგარიშს ან root-ს ჯგუფით, რომელიც სერვისს მოიცავს. შეამოწმეთ წაკითხვადობა იმ ანგარიშის სახელით, შიგთავსის დაბეჭდვის გარეშე.
ფარდობითი ბილიკი ჩუმი ჩავარდნის რეჟიმია. პროფილი შეიძლება ერთ დირექტორიაში იყოს, სანამ systemd პროცესს სხვაგან უშვებს, ამიტომ თქვენს გარსში გადაწყვეტილი ფაილი სერვისისთვის არ გადაწყდება. გადაიტანეთ რწმუნებები ფიქსირებულ ადგილას და მიუთითეთ მათზე აბსოლუტურად. შემდეგ ერთხელ გაუშვით სერვისი და დაადასტურეთ, რომ იგივე ბილიკი გამოიყენება, ნაცვლად პროფილის რედაქტორის ხედვის ნდობისა.
თუ განლაგება მოითხოვს ერთჯერად კოდს ან სხვა ინტერაქტიულ გამოწვევას, გადაწყვიტეთ, ნამდვილად უჭერს თუ არა მას კლიენტის სამუშაო ნაკადი უყურადღებოდ. სტატიკური პაროლის მქონე ფაილი ვერ უპასუხებს მბრუნავ კოდს და უპასუხადი მოთხოვნის გამეორება ინფორმაციას არ მატებს.
რატომ არ დაეხმარება script-security
script-security აკონტროლებს, შეიძლება თუ არა კლიენტმა სკრიპტების გაშვება და რამდენი გადასცეს მათ, მათ შორის, შეიძლება თუ არა პაროლის სკრიპტისთვის გარემოს ცვლადით გადაცემა. ის არაფერს ამბობს იმაზე, საიდან მოდის თავდაპირველად მომხმარებლის სახელი და პაროლი.
უფრო მაღალ დონეზე აწევა ჩვეულებრივი რეფლექსია, რადგან შეტყობინება Auth-ს ახსენებს, მაგრამ ეს ცვლის სკრიპტების ნებართვებს და არა შეყვანის წყაროს, და აფართოებს იმას, რისი გაშვებაც კლიენტს შეუძლია. თუ დამხმარე სკრიპტი დიზაინის ნაწილია, ჯერ შეასწორეთ შეყვანის წყარო და შეინარჩუნეთ უსაფრთხოების დონე განლაგებისთვის საჭირო უმცირეს მნიშვნელობაზე.
მართვის ინტერფეისი ლეგიტიმური ალტერნატივაა. frontend-ს შეუძლია მასთან დაკავშირება, რწმუნებების მოთხოვნის მიღება და მომხმარებლის სახელითა და პაროლით პასუხი, ასე მუშაობს ზოგიერთი GUI. თუ იყენებთ, მიამაგრეთ ლოკალურ მისამართს, დაიცავით მართვის პაროლის ფაილით და შეზღუდეთ, ვის შეუძლია დაკავშირება, რადგან ეს კლიენტის მართვის არხია.
შეამოწმეთ შემდეგი ეტაპი მას შემდეგ, რაც კლიენტი ფაილს წაიკითხავს
როგორც კი კლიენტს რწმუნებების წაკითხვა შეეძლება, შემდეგი ჩავარდნა სერვერთან რეალური გაცვლაა და მის შეტყობინებას სხვა მნიშვნელობა აქვს. ამ ეტაპზე ავთენტიფიკაციის ჩავარდნა ნიშნავს, რომ სერვერმა ანგარიში უარყო; გამოწვევის პასუხი ნიშნავს, რომ სერვერს სხვა ფაქტორი სურს. მათ მოეპყარით როგორც ახალ პრობლემებს და არა როგორც იმავეს გამეორებას.
გამოსცადეთ მთელი გზა ისე, როგორც სერვისი გაუშვებს მას: იგივე ანგარიში, იგივე სამუშაო დირექტორია, იგივე unit გარემო. კავშირი, რომელიც მუშაობს მხოლოდ თქვენი გარსიდან გაშვებისას, ნიშანია, რომ გარემოს ცვლადი ან ტერმინალი ჯერ კიდევ ნაკადის ნაწილია.
შემდეგ შეინახეთ საიდუმლოებები იქ, სადაც უნდა. ბრძანების ხაზის არგუმენტებში პაროლები პროცესების ცხრილში ჩანს, ხოლო გამართვის გამოსავალში მყოფი პაროლები ბილეთებში ხვდება. გამოიყენეთ დაცული ფაილი ან მართვის ინტერფეისი, შეინახეთ ჟურნალები ისეთ დონეზე, რომელიც რწმუნებებს არ იმეორებს, და შეცვალეთ ფაილი, როცა წვდომის მქონე ვინმე წავა.
ჩამონათვალი: რწმუნებების აბსოლუტური ბილიკი, წაკითხვადი როგორც სერვისის ანგარიში, ტერმინალი არ არის საჭირო, script-security თავის მინიმუმზე, მართვის ინტერფეისი მხოლოდ თუ დამაგრებული და ავთენტიფიცირებულია, და მიღებული სერვერის პასუხი განიხილება როგორც ცალკე მოვლენა.