phpseclib 3 akzeptiert eine offene Stream-Ressource dort, wo sein SSH/SFTP-Konstruktor sonst einen Hostnamen erhält. Das ist die öffentliche Übergabestelle für eine Verbindung, die bereits durch einen Proxy läuft.

Zuerst baut der Connector einen HTTP-CONNECT- oder SOCKS-Tunnel zum tatsächlichen SFTP-Server und Port auf. Danach wird der aufgebaute Stream an SFTP übergeben:

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 ist ein bereits verbundener Stream, keine Proxy-URL. $expectedHostKey ist der vertrauenswürdige Public-Key-String des Servers, den die Anwendung über ihren Bereitstellungsprozess erhält, im von phpseclib zurückgegebenen Format. Das Login-Kennwort kann das unterstützte Passwort oder ein geladenes Schlüsselobjekt sein, das die Anwendung auswählt.

Definieren, was der Connector zurückgibt

Der Stream muss bereits zum SFTP-Server führen. Bei HTTP CONNECT bedeutet das, dass der Proxy das Ziel akzeptiert hat und die vollständigen Proxy-Antwortheader gelesen wurden. Bei SOCKS muss die betreffende Verhandlung erfolgreich abgeschlossen sein. Alle SSH-Bytes, die über diese Grenze hinaus bereits gelesen wurden, müssen für die SSH-Implementierung verfügbar bleiben.

An diesem Punkt führt phpseclib den SSH-Austausch durch und startet SFTP über denselben Stream. Die Anwendung kann ihre gewohnten SFTP-Operationen nutzen. Die Konstruktor-Schnittstelle erspart eine Unterklasse der Anwendung, deren Aufgabe es wäre, interne Socket-Felder zu ersetzen.

Ähnliche Artikel