connect: command not found significa che SSH non è riuscito ad avviare localmente il proprio helper ProxyCommand. Non c'è ancora nessun handshake del proxy da riparare. Il nome può riferirsi a un eseguibile separato, non a un comando interno della shell né a un sottocomando di OpenSSH.

  1. Trovate il comando selezionato. Esaminate la configurazione SSH effettiva per lo stesso alias di destinazione e lo stesso account. Le sezioni Host, i file inclusi e le opzioni della riga di comando possono selezionare un ProxyCommand diverso dal file che avete modificato.
  2. Individuate il suo eseguibile. Confrontate il PATH dell'ambiente di avvio con il terminale interattivo in cui l'helper funziona. Un percorso assoluto al programma esistente previsto elimina questa ambiguità.
  3. Allineate l'implementazione dell'helper. Non sostituite un qualsiasi binario chiamato nc. OpenBSD netcat usa -X connect per HTTP CONNECT e -X 5 per SOCKS5; altre varianti potrebbero non avere queste opzioni né il supporto all'autenticazione del proxy.

Dopo l'avvio dell'helper, seguite il guasto successivo in ordine: connessione al proxy, negoziazione del proxy, connessione alla destinazione, poi autenticazione SSH. Un guasto in una fase non dimostra un problema nelle fasi successive.

ProxyJump richiede un host di salto SSH. Può sostituire questa disposizione solo quando quel servizio è disponibile; un proxy HTTP non diventa un punto di accesso SSH perché l'impostazione è cambiata.

Articoli correlati