ssh2 tar imot en strøm som allerede er tilkoblet, via sock-valget. La socksv5 bygge ruten til SSH-serveren, og overlever deretter strømmen til 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 er applikasjonens eksisterende SSH-oppsett, inkludert kontoen, nøkkelen og hostVerifier-regelen. SOCKS-vert og -port peker på mellomleddet; sshConfig.host og port peker på den endelige SSH-tjenesten.

Eksempelet bruker et SOCKS-endepunkt uten autentisering. For en SSH-server som nås fra åpent internett, kan SOCKS5-proxyoversikten gi kandidater; hver av dem må likevel tillate SSH-målet og -porten. For brukernavn/passord-metoden brukes socks.auth.UserPassword(proxyUser, proxyPassword) i auths. Disse påloggingsdetaljene erstatter ikke SSH-kontoen.

localDNS false sender vertsnavnet til målet til SOCKS-serveren og bruker måloppslag på proxy-siden. Uten dette bevisste valget forsøker socksv5 sin dokumenterte standard lokalt oppslag.

SOCKS-tilbakekallet kjører etter forhandlingen. Vent på ready-hendelsen i ssh2 før SFTP forespørres. Dette er atskilte vellykkede trinn; verken TCP-forbindelsen til proxyen eller SOCKS-svaret beviser at SSH-autentiseringen eller SFTP-undersystemet gikk bra.

Relaterte artikler