O --key-password do OpenConnect é a senha da sua conta VPN?

Leia o nome da opção à letra. Ele nomeia uma chave, e a confusão começa quando o ficheiro que está a ser desbloqueado é confundido com a conta que está a ser autenticada. Cole a senha da conta nessa opção e o cliente tentará abrir um ficheiro de chave com ela, o que falha por motivos que nada têm a ver com o início de sessão VPN.

A parte confusa é que uma única ligação pode legitimamente precisar dos dois segredos. A autenticação por certificado de cliente pode exigir uma chave cifrada, e o mesmo gateway pode ainda realizar uma troca de autenticação de utilizador depois de o certificado ser aceite. Nenhum dos segredos satisfaz a outra etapa, e uma falha num parece, de fora, muito semelhante a uma falha no outro.

Dois segredos, duas tarefas diferentes

Leia os papéis como acesso ao ficheiro versus admissão na rede. A senha da chave decifra a chave privada PEM indicada em --sslkey para que o certificado de cliente TLS possa ser apresentado. Essa decifra acontece localmente, dentro do processo do cliente, e a frase-passe em si nunca viaja para o gateway. O que o gateway vê é o certificado e uma assinatura feita com a chave. O manual do OpenConnect mantém --key-password ao lado de --certificate e --sslkey, e nas compilações que podem usar uma chave guardada num TPM a mesma opção transporta, em vez disso, a senha da chave raiz de armazenamento.

A senha da conta é de outra natureza. Entra na troca de autenticação: um formulário de utilizador e senha, um token, uma ronda SAML ou alguma combinação anunciada pelo gateway. Algumas instalações não a pedem de todo quando o certificado é o único fator, e outras pedem-na mesmo depois de um certificado, porque o certificado prova o dispositivo enquanto a conta prova a pessoa.

Misturar as duas produz erros enganadores. Um gateway que rejeita um início de sessão reporta normalmente uma falha de autenticação, enquanto uma frase-passe de chave errada falha geralmente mais cedo, quando a camada TLS não consegue ler o ficheiro de chave. São etapas diferentes com correções diferentes, e os nomes são suficientemente parecidos para que as pessoas os troquem e depois persigam o registo errado. Repare em que pedido apareceu antes de alterar qualquer definição, porque o texto do pedido é o diagnóstico mais barato de que dispõe.

Quando a senha da chave é realmente necessária

A opção só faz sentido quando há uma chave cifrada para desbloquear. Se se ligar com utilizador e senha e sem certificado de cliente, --key-password não tem sobre o que atuar, e incluí-la não muda nada. Se se ligar com --certificate e --sslkey, é o próprio formato do ficheiro de chave que decide se será pedida uma frase-passe.

Os dois segredos num só comando são comuns em ambientes geridos: um certificado de dispositivo numa chave cifrada, mais um início de sessão por utilizador. A sequência correta é deixar o cliente pedir a frase-passe da chave localmente, concluir o aperto de mão do certificado e depois tratar o pedido de conta do gateway em separado. Tentar preencher ambos antecipadamente através de um único script reutilizado é onde a confusão costuma começar.

Um diagnóstico útil é ver quando ocorre a falha. Se o cliente parar antes de começar qualquer autenticação de rede, suspeite do ficheiro de chave, do seu formato ou da frase-passe. Se a sessão TLS for estabelecida e o gateway rejeitar depois o utilizador, a chave fez o seu trabalho e o problema está na troca de conta.

Manter os dois segredos fora do histórico da shell

Os argumentos da linha de comandos são legíveis por outros utilizadores locais através da tabela de processos e ficam frequentemente capturados no histórico da shell, em scripts e em transcrições de suporte. O OpenConnect pode ler a senha da conta a partir da entrada padrão com --passwd-on-stdin, e a frase-passe da chave pode vir de um pedido interativo ou de um agente em vez de um argumento. Nenhum mecanismo torna o segredo seguro por si só, mas ambos mantêm-no fora dos locais mais expostos.

Os ficheiros merecem o mesmo cuidado. Um script que escreve uma frase-passe num ficheiro temporário deve criá-lo com permissões restritivas, apagá-lo ao sair e evitar diretórios legíveis por todos. Uma frase-passe que sobrevive à sessão num diretório temporário é uma cópia que se esqueceu de fazer. As variáveis de ambiente são visíveis para os processos filhos e acabam muitas vezes reproduzidas por ferramentas de depuração, por isso não são uma melhoria gratuita em relação aos argumentos.

A saída de diagnóstico é a fuga silenciosa. Os registos do cliente com maior detalhe podem mostrar corpos de pedidos ou valores de opções, e uma transcrição de terminal copiada é fácil de colar num ticket, por isso leia a saída antes de a partilhar.

Um botão do ambiente de trabalho morto é outra avaria

Uma entrada VPN do ambiente de trabalho que mostra um indicador a girar e depois nada não é, normalmente, um problema de autenticação. O botão pertence a um gestor de rede, a uma applet do fabricante ou a um plugin que inicia o OpenConnect em seu nome, e um componente em falta ou um perfil ilegível podem produzir exatamente esse sintoma. Descubra que processo o botão inicia e leia o erro antes de tocar nas credenciais.

É tentador relaxar a verificação do certificado ou desativar uma verificação quando a interface gráfica se recusa a ligar. Isso converte uma avaria de integração do cliente numa descida de segurança e raramente corrige o problema de arranque. Mantenha a verificação do servidor intacta, confirme que o perfil aponta para o gateway pretendido e verifique se o auxiliar que a interface espera está realmente instalado.

Uma lista curta separa os casos. Uma falha local antes de sair qualquer pacote aponta para a chave ou para a instalação do cliente. Uma rejeição do gateway após a sessão TLS aponta para a troca de conta. Um botão que nunca inicia o cliente aponta para a integração com o ambiente de trabalho. Três avarias diferentes, uma das quais é uma senha que estava prestes a colar na caixa errada.