Un écouteur SOCKS local est utile sur certains réseaux et absent sur d'autres. OpenSSH peut choisir une commande de proxy sous condition, sans que ce choix s'applique à tous les hôtes.

Pour OpenSSH avec la forme OpenBSD de nc, une configuration client illustrative est la suivante :

Host work-server
    HostName ssh.example.net
    User alex

Match originalhost work-server exec "nc -z -w 1 127.0.0.1 1080"
    ProxyCommand nc -X 5 -x 127.0.0.1:1080 %h %p

Match all

originalhost limite le contrôle au nom fourni sur la ligne de commande SSH. exec correspond lorsque sa commande se termine avec succès. Le Match all final clôt cette portée conditionnelle pour les réglages suivants.

Cela suppose qu'aucun réglage antérieur applicable n'ait déjà choisi une commande de proxy ou une route de saut conflictuelle. SSH utilise généralement la première valeur obtenue pour une option, donc une valeur par défaut large placée en haut peut empêcher une condition ultérieure de produire l'effet attendu.

Un socket en écoute est une promesse modeste

La sonde vérifie l'accès TCP à un port local. Elle n'achève pas la négociation SOCKS, n'établit pas la connexion de destination voulue et ne prouve pas quel programme possède ce port. L'écouteur peut aussi disparaître après le contrôle.

Le délai d'attente garde une sonde échouée bornée. Les options montrées appartiennent à l'interface nc d'OpenBSD ; d'autres programmes portant ce nom de fichier peuvent exposer des options différentes.

Lorsque la condition ne correspond pas, cet exemple laisse la connexion sans ce ProxyCommand, ce qui autorise sa route habituelle. Cela n'est approprié que si l'accès direct est permis. Une politique de proxy obligatoire ne devrait pas utiliser un contrôle de disponibilité comme autorisation de s'échapper sur une autre route.

Le nom d'hôte SSH cible et les contrôles de clé d'hôte identifient toujours le serveur de destination. Choisir un auxiliaire de transport n'est pas une raison d'accepter une clé d'hôte inattendue.

Articles similaires