Depende do que o script de inicialização que pede a senha de você está fazendo com ele.
Se for systemd , pode ser apenas um recurso. systemd-ask-password vem com uma funcionalidade de cache que pode ser responsável.
--accept-cached If passed, accept cached passwords, i.e. passwords previously entered. --multiple When used in conjunction with --accept-cached accept multiple passwords. This will output one password per line.
Desta forma, primeiro tentaria as senhas que você já digitou e só pediria outras senhas se isso não funcionasse.
A desvantagem dessa ideia é que a verificação de uma senha leva 1 segundo do tempo de CPU com o LUKS, portanto, se você tivesse muitos contêineres LUKS, essas tentativas poderiam atrasá-lo. Mas a maioria das pessoas tem apenas uma ou duas e, na verdade, não é incomum que elas usem a mesma frase secreta.
Na verdade, não consegui localizar o código-fonte especificamente responsável por isso, portanto, o que está acima é apenas uma conjectura e não tenho ideia se esse é um recurso que você pode escolher para desativar de alguma forma.
Encontrado o que parece ser o código responsável, veja aqui em Github .
Há um loop for que começa com tries = 0 e incrementa tries em uma a cada iteração.
Este loop chama get_password() com bool accept_cached definido como verdadeiro se tries == 0 && !arg_verify . Portanto, se já houver senhas em cache na primeira iteração do loop, ele retornará as senhas armazenadas em cache. Se elas não funcionarem, a próxima iteração com tries == 1 define accept_cached para false e, somente então, ele solicitará que você forneça outra frase-senha para tentar.
A lista de senhas é passada para attach_luks_or_plain() . Esta será a (s) senha (s) armazenada (s) anteriormente (s) na primeira iteração, e a nova senha única em todas as seguintes, para que não tente senhas previamente tentadas (a menos que você continue digitando a mesma). / p>
Quanto à manutenção de senhas em texto puro, a lista de senhas é declarada como _cleanup_strv_free_erase_ char **passwords = NULL; , de modo que, pelo menos, parece que a limpeza será feita adequadamente em algum momento.
As chaves estão sempre na memória em algum lugar, isso não pode ser ajudado, o crypt precisa do masterkey para funcionar, contanto que o container esteja aberto, você sempre pode vê-lo com dmsetup table --showkeys .
Parece que você normalmente tem arg_tries = 3 três tentativas de inserir uma frase-senha em funcionamento, mas se você tiver vários contêineres e as senhas armazenadas em cache não funcionarem, ele só fornecerá duas tentativas para inserir a frase secreta, pois A tentativa de senha já conta como a primeira tentativa. Eu não tenho nenhuma máquina systemd criptografada para testar se isso é verdade ou apenas estou interpretando mal o código em algum lugar.