AnyConnect en Linux: programar a secuencia de inicio de sesión con seguridade

O cliente vpn que vén con Cisco AnyConnect compórtase como unha conversa: imprime unha indicación, agarda unha liña e despois imprime a seguinte. Se alimentas esa conversa desde un ficheiro ou unha tubaxe, o mesmo binario execútase sen supervisión. A técnica é unha redirección máis unha lista ordenada de respostas, e é a lista, non a redirección, a que decide se o script é fiable.

Dúas cousas rompen isto na práctica. A orde das indicacións cambia cando unha pasarela pide algo extra, e un contrasinal almacenado converte unha errata nun bloqueo de conta. Trata a secuencia como datos versionados que podes comparar despois de calquera cambio na pasarela. Falla ruidosamente en lugar de reintentar, porque un bucle é exactamente o xeito no que un contrasinal mal escrito se converte nunha conta bloqueada.

Unha secuencia, na orde en que a pide o cliente

Executa o cliente de forma interactiva unha vez e anota cada indicación na orde en que aparece. Esa transcrición convértese no ficheiro de respostas. Cando redirixes o ficheiro ao binario, a primeira liña ten que ser o propio comando de conexión, e por iso a secuencia comeza cun nome de host en lugar dun nome de usuario.

connect vpn.example.com
0
<username>
<password>
y
exit

O 0 espido selecciona o primeiro perfil de conexión cando a pasarela ofrece unha lista; usa o índice que imprima a túa pasarela. O y acepta un banner de inicio de sesión, así que borra esa liña se non hai banner e insire unha onde a túa pasarela faga unha pregunta adicional. O exit final é o que permite ao cliente terminar limpiamente cando se consumiu a última resposta.

/opt/cisco/anyconnect/bin/vpn -s < anyconnect.txt

O modo non interactivo aquí non é opcional. Sen -s o cliente pode tomar o terminal e ignorar a entrada redirixida; con el, as respostas len do fluxo e o proceso volve. Onde o binario necesita privilexios elevados, envolve a invocación en sudo -n para que o script falle de inmediato en lugar de bloquearse nunha petición de contrasinal.

Onde se filtra o ficheiro de respostas

Un ficheiro que contén un contrasinal é unha credencial, así que dálle os permisos dunha: modo 600, propiedade da conta que executa o traballo e nunca dentro dun directorio compartido ou sincronizado. Créao co modo xa aplicado en lugar de corrixilo despois, porque un ficheiro é brevemente lexible por todos entre a escritura e o chmod.

install -m 600 /dev/null ~/.config/anyconnect.txt
chmod 700 ~/.config

A outra metade é argv. Un contrasinal pasado como argumento é visible para calquera usuario local que liste procesos, e tamén acaba no historial do shell. Léoo dun descritor de ficheiro ou dunha variable de contorno no seu lugar, e entrecomilla a carga útil para que o shell non poida expandir nada dentro.

printf '%s\n' 'connect vpn.example.com' '0' "$VPN_USER" "$VPN_PASS" 'y' 'exit' \
  | sudo -n /opt/cisco/anyconnect/bin/vpn -s

Vixía as comiñas. Dentro de comiñas dobres, un contrasinal que conteña ! pode ser expandido por un shell interactivo antes de que o cliente chegue a velo, e o fallo chega como un erro xenérico event-not-found que parece un problema de protocolo.

Demostra o túnel e despois péchao

Un estado conectado só demostra que o cliente cre ter unha sesión. Escolle un host que só responda desde dentro da rede corporativa e proba unha vez antes de facer calquera outra cousa. Un fallo aí é un problema de encamiñamento ou de política, e volver executar o inicio de sesión non o cambiará.

/opt/cisco/anyconnect/bin/vpn state
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 10 https://<internal-host>/
/opt/cisco/anyconnect/bin/vpn disconnect

Comproba a saída de estado antes e despois da desconexión. Un cliente que queda cunha sesión obsoleta pode rexeitar a seguinte conexión mentres o script aínda informa de éxito, e ese modo de fallo é invisible se só miras os códigos de saída. Compara as dúas lecturas en lugar de confiar na segunda por si soa. Os alias nun perfil de shell abondan para o uso diario, mentres que calquera cousa programada merece a mesma revisión de credenciais e identidade que calquera outro traballo sen supervisión.

Cando unha lista fixa deixa de ser segura

Un ficheiro de respostas codifica a orde de indicacións de hoxe. Un banner cambiado, un cambio de contrasinal forzado ou un reto de segundo factor convérteno nun bucle que pode bloquear a conta, e por iso o script debe saír na primeira resposta inesperada en lugar de reiniciarse.

Captura o que imprimiu o cliente, devolve un estado distinto de cero e deixa que quen chama decida. Onde a pasarela esixe un segundo factor, a resposta honesta é que un inicio de sesión sen supervisión non está dispoñible para ese perfil, non que a secuencia necesite unha liña máis.

A rotación pertence á mesma revisión. Se a credencial se almacena, decide quen pode lela, cando cambia e que a elimina cando se reconstrúe o host. Un script que funciona durante un ano porque ninguén tocou o contrasinal non é un deseño, senón un accidente que agarda unha política de rotación.

Perfís que non son AnyConnect

Dous estilos de credenciais de Cisco máis antigos confúndense con este. Un perfil vpnc pide un IPSec ID, que en realidade é o nome do grupo, despois un segredo de grupo, despois as túas propias credenciais, e os tres veñen de quen xestiona a pasarela. O Cisco IPsec heredado é un protocolo distinto de AnyConnect, así que vpnc non pode chegar a un servizo só de AnyConnect; openconnect --protocol=anyconnect é o cliente aberto para esa tarefa.

Un ficheiro .pcf describe o perfil do cliente máis antigo. O host, o nome do grupo e o contrasinal de grupo que contén pódense volver introducir a man nun cliente que fale Cisco IPsec, aínda que o ficheiro non é unha importación universal e calquera porto ou modo de tunelización non predeterminado adoita desaparecer no traslado.

Comeza polo que a pasarela ofrece realmente e despois escolle o cliente que fala ese protocolo. Copiar un perfil doutro sitio é como a xente acaba depurando credenciais que nunca foron o problema.