¿Es --key-password de OpenConnect la contraseña de tu cuenta VPN?

Lee el nombre de la opción al pie de la letra. Nombra una clave, y la confusión empieza cuando el archivo que se desbloquea se confunde con la cuenta que se autentica. Pega la contraseña de la cuenta en esa opción y el cliente intentará abrir con ella un archivo de clave, lo que falla por motivos que no tienen nada que ver con el inicio de sesión VPN.

La parte confusa es que una sola conexión puede necesitar legítimamente ambos secretos. La autenticación con certificado de cliente puede requerir una clave cifrada, y la misma puerta de enlace puede realizar después un intercambio de autenticación de usuario una vez aceptado el certificado. Ninguno de los dos secretos satisface la otra etapa, y un fallo en uno se parece mucho, desde fuera, a un fallo en el otro.

Dos secretos, dos trabajos distintos

Lee los papeles como acceso al archivo frente a admisión en la red. La contraseña de la clave descifra la clave privada PEM indicada en --sslkey para que pueda presentarse el certificado de cliente TLS. Ese descifrado ocurre localmente, dentro del proceso del cliente, y la frase de paso nunca viaja a la puerta de enlace. Lo que ve la puerta de enlace es el certificado y una firma hecha con la clave. El manual de OpenConnect mantiene --key-password junto a --certificate y --sslkey, y en compilaciones que pueden usar una clave guardada en un TPM la misma opción lleva en cambio la contraseña de la clave raíz de almacenamiento.

La contraseña de la cuenta es de otro tipo. Entra en el intercambio de autenticación: un formulario de usuario y contraseña, un token, una ronda SAML o alguna combinación que anuncie la puerta de enlace. Algunos despliegues no la piden en absoluto cuando el certificado es el único factor, y algunos la piden incluso después de un certificado, porque el certificado demuestra el dispositivo mientras que la cuenta demuestra a la persona.

Mezclar las dos produce errores engañosos. Una puerta de enlace que rechaza un inicio de sesión suele informar de un fallo de autenticación, mientras que una frase de paso de clave incorrecta suele fallar antes, cuando la capa TLS no puede leer el archivo de clave. Son etapas distintas con soluciones distintas, y los nombres se parecen lo suficiente como para que la gente los intercambie y luego persiga el registro equivocado. Fíjate en qué aviso apareció antes de cambiar cualquier ajuste, porque el texto del aviso es el diagnóstico más barato que tienes.

Cuándo se necesita realmente la contraseña de la clave

La opción solo tiene sentido cuando hay una clave cifrada que desbloquear. Si te conectas con usuario y contraseña y sin certificado de cliente, --key-password no tiene sobre qué actuar, e incluirlo no cambia nada. Si te conectas con --certificate y --sslkey, el propio formato del archivo de clave decide si se pedirá una frase de paso.

Ambos secretos en un solo comando son habituales en entornos gestionados: un certificado de dispositivo en una clave cifrada, más un inicio de sesión por usuario. La secuencia correcta es dejar que el cliente pida la frase de paso de la clave localmente, completar el apretón de manos del certificado y después gestionar por separado el aviso de cuenta de la puerta de enlace. Intentar rellenar ambos de antemano con un único script reutilizado es donde suele empezar la confusión.

Un diagnóstico útil es mirar cuándo ocurre el fallo. Si el cliente se detiene antes de que empiece cualquier autenticación de red, sospecha del archivo de clave, de su formato o de la frase de paso. Si la sesión TLS se establece y luego la puerta de enlace rechaza al usuario, la clave hizo su trabajo y el problema es el intercambio de cuenta.

Mantener ambos secretos fuera del historial del intérprete

Los argumentos de línea de comandos son legibles por otros usuarios locales a través de la tabla de procesos y a menudo quedan capturados en el historial del intérprete, en scripts y en transcripciones de soporte. OpenConnect puede leer la contraseña de la cuenta desde la entrada estándar con --passwd-on-stdin, y la frase de paso de la clave puede venir de un aviso interactivo o de un agente en lugar de un argumento. Ningún mecanismo hace seguro el secreto por sí solo, pero ambos lo mantienen fuera de los lugares más expuestos.

Los archivos merecen el mismo cuidado. Un script que escribe una frase de paso en un archivo temporal debería crearlo con permisos restrictivos, borrarlo al salir y evitar directorios legibles por todo el mundo. Una frase de paso que sobrevive a la sesión en un directorio temporal es una copia que olvidaste hacer. Las variables de entorno son visibles para los procesos hijos y a menudo acaban reproducidas por herramientas de depuración, así que no son una mejora gratuita frente a los argumentos.

La salida de diagnóstico es la fuga silenciosa. Los registros del cliente con mayor detalle pueden mostrar cuerpos de solicitud o valores de opciones, y una transcripción de terminal copiada es fácil de pegar en un ticket, así que lee la salida antes de compartirla.

Un botón muerto del escritorio es otra avería

Una entrada VPN de escritorio que muestra un indicador giratorio y luego nada normalmente no es ningún problema de autenticación. El botón pertenece a un gestor de red, a un applet del fabricante o a un complemento que inicia OpenConnect en tu nombre, y un componente que falta o un perfil ilegible pueden producir exactamente ese síntoma. Averigua qué proceso inicia el botón y lee su error antes de tocar las credenciales.

Es tentador relajar la verificación del certificado o desactivar una comprobación cuando la interfaz gráfica se niega a conectar. Eso convierte una avería de integración del cliente en una rebaja de seguridad y rara vez arregla el problema de arranque. Mantén intacta la verificación del servidor, confirma que el perfil apunta a la puerta de enlace prevista y comprueba que el ayudante que la interfaz espera está realmente instalado.

Una lista breve separa los casos. Un fallo local antes de que salga ningún paquete apunta a la clave o a la instalación del cliente. Un rechazo de la puerta de enlace tras la sesión TLS apunta al intercambio de cuenta. Un botón que nunca inicia el cliente apunta a la integración de escritorio. Tres averías distintas, una de las cuales es una contraseña que estabas a punto de pegar en la casilla equivocada.