--key-password của OpenConnect có phải mật khẩu tài khoản VPN của bạn?
Tùy chọn --key-password của OpenConnect mở khóa một khóa riêng cục bộ. Mật khẩu tài khoản xác thực tại cổng, và cái này không bao giờ thay thế cái kia.
Hãy đọc tên tùy chọn theo nghĩa đen. Nó đặt tên cho một khóa, và sự nhầm lẫn bắt đầu khi tệp đang được mở khóa bị nhầm với tài khoản đang được xác thực. Dán mật khẩu tài khoản vào tùy chọn đó và ứng dụng khách sẽ cố mở một tệp khóa bằng nó, việc này thất bại vì những lý do không liên quan gì đến đăng nhập VPN.
Phần khó hiểu là một kết nối có thể cần cả hai bí mật một cách hợp lệ. Xác thực bằng chứng chỉ máy khách có thể cần một khóa được mã hóa, và cùng một cổng vẫn có thể thực hiện trao đổi xác thực người dùng sau khi chấp nhận chứng chỉ. Không bí mật nào thỏa mãn giai đoạn kia, và thất bại ở cái này nhìn từ bên ngoài rất giống thất bại ở cái kia.
Hai bí mật, hai nhiệm vụ khác nhau
Hãy đọc vai trò như quyền truy cập tệp so với quyền vào mạng. Mật khẩu khóa giải mã khóa riêng PEM được chỉ định trong --sslkey để chứng chỉ máy khách TLS có thể được trình bày. Việc giải mã đó diễn ra cục bộ, bên trong tiến trình máy khách, và bản thân cụm mật khẩu không bao giờ đi tới cổng. Cổng nhìn thấy chứng chỉ và một chữ ký tạo bằng khóa. Hướng dẫn của OpenConnect đặt --key-password cạnh --certificate và --sslkey, và trên các bản dựng có thể dùng khóa lưu trong TPM, cùng tùy chọn đó mang thay vào đó mật khẩu của khóa gốc lưu trữ.
Mật khẩu tài khoản thuộc loại khác. Nó đi vào trao đổi xác thực: một biểu mẫu tên người dùng và mật khẩu, một token, một vòng SAML hoặc một tổ hợp nào đó mà cổng công bố. Một số triển khai hoàn toàn không hỏi nó khi chứng chỉ là yếu tố duy nhất, và một số vẫn hỏi ngay cả sau khi có chứng chỉ, vì chứng chỉ chứng minh thiết bị còn tài khoản chứng minh con người.
Trộn hai thứ với nhau tạo ra những lỗi gây hiểu nhầm. Cổng từ chối đăng nhập thường báo lỗi xác thực, trong khi cụm mật khẩu khóa sai thường thất bại sớm hơn, khi lớp TLS không đọc được tệp khóa. Đó là những giai đoạn khác nhau với cách khắc phục khác nhau, và tên gọi đủ giống nhau để người ta hoán đổi chúng rồi đuổi theo nhật ký sai. Hãy ghi lại lời nhắc nào đã xuất hiện trước khi bạn đổi bất kỳ cài đặt nào, vì câu chữ của lời nhắc là chẩn đoán rẻ nhất bạn có.
Khi nào thực sự cần mật khẩu khóa
Tùy chọn chỉ có nghĩa khi có một khóa được mã hóa để mở. Nếu bạn kết nối bằng tên người dùng và mật khẩu và không có chứng chỉ máy khách, --key-password không có gì để tác động, và thêm nó vào không thay đổi điều gì. Nếu bạn kết nối với --certificate và --sslkey, chính định dạng của tệp khóa quyết định có hỏi cụm mật khẩu hay không.
Cả hai bí mật trong một lệnh là chuyện phổ biến trong môi trường được quản lý: chứng chỉ thiết bị trong một khóa được mã hóa, cộng với đăng nhập cho từng người dùng. Trình tự đúng là để ứng dụng khách hỏi cụm mật khẩu khóa cục bộ, hoàn tất bắt tay chứng chỉ, rồi xử lý riêng lời nhắc tài khoản của cổng. Việc cố điền trước cả hai qua một script dùng lại chính là nơi sự nhầm lẫn thường bắt đầu.
Một chẩn đoán hữu ích là xem khi nào thất bại xảy ra. Nếu ứng dụng khách dừng trước khi bất kỳ xác thực mạng nào bắt đầu, hãy nghi tệp khóa, định dạng của nó hoặc cụm mật khẩu. Nếu phiên TLS được thiết lập và sau đó cổng từ chối người dùng, khóa đã làm xong việc của nó và vấn đề nằm ở trao đổi tài khoản.
Giữ cả hai bí mật ngoài lịch sử shell
Các đối số dòng lệnh có thể bị người dùng cục bộ khác đọc qua bảng tiến trình và thường bị ghi lại trong lịch sử shell, script và bản ghi hỗ trợ. OpenConnect có thể đọc mật khẩu tài khoản từ đầu vào chuẩn với --passwd-on-stdin, và cụm mật khẩu khóa có thể đến từ lời nhắc tương tác hoặc một tác tử thay vì đối số. Không cơ chế nào tự nó làm bí mật an toàn, nhưng cả hai đều giữ nó xa những nơi lộ liễu nhất.
Tệp cũng xứng đáng được chăm sóc như vậy. Một script ghi cụm mật khẩu vào tệp tạm nên tạo tệp với quyền hạn chế, xóa nó khi thoát và tránh các thư mục ai cũng đọc được. Cụm mật khẩu còn sống sau phiên trong một thư mục tạm là bản sao mà bạn quên tạo. Biến môi trường hiển thị với tiến trình con và thường bị công cụ gỡ lỗi in ra, nên chúng không phải là cải tiến miễn phí so với đối số.
Đầu ra chẩn đoán là chỗ rò rỉ âm thầm. Nhật ký ứng dụng khách ở mức chi tiết cao hơn có thể hiển thị nội dung yêu cầu hoặc giá trị tùy chọn, và bản ghi terminal được sao chép rất dễ dán vào phiếu, nên hãy đọc đầu ra trước khi chia sẻ.
Nút desktop chết là một lỗi khác
Một mục VPN trên desktop hiển thị vòng xoay rồi không làm gì thường hoàn toàn không phải vấn đề xác thực. Nút đó thuộc về trình quản lý mạng, một applet của nhà cung cấp hoặc một plugin khởi chạy OpenConnect thay bạn, và một thành phần thiếu hoặc hồ sơ không đọc được có thể tạo ra đúng triệu chứng đó. Tìm xem nút khởi chạy tiến trình nào và đọc lỗi của nó trước khi chạm vào thông tin đăng nhập.
Thật hấp dẫn khi nới lỏng xác minh chứng chỉ hoặc tắt một kiểm tra khi GUI từ chối kết nối. Điều đó biến lỗi tích hợp máy khách thành hạ thấp bảo mật và hiếm khi sửa được vấn đề khởi chạy. Giữ nguyên xác minh máy chủ, xác nhận hồ sơ trỏ tới cổng dự định, và kiểm tra xem trình trợ giúp mà GUI mong đợi có thực sự được cài đặt không.
Một danh sách kiểm tra ngắn phân tách các trường hợp. Lỗi cục bộ trước khi bất kỳ gói nào ra ngoài chỉ vào khóa hoặc bản cài ứng dụng khách. Cổng từ chối sau phiên TLS chỉ vào trao đổi tài khoản. Một nút không bao giờ khởi chạy ứng dụng khách chỉ vào tích hợp desktop. Ba lỗi khác nhau, một trong số đó là mật khẩu bạn sắp dán vào ô sai.