컴퓨터가 오랫동안 멈춰서 재설정 버튼을 눌렀습니다. 재부팅 후에는 모든 FIVE Luks 암호화(LUKS 1) 파일 시스템이 더 이상 열리지 않습니다. 내가 받은 메시지는 "이 암호문에는 사용할 수 있는 키가 없습니다."입니다. 나는 올바른 비밀번호를 사용하고 있다고 확신합니다. 나는 수년간 모든 파일 시스템에 동일한 비밀번호를 사용해 왔습니다. 하나를 제외한 모든 볼륨에 대한 백업이 있으므로 그에 대한 옵션을 분석하고 싶습니다. 모든 파일 시스템에서 'cryptsetup isLuks' 및 'cryptsetup luksDump'를 시도했는데 모두 성공했습니다. 즉, Luks 파티션이고 헤더를 덤프하고 슬롯을 볼 수 있습니다. 그러나 연구를 통해 사람들이 헤더가 수리할 수 없을 정도로 손상되었다고 말하는 유사한 사례를 발견했습니다. 나는 그것을 식별하는 방법을 모른다. 어떻게 해야 하나요? 어떤 정보라도 감사드립니다.
답변1
이 페이지를 찾았습니다.
https://bbs.archlinux.org/viewtopic.php?pid=1846810#p1846810
또한 이 페이지:
더 구체적으로,
"복구 가능성이 있는지 상당히 빨리 알 수 있습니다. "hexedit -s /dev/sdx"를 실행하고 섹터 시작 부분에서 16진수 문자열 "4C 55 4B 53 BA BE"를 검색하십시오. (이것이 ASCII 문자열입니다. "LUKS" 다음에 16진수 바이트 0xBA 및 0xBE가 옵니다.) 디스크의 처음 몇 메가바이트 내에서 이를 찾지 못하면 LUKS 헤더가 사라진 것입니다."
열기를 거부한 5개 파일 시스템 모두 헤더에 해당 문자열이 그대로 있으므로 모두 손상되지 않은 것으로 보입니다. 이제 왜 그것들이 모두 열리지 않는지는 별개의 문제이고 나는 무슨 일이 일어났는지 결코 알 수 없을 것이라고 생각합니다.
답변2
후손을 위해 답변이 제공되었습니다.
LUKS 헤더가 손상되었는지 어떻게 알 수 있나요?
귀하의 질문에 대한 짧은 대답은 잠금을 해제하려고 하면 손상되었다는 메시지가 표시되거나 부팅 파티션인 경우 암호를 입력하려고 하면 시스템이 멈춘다는 것입니다. 그러나 귀하의 경우에는 "이 암호로 사용할 수 없는" 키에 대한 오류가 표시됩니다. 이는 약간 이상합니다.
이미 발견했으므로 비밀번호 입력을 시도한 후 hexedit -s <device>실행을 시도하여 어떤 종류의 상태가 보고되는지, 테이블이 존재하는 것으로 보고되는지 등을 확인할 수도 있습니다.dmsetup info <device_name>]DMsetup 매뉴얼 페이지더 많은 정보를 위해서.
아니면 dmsetup table --showkeys <device or header file>키 슬롯을 인식하는지 확인해 보세요.
LUKS 헤더를 확인하는 추가 방법
헤더 백업을 생성하기 위해 를 사용하는 것 외에도 cryptsetup luksHeaderBackup <device> --header-backup-file <file>(열리지 않더라도 luksDump손상을 보고하지 않기 때문에) 백업을 만든 다음 해당 백업에서 복원하여 작동 여부를 확인할 수도 있습니다 cryptsetup. 그런 식으로 헤더를 복원할 수 있습니다. 앞서 언급한 방법 외에도 dd헤더의 "백업"을 생성하기 위한 대안으로 사용할 수도 있습니다.
root@system:# dd if=<device> of=<Luksheader_filename> bs=512 count=4097
hexedit헤더를 확인하는 데 사용하는 것 외에도 위에서 방금 생성한 파일에 대해 file또는 명령을 사용할 수도 있고, 장치 이름을 경로 및 파일 이름으로 바꿔 파일 자체에 대해 명령을 실행할 수도 있습니다.stringsluksDump
root@system:# file <Luksheader_filename>
root@system:# strings <Luksheader_filename> | grep -i luks LUKS
root@system:# cryptsetup luksDump <Luksheader_filename>
비슷한 사례는 비슷할 수도 있고 아닐 수도 있습니다.
위에 연결한 다른 연구와 귀하의 연구에 따르면 컴퓨터가 정지되었을 때 무엇을 하고 있었는지 명확하지 않아 드라이브에 액세스할 수 있는 마지막 시간이 될 것입니다. 대조적으로, 두 개의 링크에는 개별 LUKS로 암호화된 드라이브에 액세스할 수 없게 되는 두 가지 다른 이유가 있습니다.HPA잘못된 구성과 다른 하나는 볼륨에만 영향을 미치고 볼륨 /home에는 영향을 미치지 않는 커널 업그레이드를 따르고 있었으며 /root실제로는다듬기/폐기 문제.
아마도 광범위한 설명을 바탕으로 더 유사한 발생 문제가 발견될 수 있습니다.여기, 그들은 우주선이 어딘가에 비트 스위치를 강제로 적용할 가능성을 고려하기 시작했으며 다른 모든 옵션을 탐색했는지 다시 확인하고 싶은 사람에게 좋은 읽기가 될 수 있습니다.
제공된 정보에 따르면 이러한 "파일 시스템"*이 운영 체제를 보유하는지 또는 광범위하게 설명하는 "콘텐츠"를 보유하는지 여부가 불분명하므로 시도할 때 시스템이 정지되는지 아는 것이 도움이 될 것입니다. LUKS 암호화된 볼륨/파티션 중 하나가 부팅 드라이브이고 비밀번호가 작동하지 않는 경우 또는 터미널 및/또는 GUI에서 해당 5개 장치에 액세스하려는 경우(그리고 어떤 Linux 버전에서) 부팅하려면 ) 반복되는 오류가 발생한다고요? 이 경우 후자에 약간의 희망이 있을 수 있습니다.
*명확히 말하면 "파일 시스템"은 데이터가 저장되는 방법과 위치를 나타내므로 파일 시스템은 일반적으로 ext3, ext4, NTFS 등과 같은 형식을 참조하는 반면 LUKS는 디스크 암호화 사양입니다. 따라서 5개의 LUKS '파일 시스템'(아마도 언급한 볼륨)이 시스템의 일부로 어떤 역할을 하는지에 대한 통찰력을 제공하지 않습니다.
헤더가 아닌 가능한 문제
문제는 손상된 LUKS 헤더를 식별 및/또는 결정하는 방법에 관한 것이었습니다. 그러나 헤더를 백업하지 않으면 OP에서 비교할 헤더의 손상되지 않은 버전이 없습니다. 적용되는 상황이 불확실하고 연결된 예와 다를 수 있다는 것이 이제 더 명확해졌으므로 시도해 볼 가치가 있습니다.
다음을 사용하여 LVM 문제인지 확인
root@system:# lvscan
# or
root@system:# lvdisplay
# To check if you can still identify the LUKS filesystems as volume groups or
# supported LVM block devices.
root@system:# vgdisplay --short
# To find the Volume Group (usually fails if password won't work)
root@system:# lvs -o lv_name,lv_size -S vg_name=[name_of_volumegroup]
# To list the logical volumes identified in the volume group (if it works)
맨페이지를 참조하세요.lvscan그리고vgdisplay자세히 알아보기
그리고, 다른 가능성을 탐색해 보세요
불행하게도 LUKS1 암호화에서는 여러 가지 이유로 체크섬이 구현되지 않았습니다.이 프레젠테이션만약 원한다면. 그렇지 않으면 LUKS의 유일한 "체크섬"은 일치하는 키 슬롯이 없으며 손상되었음을 암시하는 것입니다.
그러나 5개 파일 시스템이 모두 열리지 않고 모두 볼륨으로 참조되므로 모두 하나의 디스크에 있는지, SSD 드라이브인지 아닌지는 확실하지 않습니다.메모리 및 저장소 검사드라이브의 다음 제안이 될 것입니다.
마지막으로 확실하게 '예'라고 답 cryptsetup하셨나요 sudo?
시도해 볼 수도 있습니다.
- 파티션 테이블 및 기타 사항과 관련하여 발견된 gparted GUI의 복구 기능 사용
- 스캔을 제공
ddrescue - Caps Lock이나 Number Lock이 켜져 있지 않은지 확인하세요. (어리석은 일이지만, 가볍게 상기시켜 드리겠습니다.)
- 제안된 답변 중 일부를 시도해 보세요.여기
- 컴퓨터가 정지되기 전에 업데이트가 있었다면 이전 버전으로 롤백해 보세요.
- 다른 키슬롯에 비밀번호를 추가해 보세요
참고 사항
특정 시스템이나 GUI가 언급되지 않았거나 부팅 프로세스에 대한 언급이 없었기 때문에 터미널 내에서 sudo를 사용하여 LUKS 암호화된 볼륨을 열려고 시도한 것으로 가정되었습니다.