mount: Không có tập tin hoặc thư mục như vậy với phục hồi được mã hóa


12

Tôi đã phá hủy cài đặt Mint Linux của tôi. Tôi chỉ muốn truy cập vào cửa hàng từ xa của tôi. Vì vậy, những gì đã xảy ra là tôi đã gặp rắc rối với tập tin ICEmasterity trong thư mục nhà của tôi. Vì vậy, theo các hướng khác nhau trên internet, tôi đã đi đến kết luận rằng tôi có thể đặt thư mục chính theo cách đệ quy thành chmod 755 để cho phép tập tin đó hoạt động, cuối cùng tôi gặp vấn đề với việc tải hệ thống. Cuối cùng, bằng cách đặt thư mục chính thành quyền thực thi cho root là tôi có thể nhận được quyền truy cập đọc / ghi, nhưng sau đó tôi đặt lại máy của mình oh tại sao tôi lại thiết lập lại máy của mình !!! - bây giờ hệ thống đưa ra lỗi tương tự với ICEmasterity nhưng nó không bao giờ đưa tôi vào HĐH vì đĩa được mã hóa. Không có gì tôi đã thử dường như hoạt động và tôi không có hạt giống ban đầu.

frankenmint@honeybadger /home $ sudo ecryptfs-recover-private
INFO: Searching for encrypted private directories (this might take a while)...
INFO: Found [/home/.ecryptfs/frankenmint/.Private].
Try to recover this directory? [Y/n]: y
INFO: Found your wrapped-passphrase
Do you know your LOGIN passphrase? [Y/n] y
INFO: Enter your LOGIN passphrase...
Passphrase: 
Inserted auth tok with sig [979c6cdf80d2e44d] into the user session keyring
mount: No such file or directory
ERROR: Failed to mount private data at [/tmp/ecryptfs.Hy3BV96c].

Tôi thực sự lo lắng vì tôi có các tệp quan trọng trên đó được lưu trữ trên một máy ảo. Nếu tôi có thể truy cập vào các tệp đó thì tôi sẽ không phải lo lắng về việc thiết lập và bắt đầu lại

Câu trả lời:


13

Tôi thấy rằng chạy sudo bashvà sau đó chạy ecryptfs-recover-privatebằng root (chứ không phải thông qua sudo) đã làm việc. Không chắc chắn tại sao nó nên khác nhau.

Biên tập:

TL; DR:

# ecryptfs-unwrap-passphrase /mnt/crypt/.ecryptfs/user/.ecryptfs/wrapped-passphrase - | ecryptfs-add-passphrase --fnek -
    < Type your login password here >
Inserted auth tok with sig [aaaaaaaaaaaaaaaa] into the user session keyring
Inserted auth tok with sig [bbbbbbbbbbbbbbbb] into the user session keyring

Bạn sẽ không thấy lời nhắc và phải nhập mật khẩu đăng nhập, bị mù, vào lệnh trên.

Thay thế aaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbên dưới bằng chữ ký hex giữa các dấu ngoặc từ đầu ra ở trên, theo thứ tự:

# mount -i -t ecryptfs -o ecryptfs_sig=aaaaaaaaaaaaaaaa,ecryptfs_fnek_sig=bbbbbbbbbbbbbbbb,ecryptfs_cipher=aes,ecryptfs_key_bytes=16 /mnt/crypt/.ecryptfs/user/.Private /mnt/plain

Sơ bộ

Hóa ra chỉ chạy khi root không hoạt động đáng tin cậy đối với tôi; đôi khi nó đã làm, đôi khi nó đã không. Về cơ bản, ecryptfs có vẻ lỗi và khá thân thiện với người dùng, thường gây nhầm lẫn mật khẩu đăng nhập và gắn cụm mật khẩu. Sau khi đi xuống một hố thỏ sâu, tối, tôi có một số lời khuyên nên giúp đỡ. Các ghi chú này dành cho Ubuntu 17.10, ecryptfs-utils 111-0 và bạn nên trở thành root trước khi bắt đầu. Tôi giả sử bạn muốn gắn thư mục chính của mình từ /mnt/crypt(cần được gắn kết) vào /mnt/plainvà bạn nên thay thế userbằng tên người dùng.

