SSH ProxyCommand échoue avec command not found

connect: command not found signifie que SSH n'a pas pu lancer son assistant ProxyCommand localement. Il n'y a pas encore de poignée de main proxy à réparer. Le nom peut désigner un exécutable distinct, et non une commande interne du shell ou une sous-commande d'OpenSSH.

1. Retrouvez la commande sélectionnée. Examinez la configuration SSH effective pour le même alias de destination et le même compte. Les sections Host, les fichiers inclus et les options de ligne de commande peuvent sélectionner un ProxyCommand différent de celui du fichier que vous avez modifié.
2. Localisez son exécutable. Comparez le PATH de l'environnement de lancement avec le terminal interactif où l'assistant fonctionne. Un chemin absolu vers le programme existant prévu lève cette ambiguïté.
3. Alignez l'implémentation de l'assistant. Ne remplacez pas n'importe quel binaire nommé nc. OpenBSD netcat utilise -X connect pour HTTP CONNECT et -X 5 pour SOCKS5 ; d'autres variantes peuvent ne pas disposer de ces options ni de la prise en charge de l'authentification du proxy.

Une fois l'assistant lancé, suivez l'échec suivant dans l'ordre : connexion au proxy, négociation proxy, connexion à la destination, puis authentification SSH. Un échec à une étape ne prouve pas un problème aux étapes suivantes.

ProxyJump exige un hôte de rebond SSH. Il ne peut remplacer cette organisation que lorsque ce service est disponible ; un proxy HTTP ne devient pas un point de connexion SSH parce que le réglage a changé.