Sửa lỗi: OpenVPN không đọc được tên người dùng Auth từ đầu vào chuẩn

could not read Auth username from stdin trông giống một vấn đề xác thực và không phải vậy. OpenVPN đã cố gắng hỏi tên người dùng trên đầu vào chuẩn, không tìm thấy gì đọc được và dừng lại trước khi liên hệ với máy chủ. Tài khoản có thể hoàn toàn hợp lệ; tiến trình đơn giản là không có ai để hỏi.

Vì vậy bước hữu ích đầu tiên là xác nhận những gì máy khách đang đọc, không phải thử lại kết nối hay thay đổi cài đặt phía máy chủ. Hãy thực hiện các kiểm tra dưới đây theo thứ tự và dừng ở kiểm tra đầu tiên thất bại.

Đọc lỗi như một thất bại đầu vào cục bộ

Khi auth-user-pass xuất hiện mà không có đối số tệp, máy khách mong đợi hỏi. Trong một shell tương tác, lời nhắc đó hoạt động vì tiến trình sở hữu một terminal. Dưới systemd, một tác vụ cron hoặc một container, đầu vào chuẩn thường trống, và lần đọc trả về ngay lập tức với lỗi bạn đang thấy.

Thông báo cũng nêu trường bị lỗi, tên người dùng hoặc mật khẩu, cho biết lần đọc đã đi được bao xa. Thiếu tên người dùng nghĩa là tiến trình không đọc được gì cả. Thiếu mật khẩu sau khi tên người dùng thành công nghĩa là luồng đầu vào kết thúc giữa hai lần đọc, điều thường thấy với tệp được ghi dở hoặc đường ống đã đóng.

Xác nhận cách nhìn của chính máy khách trước khi thay đổi bất cứ điều gì khác. Chạy nó ở tiền cảnh với cùng cấu hình và cùng người dùng, và xem lời nhắc có xuất hiện không. Nếu nó xuất hiện trong shell của bạn nhưng không dưới trình quản lý dịch vụ, khác biệt nằm ở nguồn đầu vào, không phải ở thông tin xác thực. So sánh nhanh tệp unit với môi trường shell của bạn thường cho thấy cái nào cung cấp terminal.

Cấp cho dịch vụ một nguồn thông tin xác thực được hỗ trợ

Nguồn được hỗ trợ cho chế độ chạy không giám sát là một tệp thông tin xác thực được truyền làm đối số cho auth-user-pass. Tệp được đọc dưới dạng văn bản thuần: dòng đầu tiên là tên người dùng, dòng thứ hai là mật khẩu. Trỏ tới nó bằng một đường dẫn tuyệt đối như /etc/openvpn/client/creds , để thư mục làm việc của tài khoản dịch vụ không thể thay đổi ý nghĩa của chỉ thị.

Quyền quan trọng như đường dẫn. Tệp phải đọc được bởi tài khoản chạy máy khách và không phải bởi mọi người khác, và nên thuộc sở hữu của tài khoản dịch vụ hoặc root với một nhóm bao gồm dịch vụ. Kiểm tra khả năng đọc với tư cách tài khoản đó, mà không in nội dung.

Đường dẫn tương đối là chế độ thất bại âm thầm. Hồ sơ có thể nằm trong một thư mục trong khi systemd khởi động tiến trình ở nơi khác, vì vậy một tệp phân giải được trong shell của bạn không phân giải được cho dịch vụ. Di chuyển thông tin xác thực đến một vị trí cố định và tham chiếu tuyệt đối. Sau đó khởi động dịch vụ một lần và xác nhận cùng đường dẫn được dùng, thay vì tin vào chế độ xem của trình soạn thảo hồ sơ.

Nếu việc triển khai yêu cầu mã dùng một lần hoặc một thách thức tương tác khác, hãy quyết định liệu quy trình làm việc của máy khách có thực sự hỗ trợ điều đó mà không cần giám sát. Một tệp có mật khẩu tĩnh không thể trả lời mã luân phiên, và thử lại một lời nhắc không thể trả lời không thêm thông tin.

Vì sao script-security không giúp được

script-security kiểm soát việc máy khách có được chạy script hay không và được truyền bao nhiêu cho chúng, bao gồm việc có thể trao mật khẩu cho script qua một biến môi trường hay không. Nó không nói gì về nơi tên người dùng và mật khẩu đến từ đầu.

Nâng nó lên mức cao hơn là phản xạ thường gặp vì thông báo nhắc đến Auth, nhưng nó thay đổi quyền của script chứ không phải nguồn đầu vào, và mở rộng những gì máy khách được thực thi. Nếu một script phụ trợ là một phần của thiết kế, hãy sửa nguồn đầu vào trước và giữ mức bảo mật ở giá trị thấp nhất mà việc triển khai cần.

Giao diện quản lý là một lựa chọn thay thế hợp lệ. Một frontend có thể kết nối tới nó, nhận yêu cầu thông tin xác thực và trả lời bằng tên người dùng và mật khẩu, đó là cách một số GUI hoạt động. Nếu bạn dùng nó, hãy gắn nó vào một địa chỉ cục bộ, bảo vệ nó bằng một tệp mật khẩu quản lý và giới hạn ai có thể kết nối, vì đó là kênh điều khiển của máy khách.

Xác minh giai đoạn tiếp theo sau khi máy khách đọc tệp

Khi máy khách đọc được thông tin xác thực, thất bại tiếp theo là một trao đổi thực sự với máy chủ, và thông báo của nó có ý nghĩa khác. Thất bại xác thực ở giai đoạn đó nghĩa là máy chủ đã từ chối tài khoản; phản hồi thách thức nghĩa là máy chủ muốn một yếu tố khác. Hãy coi chúng là vấn đề mới chứ không phải cùng một vấn đề lặp lại.

Kiểm tra toàn bộ đường đi như cách dịch vụ sẽ chạy nó: cùng tài khoản, cùng thư mục làm việc, cùng môi trường unit. Một kết nối chỉ hoạt động khi được khởi động từ shell của bạn là dấu hiệu rằng một biến môi trường hoặc một terminal vẫn là một phần của luồng.

Sau đó giữ bí mật ở nơi chúng thuộc về. Mật khẩu trong đối số dòng lệnh xuất hiện trong bảng tiến trình, và mật khẩu trong đầu ra gỡ lỗi rơi vào phiếu hỗ trợ. Dùng một tệp được bảo vệ hoặc giao diện quản lý, giữ nhật ký ở mức không lặp lại thông tin xác thực, và luân chuyển tệp khi bất kỳ ai có quyền truy cập rời đi.

Danh sách kiểm tra: đường dẫn thông tin xác thực tuyệt đối, đọc được với tư cách tài khoản dịch vụ, không cần terminal, script-security được giữ ở mức tối thiểu, giao diện quản lý chỉ khi được gắn và xác thực, và phản hồi máy chủ kết quả được coi là một sự kiện riêng.