سوکت بازشده از طریق SOCKS را به ssh2 بدهید
ابتدا اتصال 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 را مجاز کند. برای روش نام کاربری/گذرواژه آن، از socks.auth.UserPassword(proxyUser, proxyPassword) در auths استفاده کنید. این اعتبارنامهها جایگزین حساب SSH نمیشوند.
localDNS false نام میزبان مقصد را به سرور SOCKS میفرستد و از تفکیک مقصد در سمت پروکسی استفاده میکند. بدون این انتخاب صریح، پیشفرض مستندشده socksv5 تفکیک محلی را امتحان میکند.
callback مربوط به SOCKS پس از مذاکره اجرا میشود. پیش از درخواست SFTP منتظر رویداد ready در ssh2 بمانید. اینها مراحل موفق جداگانهای هستند؛ نه اتصال TCP به پروکسی و نه پاسخ SOCKS ثابت نمیکند که احراز هویت SSH یا زیرسیستم SFTP موفق شده است.