Sử dụng Ubuntu 18.04 sau khi nâng cấp từ 16.04. Hiện tại không có ý định nâng cấp lên 20.04.
Tôi gặp sự cố với ecryptfs khi đăng nhập vào một trong hai người dùng. tôi đang làm việc từ một thiết bị đầu cuối vì sợ rằng các hoạt động tự động của GUI có thể làm phức tạp mọi thứ.
Có một nguyên nhân có thể xảy ra cho những rắc rối này: Tôi đã kết thúc với hai bộ chữ ký xử lý cùng một thư mục được mã hóa.
Chỉnh sửa ghi chú cho người đọc sớm: các phần chứa các thay đổi, một khi lỗi gắn kết đã được sắp xếp độc lập. Ý chính của phần 4 vẫn giữ nguyên. Câu chuyện ngắn hơn.
1. Tình huống ban đầu khi đăng nhập (đã chỉnh sửa)
Sau khi tôi đăng nhập, đôi khi tôi nhận được thông báo rằng chữ ký FNEK không khả dụng.
[ 768.391515] Không thể tìm thấy khóa có mô tả: [chữ ký fnek]
[ 768.392001] process_request_key_err: Không có khóa
[ 768.392001] Không thể tìm thấy khóa hợp lệ trong khóa phiên người dùng cho sig được chỉ định trong tùy chọn gắn kết: [chữ ký fnek]
2. Kiểm tra cụm mật khẩu và khóa (đã chỉnh sửa): vượt qua
Tại dấu nhắc ecryptfs-unwrap-cụm mật khẩu đầu ra giống nhau gắn cụm mật khẩu Tôi đã có kể từ khi tôi tạo hồ sơ người dùng (năm trước).
Điều này được liên kết với hai chữ ký (tiêu chuẩn và kiểu FNEK) là ecryptfs-add-passphrase --fnek nói: những điều này thường xuyên được ghi lại trong /home/.ecryptfs/user/.ecryptfs/Private.sig và trong thực tế, Mà còn Trong hiển thị bàn phím.
3. Mount thư mục mã hóa (đã chỉnh sửa): pass
tôi kiểm tra lại gắn kết và tìm dòng:
/home/.ecryptfs/user/.Private trên /home/user gõ ecryptfs(rw,nosuid,nodev,relatime,
ecryptfs_fnek_sig=**chữ ký của fnek**,
ecryptfs_sig=**chữ ký tiêu chuẩn**,
ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)
Tôi thấy dòng này ổn: nó tương ứng với các cài đặt cho một người dùng khác trong máy tính mà quá trình đăng nhập và giải mã vẫn diễn ra tốt đẹp.
4. Bất ngờ: không tìm thấy một khóa/chữ ký phụ nào
Thay vì hiển thị thư mục được giải mã, ls/nhà/người dùng tạo thông báo lỗi này (thực ra là phần đuôi của dmesg):
[ 3068.228947] Không thể tìm thấy khóa có mô tả: [MỘT CHỮ KÝ THÊM]
[ 3068.228948] process_request_key_err: Không có khóa
[ 3068.228948] ecryptfs_parse_tag_70_packet: Lỗi khi cố tìm mã xác thực cho fnek sig [MỘT CHỮ KÝ THÊM]; rc = [-2]
Cái này MỘT CHỮ KÝ THÊM Là chữ ký hoàn toàn khác hơn những cái ở trên cho phép gắn kết.
Tôi cũng biết chính xác nó là gì. MỘT CHỮ KÝ THÊM là chữ ký tiêu chuẩn được tạo ra khi tôi nhập mật khẩu đăng nhập thay cho gắn kết mật khẩu Trong ecryptfs-add-cụm mật khẩu hoặc trong một số hoạt động tương đương khác, có lẽ ecryptfs-recovery-riêng tư và ecryptfs-mount-riêng tư quá.
5. Phân tích
Điều kỳ lạ là tôi không thể tìm thấy bất kỳ dấu vết nào của khóa giả mạo này trong các tệp bên trong /home/.ecryptfs/user/.ecryptfs và /root/.ecryptfs. Không có manh mối nào về việc ecryptfs lấy nó từ đâu.
Hôm qua, tôi đã quản lý để áp dụng thành công quy trình tương tự này trong môi trường trực tiếp USB (với các phím thông thường).
Hôm nay tôi đã thất bại trong việc sao chép thành công đó trong cùng một môi trường USB trực tiếp.
Do đó, một điều gì đó khá đột phá đã xảy ra, mà tôi hoàn toàn không thể hiểu được.
Tôi chắc chắn nghịch xung quanh. Tuy nhiên, tôi loại trừ việc đã đưa ra một lệnh quyết liệt như "vui lòng mã hóa lại mọi thứ bằng một cặp khóa mới", cũng bởi vì công cụ trình quản lý ecryptfs không thân thiện với người dùng.
Rất có thể, tôi đã nhập cụm mật khẩu đăng nhập thay vì cụm mật khẩu gắn kết một vài nơi. Về cơ bản, tôi đã rơi vào cái bẫy khét tiếng về mật khẩu đăng nhập/gắn kết của ecryptfs. Chúng là hai thứ khác nhau và ecryptfs hầu như không bận tâm đến việc nó muốn gì. Nhìn thấy ecryptfs và cụm mật khẩu đăng nhập so với cụm mật khẩu gắn kết.
6. Câu hỏi
- Làm thế nào để bạn giải thích yêu cầu này của một khóa nữa?
- Có manh mối nào về cách mà chiếc chìa khóa phụ này có thể lẻn vào được không?
- bất kỳ đề nghị trên làm thế nào để có được nó ra khỏi con đường, hoàn nguyên và yêu cầu các khóa gốc gắn kết và giải mã thư mục?
7. Nguồn