Bắt đầu dễ dàng

Điều đầu tiên để thử là:

# ecryptfs-recover-private /mnt/crypt/.ecryptfs/user/.Private

Nếu điều này hoạt động, tốt, bạn may mắn. Nếu không, nó có thể đưa ra một thông báo lỗi từ mountkhoảng no such file or directory. Điều này cực kỳ sai lệch: điều thực sự có nghĩa là cụm mật khẩu gắn kết của bạn bị sai hoặc thiếu.

Nhận chữ ký

Đây là phần quan trọng: chúng ta cần xác minh ecryptfs thực sự đang thử (các) cụm mật khẩu gắn kết đúng. Các cụm mật khẩu phải được tải vào nhân Linux trước khi ecryptfs có thể gắn kết hệ thống tệp của bạn. ecryptfs yêu cầu kernel cho họ bằng chữ ký của họ. Chữ ký là một giá trị hex 16 byte (và không nhạy cảm về mặt mật mã). Bạn có thể tìm thấy chữ ký mật khẩu mà ecryptfs đang mong đợi:

# cat /mnt/crypt/.ecryptfs/user/.ecryptfs/Private.sig
aaaaaaaaaaaaaaaa
bbbbbbbbbbbbbbbb

Hãy nhớ những điều này. Mục tiêu là để có được các cụm mật khẩu với các chữ ký này được tải vào kernel và sau đó báo cho ecryptfs sử dụng chúng. Chữ ký đầu tiên ( aaaaaaaaaaaaaaaa) dành cho dữ liệu và chữ ký thứ hai ( bbbbbbbbbbbbbbbb) là Khóa mã hóa tên tệp (FNEK).

Lấy cụm mật khẩu gắn kết

Lệnh này sẽ yêu cầu bạn cung cấp cho bạn mật khẩu đăng nhập (với lời nhắc sai lệch) và xuất cụm mật khẩu gắn kết của bạn :

# ecryptfs-unwrap-passphrase /mnt/crypt/.ecryptfs/user/.ecryptfs/wrapped-passphrase

Sao chép này nhưng hãy cẩn thận !! , vì điều này cực kỳ nhạy cảm về mật mã, chìa khóa của vương quốc.

Hãy thử gắn kết tương tác

Điều tiếp theo để thử là:

# mount -t ecryptfs /mnt/crypt/.ecryptfs/user/.Private /mnt/plain

Điều quan trọng ở đây là mountcần cụm mật khẩu gắn kết (siêu nhạy cảm) mà chúng tôi vừa sao chép (không phải mật khẩu đăng nhập của bạn).

Điều này sẽ hỏi bạn một số câu hỏi và bạn có thể chấp nhận mặc định ngoại trừ nói có với Enable filename encryption. Nó có thể cung cấp cho bạn một cảnh báo và yêu cầu lưu trữ chữ ký; bạn có thể nói đồng ý với cả hai, nhưng hãy kiểm tra kỹ xem bạn đã có cụm mật khẩu gắn kết đúng chưa.

Bạn sẽ thấy các tùy chọn mountđã quyết định thử cho bạn:

Attempting to mount with the following options:
  ecryptfs_unlink_sigs
  ecryptfs_fnek_sig=bbbbbbbbbbbbbbbb
  ecryptfs_key_bytes=16
  ecryptfs_cipher=aes
  ecryptfs_sig=aaaaaaaaaaaaaaaa
Mounted eCryptfs

Nếu chữ ký sai (không khớp với những gì bạn nhận được Private.sig), gắn kết sẽ không hoạt động.

... nhưng nó sẽ báo cáo một cách vô ích rằng nó đã làm. Bạn sẽ phải làm một ls /mnt/plainvà cat một tập tin để đảm bảo. Tại thời điểm này, bạn cũng có thể xem /var/log/syslogvà xác minh rằng ecryptfs đang tìm kiếm các chữ ký giống như chúng ta.

Rõ ràng có hai vấn đề nghiêm trọng với ecryptfs ở đây và chúng ta phải làm việc xung quanh chúng.

Nạp các khóa vào kernel

