ssh2 akceptas jam konektitan fluon per sia opcio sock. Lasu socksv5 starigi la itineron al la SSH-servilo, poste transdonu tiun fluon al 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 estas la ekzistanta SSH-agordo de la aplikaĵo, inkluzive de ĝia konto, ŝlosilo kaj hostVerifier-politiko. La SOCKS-gastiganto kaj -pordo identigas la peranton; sshConfig.host kaj port identigas la finan SSH-servon.

La ekzemplo uzas SOCKS-finpunkton sen aŭtentigo. Por SSH-servilo atingebla el la publika interreto, la listo de SOCKS5-prokuriloj povas liveri kandidatojn; ĉiu ankoraŭ devas permesi la SSH-celon kaj -pordon. Por ĝia uzantnomo/pasvorta metodo, uzu socks.auth.UserPassword(proxyUser, proxyPassword) en auths. Tiuj akreditaĵoj ne anstataŭas la SSH-konton.

localDNS false transdonas la celan gastigantan nomon al la SOCKS-servilo, uzante celrezolucion ĉe la prokurila flanko. Sen tiu eksplicita elekto, la dokumentita defaŭlto de socksv5 provas lokan rezolucion.

La SOCKS-revoko ruliĝas post la intertraktado. Atendu la ready-eventon de ssh2 antaŭ ol peti SFTP. Temas pri apartaj sukcesaj etapoj; nek TCP-konekto al la prokurilo nek SOCKS-respondo pruvas, ke la SSH-aŭtentigo aŭ la SFTP-subsistemo sukcesis.

Rilataj artikoloj