Le client vpn fourni avec Cisco AnyConnect se comporte comme une conversation : il affiche une invite, attend une ligne, puis affiche la suivante. Alimentez cette conversation depuis un fichier ou un tube et le même binaire s’exécute sans surveillance. La technique tient en une redirection et une liste ordonnée de réponses, et c’est la liste, non la redirection, qui décide si le script est fiable.

Deux choses le cassent en pratique. L’ordre des invites change quand une passerelle demande quelque chose en plus, et un mot de passe stocké transforme une faute de frappe en verrouillage de compte. Traitez la séquence comme des données versionnées que vous pouvez comparer après chaque changement de passerelle. Échouez bruyamment plutôt que de réessayer, car une boucle est exactement la façon dont un mot de passe mal saisi devient un compte verrouillé.

Une séquence, dans l’ordre où le client demande

Lancez le client en interactif une fois et notez chaque invite dans l’ordre d’apparition. Cette transcription devient le fichier de réponses. Quand vous redirigez le fichier vers le binaire, la première ligne doit être la commande de connexion elle-même, et c’est pourquoi la séquence commence par un nom d’hôte plutôt que par un nom d’utilisateur.

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

Le 0 seul sélectionne le premier profil de connexion quand la passerelle propose une liste ; utilisez l’index qu’affiche votre passerelle. Le y accepte une bannière de connexion, donc supprimez cette ligne s’il n’y a pas de bannière et insérez-en une là où votre passerelle pose une question supplémentaire. Le exit final est ce qui permet au client de se terminer proprement quand la dernière réponse a été consommée.

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

Le mode non interactif n’est pas optionnel ici. Sans -s, le client peut prendre le terminal et ignorer l’entrée redirigée ; avec lui, les réponses sont lues depuis le flux et le processus rend la main. Là où le binaire exige des privilèges élevés, enveloppez l’appel dans sudo -n pour que le script échoue immédiatement au lieu de bloquer sur une demande de mot de passe.

Où fuit le fichier de réponses

Un fichier qui contient un mot de passe est un identifiant : donnez-lui donc les permissions d’un tel fichier : mode 600, appartenant au compte qui exécute la tâche, et jamais dans un répertoire partagé ou synchronisé. Créez-le avec le mode déjà appliqué plutôt que de le corriger après coup, car un fichier est brièvement lisible par tous entre l’écriture et le chmod.

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

L’autre moitié, c’est argv. Un mot de passe passé en argument est visible par tout utilisateur local qui liste les processus, et il atterrit aussi dans l’historique du shell. Lisez-le plutôt depuis un descripteur de fichier ou une variable d’environnement, et citez la charge utile pour que le shell ne puisse rien développer à l’intérieur.

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

Attention au quoting. Entre guillemets doubles, un mot de passe contenant ! peut être développé par un shell interactif avant même que le client le voie, et l’échec arrive sous la forme d’une erreur générique event-not-found qui ressemble à un problème de protocole.

Prouvez le tunnel, puis fermez-le

Un état connecté prouve seulement que le client croit avoir une session. Choisissez un hôte qui ne répond que depuis le réseau d’entreprise et testez-le une fois avant de faire quoi que ce soit d’autre. Un échec à cet endroit est un défaut de routage ou de politique, et relancer la connexion n’y changera rien.

/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

Vérifiez la sortie d’état avant et après la déconnexion. Un client laissé avec une session périmée peut refuser la connexion suivante alors que le script signale encore un succès, et ce mode de défaillance est invisible si vous ne regardez que les codes de sortie. Comparez les deux relevés au lieu de faire confiance au second isolément. Les alias d’un profil de shell suffisent pour un usage quotidien, mais tout ce qui est planifié mérite la même revue des identifiants et de l’identité que n’importe quelle autre tâche sans surveillance.

Quand une liste figée cesse d’être sûre

Un fichier de réponses encode l’ordre des invites du jour. Une bannière modifiée, un changement de mot de passe forcé ou un défi à second facteur en font une boucle qui peut verrouiller le compte, et c’est pourquoi le script doit sortir à la première réponse inattendue au lieu de redémarrer.

Capturez ce que le client a affiché, renvoyez un statut non nul et laissez l’appelant décider. Là où la passerelle exige un second facteur, la réponse honnête est qu’une connexion sans surveillance n’est pas disponible pour ce profil, pas que la séquence a besoin d’une ligne de plus.

La rotation fait partie de la même revue. Si l’identifiant est stocké, décidez qui peut le lire, quand il change et ce qui le supprime quand l’hôte est reconstruit. Un script qui fonctionne un an parce que personne n’a touché au mot de passe n’est pas une conception, c’est un accident qui attend une politique de rotation.

Les profils qui ne sont pas AnyConnect

Deux styles d’identifiants Cisco plus anciens sont confondus avec celui-ci. Un profil vpnc demande un IPSec ID, qui est en réalité le nom du groupe, puis un secret de groupe, puis vos propres identifiants, et les trois viennent de celui qui exploite la passerelle. Le Cisco IPsec historique est un protocole différent d’AnyConnect, donc vpnc ne peut pas atteindre un service réservé à AnyConnect ; openconnect --protocol=anyconnect est le client ouvert pour ce travail.

Un fichier .pcf décrit le profil du client plus ancien. L’hôte, le nom du groupe et le mot de passe de groupe qu’il contient peuvent être ressaisis à la main dans un client qui parle Cisco IPsec, bien que le fichier ne soit pas un import universel et que tout port ou mode de tunnellisation non standard disparaisse généralement au transfert.

Partez de ce que la passerelle offre réellement, puis choisissez le client qui parle ce protocole. Copier un profil d’un autre site, c’est ainsi que l’on finit par déboguer des identifiants qui n’ont jamais été le problème.

Articles similaires