Entregue ao ssh2 o soquete aberto através do SOCKS

O ssh2 aceita um fluxo já conectado por meio de sua opção sock. Deixe o socksv5 estabelecer a rota até o servidor SSH e então entregue esse fluxo ao SSH:

const socks = require('socksv5');
const { Client } = require('ssh2');

const connection = socks.connect({
  host: sshConfig.host,
  port: sshConfig.port || 22,
  proxyHost: 'proxy.example',
  proxyPort: 1080,
  localDNS: false,
  auths: [socks.auth.None()],
}, socket => {
  const ssh = new Client();
  ssh.on('error', error => console.error(error.message));
  ssh.on('ready', () => {
    ssh.sftp((error, sftp) => {
      if (error) {
        console.error(error.message);
        ssh.end();
        return;
      }
      sftp.readdir('.', (error, entries) => {
        if (error) console.error(error.message);
        else console.log(entries);
        ssh.end();
      });
    });
  });
  ssh.connect({ ...sshConfig, sock: socket });
});
connection.on('error', error => console.error(error.message));

sshConfig é a configuração SSH existente da aplicação, incluindo a conta, a chave e a política hostVerifier. O host e a porta SOCKS identificam o intermediário; sshConfig.host e port identificam o serviço SSH final.

O exemplo usa um endpoint SOCKS sem autenticação. Para um servidor SSH acessível pela internet pública, a lista de proxies SOCKS5 pode fornecer candidatos; cada um ainda precisa permitir o destino e a porta SSH. Para o método de utilizador/palavra-passe, use socks.auth.UserPassword(proxyUser, proxyPassword) em auths. Essas credenciais não substituem a conta SSH.

localDNS false passa o nome do host de destino ao servidor SOCKS, usando a resolução de destino do lado do proxy. Sem essa escolha explícita, o padrão documentado do socksv5 tenta a resolução local.

O callback do SOCKS corre após a negociação. Aguarde o evento ready do ssh2 antes de pedir SFTP. São fases bem-sucedidas separadas; nem uma ligação TCP ao proxy nem uma resposta SOCKS provam que a autenticação SSH ou o subsistema SFTP tiveram êxito.