Eu tenho um volume criptografado para o qual eu configurei inicialmente uma senha de forma interativa, o que funciona muito bem para descriptografar a partição. Eu adicionei mais chaves usando um arquivo-chave nas duas formas a seguir:
cryptsetup --keyfile=passphrase luksAddKey /dev/sdax
cryptsetup --luksAddKey /dev/sdax passphrase
onde a senha é o arquivo que contém a chave e / dev / sdax é o volume criptografado.
Em seguida, verifiquei se a frase secreta era válida usando
cat passphrase | cryptsetup --test-passphrase luksOpen /dev/sdax
dd if=passphrase bs=1 count=256 | cryptsetup --test-passphrase luksOpen /dev/sdax
mas ambos falharam: "Nenhuma chave disponível com esta senha". O seguinte comando usando a opção --key-file funcionou:
cryptsetup --test-passphrase --key-file passphrase luksOpen /dev/sdax
Nesse ponto, tentei ver se o método de canalizar o conteúdo da frase secreta funcionava com a única frase-senha funcional (configurada interativamente).
echo "manually written working passphrase" > interactive_pass
cat interactive_pass | cryptsetup luksAddKey /dev/sdax
Desta vez funcionou muito bem. Qual é a diferença entre os dois métodos e os dois arquivos principais? Eu precisaria que o primeiro método de canalizar o conteúdo do arquivo funcionasse também com senhas adicionadas dos arquivos de chave, já que parece ser o único método possível ao usar um script no crypttab. É possível?
Você precisa usar a opção -h . A senha é primeiro dividida antes de ser usada como um arquivo-chave; é assim que você vai de alguns caracteres para 256 ou 512 bits. Então, dependendo de quais opções você usou para luksFormat e como você planeja desbloqueá-las, é necessário especificar, por exemplo. -h plain ou algum outro parâmetro.
Isso é explicado em detalhes na página cryptsetup man em NOTES ON PASSPHRASE PROCESSING FOR LUKS . Existem diferenças, como incluir novas linhas ou não, limites de tamanho diferentes (por exemplo, 512 bytes para senhas interativas, verificar cryptsetup --help ), ...
Se você quiser evitar este incômodo em particular, é melhor criar arquivos de chave que também funcionem ao digitá-los no terminal no prompt interativo cryptsetup. Isso significa que o arquivo de chave deve ser uma cadeia de texto simples e NÃO deve incluir um caractere de nova linha no final. (Use echo -n ou printf "%s" .)
Por exemplo, você pode usar pwgen para gerar uma senha de 64 caracteres keyfile.txt que também pode ser digitada manualmente em uma emergência:
$ echo -n $(pwgen 64 1) | tee keyfile.txt
Aish6shaejongi9yug3quij7aijop7SieTh7ierahngaem8iov5isho5dae0pisu
Com um arquivo-chave como este, não deve haver diferença na interpretação, independentemente de como você o passa para cryptsetup . A exceção é usar o layout de teclado incorreto ao digitá-lo. Se você espera problemas de layout de teclado, você pode adicionar a senha duas vezes para que o LUKS aceite qualquer um deles.
Isso é particularmente importante ao usar /dev/urandom keyfiles ... se você usá-los da maneira errada, pode ter parado de processar antecipadamente (um caractere aleatório de nova linha aparece) e sua senha é muito mais curta do que você acredita ser.
Quando você passa a frase-senha na entrada padrão, o cryptsetup lê uma linha de entrada e descarta a nova linha no final desta linha, assim como qualquer linha subseqüente.
Quando você passa a senha de um arquivo com --key-file , o conteúdo completo do arquivo é usado. Se o arquivo contiver uma nova linha, a frase secreta não poderá ser idêntica àquela que é passada na entrada padrão.