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 хамгийн багадаа, удирдлагын интерфэйс зөвхөн холбогдсон, баталгаажсан бол, үүнээс гарсан серверийн хариуг тусдаа үйл явдал гэж үзэх.

Холбоотой нийтлэлүүд