Donnez à OpenSSH sous Windows une commande Ncat SOCKS5 explicite

Utilisez Ncat comme assistant de transport du flux standard d’OpenSSH et précisez SOCKS5 au lieu de vous fier au proxy HTTP par défaut.

Si Ncat est déjà disponible pour OpenSSH sous Windows, il peut fournir la connexion via un proxy SOCKS5. Ajoutez une entrée d’hôte à la configuration SSH utilisée par ce client OpenSSH :

Host target-via-socks
    HostName ssh.example
    User user
    ProxyCommand ncat.exe --proxy-type socks5 --proxy proxy.example:1080 %h %p

Remplacez les deux noms d’hôte et le compte, puis connectez-vous avec ssh target-via-socks. Cet exemple suppose que ncat.exe se trouve dans le chemin de recherche des exécutables de l’assistant. Sinon, utilisez le chemin complet de l’exécutable correctement entre guillemets, surtout lorsque le dossier contient des espaces.

Le point de terminaison du proxy se place après --proxy. OpenSSH développe %h et %p en nom d’hôte et port SSH finaux. Ncat négocie la connexion SOCKS et transporte le flux d’octets résultant sur l’entrée et la sortie standard ; OpenSSH poursuit sa poignée de main SSH sur ce flux.

Le --proxy-type socks5 explicite est important. Sans cette option, Ncat utilise par défaut un proxy HTTP, même si le port fourni est 1080. Un écouteur SOCKS ne peut pas déduire qu’une requête HTTP CONNECT était censée être du SOCKS.

Cet exemple suppose un point de terminaison SOCKS non authentifié ; choisissez un candidat dans la liste de proxys SOCKS5 uniquement pour une destination SSH publique où cette route est autorisée, et vérifiez l’accès à son hôte et à son port réels. L’authentification du proxy, lorsqu’elle est requise, est distincte de la connexion SSH ultérieure. Conservez la vérification de la clé d’hôte de la destination SSH ; y accéder via un assistant ne change pas l’identité qu’OpenSSH doit authentifier.

Articles similaires