رفع مشکل: OpenVPN نتوانست نام کاربری Auth را از ورودی استاندارد بخواند
خطای «could not read Auth username from stdin» در OpenVPN یک شکست محلی در ورودی است. به سرویس یک منبع خواندنی برای اطلاعات ورود بدهید؛ script-security ربطی به آن ندارد.
could not read Auth username from stdin شبیه یک مشکل احراز هویت به نظر میرسد و چنین نیست. OpenVPN تلاش کرد نام کاربری را از ورودی استاندارد بپرسد، چیز خواندنیای پیدا نکرد و پیش از آنکه حتی با سرور تماس بگیرد متوقف شد. ممکن است حساب کاملاً معتبر باشد؛ فقط فرایند کسی را برای پرسیدن ندارد.
به همین دلیل نخستین گام مفید تأیید این است که کلاینت چه چیزی میخواند، نه تلاش دوباره برای اتصال یا تغییر تنظیمات سمت سرور. بررسیهای زیر را به ترتیب انجام دهید و در نخستین موردی که شکست میخورد توقف کنید.
خطا را یک شکست محلی در ورودی بخوانید
وقتی auth-user-pass بدون آرگومان فایل ظاهر میشود، کلاینت انتظار دارد بپرسد. در یک پوسته تعاملی این پرسش کار میکند چون فرایند یک ترمینال دارد. زیر systemd، یک کار cron یا یک کانتینر، ورودی استاندارد معمولاً خالی است و خواندن بلافاصله با همان خطایی که میبینید برمیگردد.
پیام همچنین نام فیلدی را که شکست خورده میآورد، نام کاربری یا گذرواژه، که نشان میدهد خواندن تا کجا پیش رفته است. نبود نام کاربری یعنی فرایند هیچ چیز نخوانده است. نبود گذرواژه پس از نام کاربری موفق یعنی جریان ورودی میان دو خواندن تمام شده، که برای فایلی نیمه نوشته یا لولهای بسته معمول است.
پیش از تغییر هر چیز دیگری، دید خود کلاینت را تأیید کنید. آن را در پیشزمینه با همان پیکربندی و همان کاربر اجرا کنید و ببینید آیا پرسش ظاهر میشود. اگر در پوسته شما ظاهر شد ولی زیر مدیر سرویس نه، تفاوت در منبع ورودی است نه در اطلاعات ورود. مقایسه سریع فایل واحد و محیط پوسته شما معمولاً نشان میدهد کدام یک ترمینال فراهم میکند.
به سرویس یک منبع اطلاعات ورود پشتیبانیشده بدهید
منبع پشتیبانیشده برای اجرای بدون نظارت یک فایل اطلاعات ورود است که بهعنوان آرگومان به auth-user-pass داده میشود. فایل بهصورت متن ساده خوانده میشود: خط اول نام کاربری و خط دوم گذرواژه است. با یک مسیر مطلق مانند /etc/openvpn/client/creds به آن اشاره کنید تا دایرکتوری کاری حساب سرویس نتواند معنای دستور را تغییر دهد.
مجوزها بهاندازه مسیر مهماند. فایل باید برای حسابی که کلاینت را اجرا میکند خواندنی باشد و نه برای همه، و باید متعلق به حساب سرویس یا root با گروهی باشد که سرویس را در بر میگیرد. خواندنیبودن را بهعنوان همان حساب بررسی کنید، بدون چاپ محتوا.
مسیر نسبی حالت شکست خاموش است. پروفایل ممکن است در یک دایرکتوری باشد در حالی که systemd فرایند را جای دیگری شروع میکند، بنابراین فایلی که در پوسته شما باز میشود برای سرویس باز نمیشود. اطلاعات ورود را به مکانی ثابت منتقل کنید و بهصورت مطلق به آن ارجاع دهید. سپس سرویس را یک بار شروع کنید و تأیید کنید که همان مسیر استفاده میشود، نه اینکه به دید ویرایشگر پروفایل اعتماد کنید.
اگر استقرار به کد یکبارمصرف یا چالش تعاملی دیگری نیاز دارد، تصمیم بگیرید که آیا جریان کار کلاینت واقعاً از آن بدون نظارت پشتیبانی میکند. فایلی با گذرواژه ثابت نمیتواند به کدی که تغییر میکند پاسخ دهد، و تلاش دوباره برای پرسشی که پاسخ ندارد اطلاعاتی نمیافزاید.
چرا script-security کمکی نمیکند
script-security کنترل میکند که آیا کلاینت میتواند اسکریپتها را اجرا کند و چه مقدار میتواند به آنها بدهد، از جمله اینکه آیا گذرواژه میتواند از طریق متغیر محیطی به اسکریپت داده شود. درباره اینکه نام کاربری و گذرواژه از کجا میآیند چیزی نمیگوید.
بالا بردن آن به سطحی بالاتر واکنشی رایج است چون پیام Auth را ذکر میکند، اما مجوزهای اسکریپت را تغییر میدهد نه منبع ورودی را، و آنچه کلاینت میتواند اجرا کند را گستردهتر میکند. اگر اسکریپت کمکی بخشی از طراحی است، ابتدا منبع ورودی را درست کنید و سطح امنیت را در کمترین مقداری که استقرار نیاز دارد نگه دارید.
رابط مدیریت گزینه جایگزین مشروعی است. یک فرانتاند میتواند به آن متصل شود، درخواست اطلاعات ورود را دریافت کند و با نام کاربری و گذرواژه پاسخ دهد، که برخی GUIها همینگونه کار میکنند. اگر از آن استفاده میکنید، آن را به یک نشانی محلی ببندید، با فایل گذرواژه مدیریت محافظت کنید و محدود کنید چه کسی میتواند متصل شود، زیرا کانال کنترلی کلاینت است.
مرحله بعد را پس از خواندن فایل توسط کلاینت بررسی کنید
وقتی کلاینت میتواند اطلاعات ورود را بخواند، شکست بعدی یک تبادل واقعی با سرور است و پیام آن معنای دیگری دارد. شکست احراز هویت در آن مرحله یعنی سرور حساب را رد کرده؛ پاسخ چالش یعنی سرور عامل دیگری میخواهد. آنها را مشکلهای تازه بدانید نه تکرار همان مشکل.
کل مسیر را همانگونه که سرویس اجرا خواهد کرد آزمایش کنید: همان حساب، همان دایرکتوری کاری، همان محیط واحد. اتصالی که فقط هنگام شروع از پوسته شما کار میکند نشانه آن است که یک متغیر محیطی یا یک ترمینال هنوز بخشی از جریان است.
سپس رازها را همانجا که باید نگه دارید. گذرواژههای موجود در آرگومانهای خط فرمان در جدول فرایندها دیده میشوند و گذرواژههای موجود در خروجی اشکالزدایی به تیکتها میرسند. از فایل محافظتشده یا رابط مدیریت استفاده کنید، گزارشها را در سطحی نگه دارید که اطلاعات ورود را تکرار نکند، و فایل را هنگامی که هر کسی با دسترسی خارج میشود تغییر دهید.
فهرست بررسی: مسیر مطلق اطلاعات ورود، خواندنی بهعنوان حساب سرویس، بدون نیاز به ترمینال، script-security در کمینه، رابط مدیریت فقط اگر متصل و تأییدشده باشد، و پاسخ سرور حاصل بهعنوان رویدادی جداگانه تلقی شود.