Gi ssh2 sockelen som ble åpnet gjennom SOCKS
Forhandle SOCKS-forbindelsen først, og overlever deretter mål-sockelen til ssh2 før SFTP-undersystemet åpnes.
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.