ssh2-ს გადაეცით SOCKS-ით გახსნილი სოკეტი
ჯერ მოაწესრიგეთ SOCKS კავშირი, შემდეგ SFTP ქვესისტემის გახსნამდე მისი დანიშნულების სოკეტი გადაეცით ssh2-ს.
ssh2 უკვე დაკავშირებულ ნაკადს თავისი sock პარამეტრით იღებს. მიეცით socksv5-ს SSH სერვერამდე მარშრუტის დამყარების საშუალება, შემდეგ ეს ნაკადი 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 აპლიკაციის არსებული SSH კონფიგურაციაა, მათ შორის ანგარიში, გასაღები და hostVerifier პოლიტიკა. SOCKS ჰოსტი და პორტი შუამავალს აღნიშნავს; sshConfig.host და port საბოლოო SSH სერვისს აღნიშნავს.
მაგალითი იყენებს ავთენტიფიკაციის გარეშე SOCKS ბოლო წერტილს. საჯარო ინტერნეტიდან მისაწვდომი SSH სერვერისთვის SOCKS5 პროქსების სია კანდიდატებს მოგვცემს; თითოეულმა მაინც უნდა დაუშვას SSH დანიშნულება და პორტი. მისი მომხმარებლის სახელი/პაროლი მეთოდისთვის auths-ში გამოიყენეთ socks.auth.UserPassword(proxyUser, proxyPassword). ეს მონაცემები SSH ანგარიშს არ ცვლის.
localDNS false დანიშნულების ჰოსტის სახელს SOCKS სერვერს გადასცემს და იყენებს პროქსის მხარეს დანიშნულების გადაწყვეტას. ამ ცხადი არჩევანის გარეშე socksv5-ის დოკუმენტირებული ნაგულისხმევი ლოკალურ გადაწყვეტას ცდილობს.
SOCKS-ის უკუგამოძახება მოლაპარაკების შემდეგ მუშაობს. SFTP-ის მოთხოვნამდე დაელოდეთ ssh2-ის ready მოვლენას. ეს ცალკეული წარმატებული ეტაპებია; არც პროქსისთან TCP კავშირი და არც SOCKS პასუხი არ ამტკიცებს, რომ SSH ავთენტიფიკაცია ან SFTP ქვესისტემა წარმატებით დასრულდა.