ssh2 przyjmuje już połączony strumień poprzez swoją opcję sock. Pozwól socksv5 ustanowić trasę do serwera SSH, a następnie przekaż ten strumień do 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 to istniejąca konfiguracja SSH aplikacji, obejmująca konto, klucz i politykę hostVerifier. Host i port SOCKS wskazują pośrednika; sshConfig.host i port wskazują końcową usługę SSH.

Przykład używa punktu końcowego SOCKS bez uwierzytelniania. Dla serwera SSH osiągalnego z publicznego internetu lista proxy SOCKS5 może dostarczyć kandydatów; każdy z nich nadal musi zezwalać na cel i port SSH. W przypadku metody nazwy użytkownika/hasła użyj socks.auth.UserPassword(proxyUser, proxyPassword) w auths. Te dane uwierzytelniające nie zastępują konta SSH.

localDNS false przekazuje nazwę hosta docelowego do serwera SOCKS, korzystając z rozwiązywania celu po stronie proxy. Bez tego wyraźnego wyboru udokumentowane ustawienie domyślne socksv5 próbuje rozwiązywania lokalnego.

Wywołanie zwrotne SOCKS działa po negocjacji. Przed żądaniem SFTP poczekaj na zdarzenie ready w ssh2. To odrębne udane etapy; ani połączenie TCP z proxy, ani odpowiedź SOCKS nie dowodzą, że uwierzytelnianie SSH lub podsystem SFTP zakończyły się powodzeniem.

Powiązane artykuły