Sau bốn tháng phát triển giải phóng , một triển khai máy khách và máy chủ mở để làm việc thông qua giao thức SSH 2.0 và SFTP.
Một cải tiến quan trọng trong việc phát hành OpenSSH 8.2 là khả năng sử dụng xác thực hai yếu tố bằng các thiết bị hỗ trợ giao thức , được phát triển bởi liên minh . U2F cho phép tạo mã thông báo phần cứng chi phí thấp để xác minh sự hiện diện vật lý của người dùng, tương tác với họ qua USB, Bluetooth hoặc NFC. Những thiết bị như vậy được quảng bá như một phương tiện xác thực hai yếu tố trên các trang web, đã được các trình duyệt lớn hỗ trợ và được sản xuất bởi nhiều nhà sản xuất khác nhau, bao gồm Yubico, Feitian, Thetis và Kensington.
Để tương tác với các thiết bị xác nhận sự hiện diện của người dùng, các loại khóa mới “ecdsa-sk” và “ed25519-sk” đã được thêm vào OpenSSH, sử dụng thuật toán chữ ký số ECDSA và Ed25519, kết hợp với hàm băm SHA-256. Các quy trình tương tác với mã thông báo được đặt trong thư viện trung gian, được tải theo cách tương tự như thư viện để hỗ trợ PKCS#11 và là trình bao bọc ở đầu thư viện , cung cấp các công cụ để giao tiếp với mã thông báo qua USB (giao thức FIDO U2F/CTAP 1 và FIDO 2.0/CTAP 2 được hỗ trợ). Thư viện trung gian libsk-libfido2 do các nhà phát triển OpenSSH chuẩn bị vào libfido2 cốt lõi, cũng như cho OpenBSD.
Để xác thực và tạo khóa, bạn phải chỉ định tham số “SecurityKeyProvider” trong cài đặt hoặc đặt biến môi trường SSH_SK_PROVIDER, cho biết đường dẫn đến thư viện bên ngoài libsk-libfido2.so (export SSH_SK_PROVIDER=/path/to/libsk-libfido2. Vì thế). Có thể xây dựng openssh với sự hỗ trợ tích hợp cho thư viện lớp (--with-security-key-buildin), trong trường hợp này, bạn cần đặt tham số “SecurityKeyProvider=internal”.
Tiếp theo, bạn cần chạy “ssh-keygen -t ecdsa-sk” hoặc nếu các khóa đã được tạo và định cấu hình, hãy kết nối với máy chủ bằng cách sử dụng “ssh”. Khi bạn chạy ssh-keygen, cặp khóa được tạo sẽ được lưu trong “~/.ssh/id_ecdsa_sk” và có thể được sử dụng tương tự như các khóa khác.
Khóa chung (id_ecdsa_sk.pub) phải được sao chép vào máy chủ trong tệp ủy quyền. Về phía máy chủ, chỉ có chữ ký số được xác minh và việc tương tác với mã thông báo được thực hiện ở phía máy khách (bạn không cần cài đặt libsk-libfido2 trên máy chủ nhưng máy chủ phải hỗ trợ loại khóa “ecdsa-sk”) . Khóa riêng được tạo (id_ecdsa_sk) về cơ bản là một tay cầm khóa, tạo thành khóa thực chỉ khi kết hợp với chuỗi bí mật được lưu trữ ở phía mã thông báo U2F. Nếu khóa id_ecdsa_sk rơi vào tay kẻ tấn công, để vượt qua xác thực, hắn cũng sẽ cần có quyền truy cập vào mã thông báo phần cứng, nếu không có mã thông báo riêng được lưu trong tệp id_ecdsa_sk sẽ vô dụng.
Ngoài ra, theo mặc định, khi thực hiện bất kỳ thao tác nào bằng khóa (cả trong quá trình tạo và trong khi xác thực), cần phải có xác nhận cục bộ về sự hiện diện vật lý của người dùng, chẳng hạn như đề xuất chạm vào cảm biến trên mã thông báo, điều này gây khó khăn cho việc thực hiện các cuộc tấn công từ xa vào các hệ thống có mã thông báo được kết nối. Là một tuyến phòng thủ khác, mật khẩu cũng có thể được chỉ định trong giai đoạn khởi động của ssh-keygen để truy cập vào tệp khóa.
Phiên bản mới của OpenSSH cũng đã thông báo về việc sắp ngừng sử dụng các thuật toán sử dụng hàm băm SHA-1 do hiệu quả của các cuộc tấn công va chạm với tiền tố nhất định (chi phí chọn va chạm ước tính khoảng 45 nghìn đô la). Trong một trong những bản phát hành sắp tới, họ có kế hoạch vô hiệu hóa theo mặc định khả năng sử dụng thuật toán chữ ký số khóa công khai “ssh-rsa”, được đề cập trong RFC gốc cho giao thức SSH và vẫn phổ biến trong thực tế (để kiểm tra việc sử dụng của ssh-rsa trong hệ thống của mình, bạn có thể thử kết nối qua ssh với tùy chọn “-oHostKeyAlgorithms=-ssh-rsa”).
Để quá trình chuyển đổi sang các thuật toán mới trong OpenSSH diễn ra suôn sẻ, trong bản phát hành trong tương lai, cài đặt UpdateHostKeys sẽ được bật theo mặc định, cài đặt này sẽ tự động di chuyển máy khách sang các thuật toán đáng tin cậy hơn. Các thuật toán được đề xuất để di chuyển bao gồm rsa-sha2-256/512 dựa trên RFC8332 RSA SHA-2 (được hỗ trợ kể từ OpenSSH 7.2 và được sử dụng theo mặc định), ssh-ed25519 (được hỗ trợ kể từ OpenSSH 6.5) và dựa trên ecdsa-sha2-nistp256/384/521 trên RFC5656 ECDSA (được hỗ trợ kể từ OpenSSH 5.7).
Trong OpenSSH 8.2, khả năng kết nối bằng “ssh-rsa” vẫn khả dụng, nhưng thuật toán này đã bị xóa khỏi danh sách CASSignatureAlgorithms, danh sách xác định các thuật toán được phép ký điện tử chứng chỉ mới. Tương tự, thuật toán diffie-hellman-group14-sha1 đã bị xóa khỏi thuật toán trao đổi khóa mặc định được hỗ trợ. Cần lưu ý rằng việc sử dụng SHA-1 trong chứng chỉ có liên quan đến rủi ro bổ sung, vì kẻ tấn công có không giới hạn thời gian để tìm kiếm xung đột cho chứng chỉ hiện có, trong khi thời gian tấn công vào khóa máy chủ bị giới hạn bởi thời gian chờ kết nối (LoginGraceTime ).
Chạy ssh-keygen hiện mặc định là thuật toán rsa-sha2-512, được hỗ trợ kể từ OpenSSH 7.2, thuật toán này có thể tạo ra sự cố tương thích khi cố xử lý các chứng chỉ được ký trong OpenSSH 8.2 trên các hệ thống chạy bản phát hành OpenSSH cũ hơn (để khắc phục sự cố khi Khi nào khi tạo chữ ký, bạn có thể chỉ định rõ ràng “ssh-keygen -t ssh-rsa” hoặc sử dụng thuật toán ecdsa-sha2-nistp256/384/521, được hỗ trợ kể từ OpenSSH 5.7).
Các thay đổi khác:
- Lệnh Bao gồm đã được thêm vào sshd_config, cho phép bạn đưa nội dung của các tệp khác vào vị trí hiện tại của tệp cấu hình (có thể sử dụng mặt nạ toàn cầu khi chỉ định tên tệp);
- Tùy chọn “không cần chạm” đã được thêm vào ssh-keygen, tùy chọn này vô hiệu hóa nhu cầu xác nhận vật lý quyền truy cập vào mã thông báo khi tạo khóa;
- Lệnh PubkeyAuthOptions đã được thêm vào sshd_config, lệnh này kết hợp nhiều tùy chọn khác nhau liên quan đến xác thực khóa chung. Hiện tại, chỉ hỗ trợ cờ "không cần chạm" để bỏ qua kiểm tra sự hiện diện vật lý nhằm xác thực mã thông báo. Bằng cách tương tự, tùy chọn “không cần chạm” đã được thêm vào tệp ủy quyền;
- Đã thêm tùy chọn "-O write-attestation=/path" vào ssh-keygen để cho phép ghi các chứng chỉ chứng thực FIDO bổ sung khi tạo khóa. OpenSSH chưa sử dụng các chứng chỉ này, nhưng sau này chúng có thể được sử dụng để xác minh rằng khóa được đặt trong cửa hàng phần cứng đáng tin cậy;
- Trong cài đặt ssh và sshd, giờ đây có thể đặt chế độ ưu tiên lưu lượng truy cập thông qua chỉ thị IPQoS (Hành vi mỗi chặng với nỗ lực thấp hơn);
- Trong ssh, khi đặt giá trị “AddKeysToAgent=yes”, nếu khóa không chứa trường nhận xét, nó sẽ được thêm vào ssh-agent chỉ ra đường dẫn đến khóa dưới dạng nhận xét. TRONG
ssh-keygen và ssh-agent hiện cũng sử dụng nhãn PKCS#11 và tên chủ đề X.509 thay vì đường dẫn thư viện làm nhận xét trong khóa; - Đã thêm khả năng xuất PEM cho khóa DSA và ECDSA sang ssh-keygen;
- Đã thêm một trình thực thi mới, ssh-sk-helper, được sử dụng để tách biệt thư viện truy cập mã thông báo FIDO/U2F;
- Đã thêm tùy chọn xây dựng “--with-zlib” vào ssh và sshd để biên dịch với sự hỗ trợ của thư viện zlib;
- Theo yêu cầu của RFC4253, cảnh báo về việc chặn truy cập do vượt quá giới hạn MaxStartups được cung cấp trong biểu ngữ hiển thị trong quá trình kết nối. Để đơn giản hóa chẩn đoán, tiêu đề quy trình sshd, hiển thị khi sử dụng tiện ích ps, hiện hiển thị số lượng kết nối hiện được xác thực và trạng thái giới hạn MaxStartups;
- Trong ssh và ssh-agent, khi gọi một chương trình để hiển thị lời mời trên màn hình, được chỉ định qua $SSH_ASKPASS, một cờ với loại lời mời hiện được truyền thêm: “confirm” - hộp thoại xác nhận (có/không), “none” ” - thông báo thông tin, “trống” — yêu cầu mật khẩu;
- Đã thêm thao tác chữ ký số mới "tìm hiệu trưởng" vào ssh-keygen để tìm kiếm tệp người ký được phép cho người dùng được liên kết với chữ ký số được chỉ định;
- Cải thiện hỗ trợ cách ly quy trình sshd trên Linux bằng cơ chế seccomp: tắt các lệnh gọi hệ thống IPC, cho phép clock_gettime64(), clock_nanosleep_time64 và clock_nanosleep().
Nguồn: opennet.ru