나는 암호화된 Luks 볼륨에 대해 가장 이상한 경험을 해왔고 누군가가 내가 그것에 대해 약간의 정보를 제공하도록 도울 수 있기를 바랐습니다. 그 내용을 안내해 드리겠습니다.
/boot내 OS(바닐라 아치(btw))를 설치할 때 cryptestup & luks v2를 사용하여 암호화된 루트 파티션(암호화되지 않은 상태로 유지) 을 설정했습니다 . 처음 며칠 동안은 문제 없이 모든 것이 잘 작동했습니다. 그런데 재부팅 후 어느 날 갑자기 암호 문구가 더 이상 허용되지 않습니다.
No key available with this passphrase내가 얻는 전부입니다. 그래서 제가 가장 먼저 확인한 것은 키보드 레이아웃에 이상한 점이 있는지 여부였습니다. 내 비밀번호를 볼 수 있도록 다음 명령을 사용하여 라이브 Manjaro ISO를 부팅하여 거기에 볼륨을 마운트했습니다(이렇게 잘못 입력하지 않음).
echo [mypassword] | cryptsetup open --test-passphrase /dev/nvme0n1p2
또한 차이가 있을 경우를 대비해 다음을 시도했습니다.
echo [mypassword] | cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2
그러나 아무 소용이 없습니다. 시작하는 동안 키보드 레이아웃을 확인하기 위해 사용하여 부팅했는데 break=premount아무런 문제도 없습니다. 그래서 이 시점에서 나는 헤더 백업이 없었기 때문에(현재 백업이 손상되었다고 생각하면서) 아무 것도 볼 수 없다고 생각했지만, 필사적으로 마지막 노력으로 다시 부팅을 시도했는데 이번에는 잘 작동했습니까?
즉시 진행하여 헤더 백업 파일을 생성했습니다. 다음을 실행하여 손상되지 않았는지 확인했습니다.
echo [mypassword] | cryptsetup luksOpen --test-passphrase ./luksHeader
암호화된 볼륨 외부에 헤더를 저장했습니다.
오늘까지 문제가 다시 발생하지 않았습니다. 부팅하는 동안 다시 메시지를 받았습니다 No key available with this passphrase. 좋습니다. 그러면 라이브 ISO로 부팅하고 거기에 볼륨을 마운트하려고 시도했지만 작동하지 않습니다. 그런 다음 저장해 두었던 헤더를 복사하여 열려고 시도하지만또한 작동하지 않습니다. 내 비밀번호를 망칠 수 없도록 만드는 명령도 실행했습니다.
echo [mypassword] | cryptsetup luksOpen --test-passphrase ./luksHeader
내 비밀번호와 관련된 급성 선택적 기억상실증을 배제하기 위해 다른 컴퓨터에서 헤더 파일을 열려고 시도했는데 문제가 없었습니다. 그 사이에 내 기본 컴퓨터에서는 여전히 오류가 발생합니다.
그래서 기본적으로 명령을 스팸하기로 결정했습니다.
echo [mypassword] | cryptsetup luksOpen --test-passphrase ./luksHeader
이전 작업이 끝나자마자. 이상하게도 헤더 파일을 열 때 성공할 확률은 약 1/5 정도입니다. 대부분 연속해서 여러 번 실패했지만 때로는 연속해서 2~3번 성공하기도 했습니다.
위의 명령을 사용하면 비밀번호를 잘못 입력하거나 기억하는 것이 불가능해지기 때문에 이는 매우 이상하다는 생각이 들었습니다. 헤더 파일에 전달되는 것은 항상 동일한 문자열이었습니다. 또한, 앞서 언급한 것처럼 이는 지속적인 문제가 아닙니다. 처음 관찰한 시점과 오늘 사이에 문제 없이 다시 시작하고 암호를 입력할 수 있었던 기간이 여러 주가 있었기 때문입니다.
그런 다음 암호화된 파티션으로 동일한 작업을 시도했으며 약 1/5의 성공률도 관찰할 수 있었습니다. 그런 다음 재부팅하기로 결정하고 No key available ...비밀번호를 입력하는 동안 메시지를 두 번 받았고 세 번째 시도에서 부팅에 성공했습니다.
여기까지 완료하셨다면 축하드립니다. 내가 이것을 경험한 것처럼 당신도 이 글을 읽고 미쳐버리지 않기를 바랍니다.
현재로서는 데이터 손실에 대해 전혀 걱정하지 않습니다. 왜냐하면 a) 중요한 모든 항목의 백업이 있고 b) 항상 다른 장치에서 내 드라이브의 암호를 해독할 수 있기 때문입니다(제 생각에는 ㅋㅋㅋ). 내가 목격하고 있는 이상한 행동에 대한 설명과 그에 대한 잠재적인 해결책과 같은 것입니다. 왜냐하면 최소한 내가 원할 때마다 부팅할 수 없는 잠재적인 짜증을 제공하기 때문입니다.
나는 심지어 우주 배경 방사선이나 전자기장의 다른 근원과 같은 이상한 것들도 고려했습니다. 그리고 여러분 중 누구도 더 나은 이론을 생각해 내지 못한다면 내 타워를 같은 곳으로 옮겨서 테스트해야 할 것 같습니다. 헤더를 실패 없이 해독할 수 있는 머신으로 룸을 사용합니다.
가장 큰 문제는 이 문제가 무작위로 발생하는 것 같다는 것입니다. 아직 안정적으로 재현할 수 있는 방법을 찾지 못했기 때문입니다. 그 일에 도움을 주시면 정말 감사하겠습니다!
마지막으로: 이 문제는 헤더 파일/볼륨을 열 때 안정성이 향상되는 것을 관찰할 수 없었기 때문에 추가 재부팅/전원 끄기에 의해 영향을 받지 않는 것 같습니다. 그것에 영향을 미치는 유일한 것은 시간입니다(내일은 아마도 괜찮을 것입니다). BIOS 구성을 피할 수 있다면 잃고 싶지 않기 때문에 CMOS 지우기를 확인하지 않았습니다.