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 목적지와 포트를 허용해야 합니다. 사용자 이름/비밀번호 방식에는 auths에 socks.auth.UserPassword(proxyUser, proxyPassword)을 사용하세요. 그 자격 증명이 SSH 계정을 대신하지는 않습니다.
localDNS false는 목적지 호스트 이름을 SOCKS 서버로 넘기며 프록시 측 목적지 해석을 사용합니다. 이 명시적 선택이 없으면 socksv5의 문서화된 기본값은 로컬 해석을 시도합니다.
SOCKS 콜백은 협상 후에 실행됩니다. SFTP를 요청하기 전에 ssh2의 ready 이벤트를 기다리세요. 이들은 별개의 성공 단계입니다. 프록시로의 TCP 연결이나 SOCKS 응답 어느 것도 SSH 인증이나 SFTP 하위 시스템이 성공했음을 증명하지 않습니다.