scp über SFTP: entfernte Pfade schreiben, die tatsächlich aufgelöst werden

Ein scp-Befehl, der jahrelang in einem Skript funktionierte, kann auf einem aktuellen Client mit einem Pfadfehler scheitern, der nichts mit dem Tunnel zu tun hat. Das VPN übertrug die Bytes; der Client fragte den Server nach einem Namen, den der Server nicht auflösen konnte. Aktuelles OpenSSH-scp überträgt standardmäßig über SFTP, und SFTP führt keine Erweiterung im Shell-Stil durch wie das alte Protokoll. Wenn Sie den Befehl von Ihrem eigenen Konto aus nach außen verfolgen, sehen Sie, wo der Pfad wirklich interpretiert wird.

Beginnen Sie beim Konto, dann beim Verzeichnis, in das es schreiben kann

Der Doppelpunkt trennt zwei Namensräume, und nur die linke Seite gehört zu dem Rechner, auf dem Sie tippen. Alles danach löst der Server auf, unter dem Konto, als das Sie sich authentifiziert haben, innerhalb der Dateisystemsicht, die dieses Konto hat. Bestätigen Sie beides, bevor Sie den Befehl zusammenstellen, denn ein Pfad, der für den Administrator korrekt ist, ist nicht automatisch für den Übertragungsbenutzer korrekt. Dieser Unterschied ist die Ursache der meisten Berechtigungsfehler, die wie Netzwerkstörungen aussehen.

Fragen Sie den Server nach seiner eigenen Sicht: ssh [email protected] pwd und ssh [email protected] ls -ld /srv/archive. Wenn der zweite Befehl Zugriff verweigert meldet, ist der Tunnel in Ordnung und der Pfad für dieses Konto unbrauchbar. Korrigieren Sie den Besitz oder wählen Sie ein anderes Ziel, statt Berechtigungen zu erweitern, damit die Übertragung fortgesetzt werden kann.

Eine eingeschränkte SFTP-Konfiguration kann ein chroot als Wurzel des Dateisystems präsentieren. Innerhalb dieser Sicht ist ein absoluter Pfad absolut innerhalb des chroot, was nicht derselbe Ort ist, den der Administrator auf dem Host sieht.

Benennen Sie beide Seiten des Doppelpunkts ausdrücklich

Ein Upload sollte den entfernten Dateinamen angeben, statt anzunehmen, dass der lokale Basisname auf der anderen Seite akzeptabel ist.

scp q3-invoice.csv [email protected]:/home/transfer/drop/q3-invoice.csv

Ein Download sollte das lokale Ziel aus genau demselben Grund angeben. Die beiden Namensräume sind unabhängig, und ein Skript, das Übereinstimmung annimmt, bricht beim ersten Mal, wenn der entfernte Baum eine andere Struktur verwendet.

scp [email protected]:/srv/archive/2026-q3.csv ./2026-q3.csv

Vermeiden Sie ~otheruser in einem gepflegten Skript. Das Erweitern des Home-Verzeichnisses eines anderen Kontos war eine Funktion der entfernten Shell, und ein SFTP-Server implementiert die Erweiterung, die sie nachahmt, möglicherweise nicht. Schreiben Sie den absoluten Pfad, den das Konto tatsächlich öffnen kann, und setzen Sie lokale Pfade mit Leerzeichen in Anführungszeichen, statt Anführungszeichen-Ebenen zu kopieren, die für eine Shell auf dem Server geschrieben wurden.

Wissen Sie, welches Protokoll Ihr scp tatsächlich verwendet

Seit OpenSSH 9.0 verwendet der Client standardmäßig SFTP, und Distributionen übernehmen oder backporten dieses Verhalten nach ihrem eigenen Zeitplan. Die Versionszeichenfolge sagt, was der Client beabsichtigt, aber ein Hersteller-Build kann vom Upstream abweichen, prüfen Sie also den Client, den Sie tatsächlich ausführen: ssh -V.

Die beiden Protokolle lösen Namen unterschiedlich auf. Altes SCP bittet die entfernte Benutzer-Shell, den Pfad zu erweitern, daher werden Platzhalter und Tilden von dieser Shell nach ihren eigenen Regeln behandelt. SFTP gibt stattdessen Dateiübertragungsoperationen aus, daher wird ein Platzhalter entweder vom Client erweitert oder gar nicht. Beide reisen innerhalb von SSH zum selben Rechner, weshalb sich ein Host unter zwei Clients unterschiedlich verhalten kann.

scp -v gibt das angeforderte Subsystem aus, und eine sftp-Subsystemzeile bestätigt, dass der moderne Pfad verwendet wird. scp -O erzwingt das alte Protokoll dort, wo es unterstützt wird und wirklich erforderlich ist, und bringt seine eigenen Quoting-Regeln mit zurück. Es ist keine VPN-Option, kein Weg, etwas auf dem Server zu aktivieren, und kein Grund, die Hostschlüsselprüfung zu lockern.

Testen Sie den Pfad, bevor das Skript davon abhängt

Ein Pfadproblem tritt zum ungünstigsten Zeitpunkt auf, in einem automatisierten Job nachts, wenn niemand zusieht. Beweisen Sie das Ziel zuerst mit einer kleinen Datei und dem genauen Konto, das der Job verwendet, und halten Sie diesen Testbefehl neben der Jobdefinition. Wenn der Test ein anderes Konto oder ein anderes Verzeichnis braucht, braucht der Job es auch.

Prüfen Sie auch die Serverseite. grep -i subsystem /etc/ssh/sshd_config zeigt, ob ein SFTP-Subsystem konfiguriert ist, und sftp -b /dev/null [email protected] endet nur dann erfolgreich, wenn dieses Subsystem antwortet. Ein Host, der SSH-Anmeldungen akzeptiert, aber kein Subsystem hat, scheitert bei jeder modernen Übertragung, während er in einem Anmeldetest völlig gesund aussieht.

Notieren Sie die Clientversion, das verwendete Protokoll und den absoluten entfernten Pfad in den Jobnotizen. Wenn das nächste Upgrade einen Standard ändert, ist diese Notiz der Unterschied zwischen einer Fünf-Minuten-Korrektur und einem Nachmittag voller Vermutungen.