phpseclib 3 aanvaar 'n oop stroomhulpbron waar sy SSH/SFTP-konstruktor andersins 'n gasheernaam sou ontvang. Dit is die openbare oorhandigingspunt vir 'n verbinding wat reeds deur 'n proxy gedra word.

Eers bou die verbindingskomponent 'n HTTP CONNECT- of SOCKS-tonnel na die werklike SFTP-bediener en poort. Gee dan die gevestigde stroom aan SFTP door:

use phpseclib3\Net\SFTP;

$sftp = new SFTP($tunnel);

$actualHostKey = $sftp->getServerPublicHostKey();
if ($actualHostKey === false
    || !hash_equals($expectedHostKey, $actualHostKey)) {
    throw new RuntimeException('Unexpected SFTP server key');
}

if (!$sftp->login($sftpUser, $sftpCredential)) {
    throw new RuntimeException('SFTP login failed');
}

$tunnel is 'n bestaande gekoppelde stroom, nie 'n proxy-URL nie. $expectedHostKey is die bediener se vertroude publieke-sleutelstring wat deur die toepassing se voorsieningsproses verkry is, in die formaat wat phpseclib teruggee. Die aanmeldgegewens kan die ondersteunde wagwoord of 'n gelaaide sleutelobjek wees wat die toepassing kies.

Bepaal wat die verbindingskomponent teruggee

Die stroom moet reeds na die SFTP-bediener lei. Vir HTTP CONNECT beteken dit die proxy het die bestemming aanvaar en die volledige proxy-antwoordopskrifte is verbruik. Vir SOCKS moet die betrokke onderhandeling suksesvol afgehandel wees. Enige SSH-grepe wat reeds verby daardie grens gelees is, moet vir die SSH-implementering beskikbaar bly.

Op daardie punt doen phpseclib die SSH-uitruiling en begin SFTP oor dieselfde stroom. Die toepassing kan sy gewone SFTP-bewerkings gebruik. Die konstruktor-koppelvlak vermy 'n toepassing-subklas wie se taak dit sou wees om interne socket-velde te vervang.

Verwante artikels