Nếu việc gắn kết tương tác không có ích, chúng ta phải tự tải các khóa vào kernel và tự chỉ định chúng trong các tùy chọn gắn kết.

# ecryptfs-add-passphrase --fnek

Và dán vào cụm mật khẩu gắn kết (siêu senstive) của bạn được sao chép từ phía trên. Điều này sẽ xuất ra:

Inserted auth tok with sig [aaaaaaaaaaaaaaaa] into the user session keyring
Inserted auth tok with sig [bbbbbbbbbbbbbbbb] into the user session keyring

Gắn thủ công

Bây giờ các cụm mật khẩu được tải vào kernel và chúng ta chỉ cần nói với mount để sử dụng chúng:

# umount /mnt/plain
# mount -i -t ecryptfs -o ecryptfs_sig=aaaaaaaaaaaaaaaa,ecryptfs_fnek_sig=bbbbbbbbbbbbbbbb,ecryptfs_cipher=aes,ecryptfs_key_bytes=16 /mnt/crypt/.ecryptfs/user/.Private /mnt/plain

Bạn sẽ nhận thấy các tùy chọn tương tự như những gì gắn kết tương tác được in ra, ngoại trừ chúng tôi đang nói thủ công về ecryptfs.

Hy vọng điều này làm việc. Nếu không, bạn có thể kiểm tra xem các khóa đã được tải vào kernel có chữ ký chính xác bằng cách sử dụng chưa keyctl list @u, có nên in ra ít nhất hai chữ ký mà bạn mong đợi.


4
có một cách giải quyết khi ecryptfs-recover-privateđầu ra lỗi mount (2). cố gắng chạy sudo ecryptfs-manager, nhấn 4 (thoát), sau đó chạy lại bản gốc ecryptfs-recover-private. nên làm việc ngay bây giờ
ulkas

1
@ulkas Bất cứ ý tưởng tại sao điều này làm việc?
Turion

2
@Turion tôi googled giải pháp ra, vì vậy tôi không phải là nhà phát minh. Tôi đoán là có một lỗi trong ecryptfsmột số phiên bản và gọi trình quản lý chỉ đơn giản là đặt một số biến mà sau đó được mount sử dụng. Ý tưởng làm thế nào để tự động hóa điều này để tôi có thể gắn các thư mục của mình sau mỗi lần khởi động lại?
ulkas

1
keyctl link @u @slà một giải pháp đơn giản cho tôi Tín dụng ở đây: bug.debian.org/cgi-bin/orpreport.cgi?orp=870126
sup

Mặc dù vấn đề của tôi có lẽ khác với poster ban đầu.
sup

1

Đối với những người xem tương lai của Q & A này: cùng một triệu chứng rõ ràng có thể được gây ra bởi các lý do cơ bản khác nhau. Các triệu chứng trông giống như:

INFO: Found [/home/.ecryptfs/frankenmint/.Private].
Try to recover this directory? [Y/n]: y
INFO: Found your wrapped-passphrase
Do you know your LOGIN passphrase? [Y/n] y
INFO: Enter your LOGIN passphrase...
Passphrase: 
Inserted auth tok with sig [979c6cdf80d2e44d] into the user session keyring
mount: No such file or directory
ERROR: Failed to mount private data at [/tmp/ecryptfs.Hy3BV96c].

Trong trường hợp của tôi, câu trả lời này giữ chìa khóa cho giải pháp. Vấn đề là tôi đã cố gắng thực hiện mọi thứ từ xa qua SSH trong phiên Tmux, bị giới hạn bởi dòng sau trong /etc/pam.d/sshd:

session    optional     pam_keyinit.so force revoke

Câu trả lời đã nói ở trên gợi ý nhận xét dòng đó và thử lại trong một phiên mới.

Cách giải quyết đơn giản có hiệu quả trong trường hợp của tôi là thực hiện trên vị trí, tránh hoàn toàn SSH và Tmux. Một cách giải quyết phức tạp hơn (mà tôi chưa xác minh) là sử dụng một cái gì đó như conspy để có quyền truy cập vào một thiết bị đầu cuối không giới hạn từ xa.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.