Alles über das Secure Copy Protocol

Das Secure Copy Protocol (SCP) überträgt Dateien über eine verschlüsselte SSH-Verbindung mithilfe einer Syntax, die die meisten Entwickler auswendig beherrschen. Genau diese Einfachheit ist aber auch das Problem: Das zugrundeliegende Protokoll von SCP stammt aus dem Jahr 1983 (rcp) und wies bereits bekannte Sicherheitslücken auf, darunter eine Command-Injection-Schwachstelle aus dem Jahr 2020 und eine Privilege-Escalation-Schwachstelle aus dem Jahr 2026. OpenSSH selbst verwendet mittlerweile standardmäßig eine sicherere Übertragungsmethode, die denselben Befehlsnamen verwendet.

Veröffentlicht: April 2026. Aktualisiert: August 2026. Geprüft vom SSH- und Schlüsselverwaltungsteam von Encryption Consulting.

Was ist Secure Copy Protocol (SCP) und wie funktioniert es?

SCP ist ein Kommandozeilen-Tool, das Dateien zwischen einem lokalen und einem entfernten Host oder zwischen zwei entfernten Hosts über eine bestehende SSH- Verbindung kopiert. Es existiert, weil das ursprüngliche Remote Copy Protocol (RCP), auf dem es basiert, keinerlei Verschlüsselung bot. SCP übernimmt die einfache Kopiersemantik von RCP und ergänzt sie um die Authentifizierung und Verschlüsselung von SSH, sodass eine Datei während der Übertragung von niemandem im Netzwerk gelesen oder verändert werden kann.

Im Hintergrund läuft eine SCP-Übertragung nach dem Aufbau des SSH-Tunnels in zwei Richtungen ab. Im Sink-Modus werden Dateien vom lokalen Rechner zum Remote-Rechner übertragen; im Source-Modus werden Dateien vom Remote-Rechner zum lokalen Rechner übertragen. Welcher Modus zum Einsatz kommt, hängt ausschließlich von der Befehlsformulierung ab, nicht von einzelnen Parametern: SCP startet einfach den entsprechenden SCP-Prozess. scp Die Verarbeitung erfolgt auf der Gegenseite und die Dateidaten werden über den SSH-Kanal gestreamt.

Die grundlegende Befehlsstruktur ist:

scp [Optionen] Quelle Ziel

So übertragen Sie eine lokale Datei auf einen Remote-Host:

scp file.txt user@remote_host:/home/user/

Um dieselbe Datei wieder in das aktuelle lokale Verzeichnis herunterzuladen:

scp user@remote_host:/home/user/file.txt .

Der nachfolgende Punkt ist wichtig: Er weist SCP an, die Datei in das Verzeichnis zu schreiben, aus dem der Befehl ausgeführt wird. -r Ein gesamtes Verzeichnis rekursiv kopieren. Zur Authentifizierung funktioniert die Anmeldung mit einem Passwort, aber die SSH-Schlüsselauthentifizierung ist der Standard für automatisierte oder wiederholte Vorgänge.

scp -i ~/.ssh/id_rsa file.txt user@remote_host:/home/user/

Weitere Flaggen, die man kennen sollte: -v für ausführliche Ausgaben bei Verbindungsproblemen, -P einen nicht standardmäßigen SSH-Port festlegen, und -p Um die Änderungszeiten und Berechtigungen der Dateien in der Kopie beizubehalten, ist es wichtig, den Doppelpunkt im Remote-Pfad zu vergessen. Dies ist der häufigste Fehler, da SCP sonst das gesamte Argument als lokalen Pfad anstatt als Remote-Pfad interpretiert.

SCP vs. SFTP vs. Rsync über SSH: Wie schneiden sie im Vergleich ab?

Alle drei Tools übertragen Dateien über einen verschlüsselten SSH-Kanal, nutzen dabei aber sehr unterschiedliche Protokolldesigns. Genau diese Unterschiede sind die Ursache für die Sicherheits- und Zuverlässigkeitslücken. SFTP selbst entstand aus demselben Bedürfnis wie SCP: Eine detailliertere Betrachtung dieses Protokolls finden Sie in unserer Analyse des Secure File Transfer Protocol (SFTP) und seiner Vorteile.

Das ältere scp/rcp-Protokoll funktioniert, indem es den lokalen scp Client ruft eine Remote-Anwendung auf scp Prozess mit undokumentierten Flags (-t für Spüle -f Beim SCP-Protokoll werden zunächst die Quelldateien (z. B. die Dateipfade) übergeben, die die entfernte Shell teilweise interpretiert, inklusive Wildcard-Erweiterung. Diese Shell-Interaktion ist die Ursache für die gravierendsten Schwächen von SCP. SFTP ersetzt dies vollständig durch ein speziell entwickeltes, paketbasiertes Anfrage-Antwort-Protokoll: Der Client fordert einzelne Operationen an (Öffnen, Lesen, Schreiben, Statusabfrage, Umbenennen), und der Server antwortet, ohne dass zu irgendeinem Zeitpunkt Shell-Befehle erstellt werden. Rsync-over-SSH verfolgt einen dritten Ansatz: Es nutzt SSH lediglich als sicheren Transportmechanismus, während das rsync-eigene Protokoll den eigentlichen Vergleich und die Übertragung übernimmt, einschließlich Delta-Codierung, sodass nur die geänderten Teile einer Datei übertragen werden.

Capability	SCP	SFTP	Rsync über SSH
Transfermodell	Shell-basiertes Push/Pull	Anfrage-Antwort-Subsystem	Delta-Synchronisierung über SSH-Transport
Unterbrochene Übertragung fortsetzen	Nein	Ja, teilweise Dateiunterstützung	Ja, dafür gebaut.
Verzeichnissynchronisierung / inkrementelle Kopie	Nein, immer eine vollständige Dateikopie.	Begrenzt, pro Sitzung	Ja, natürliche Stärke
Interaktives Remote-Browsing	Nein	Ja (ls, cd, rm in der Sitzung)	Nein
Shell-Befehlskonstruktion auf der Remote-Seite	Ja, nur das Legacy-Protokoll	Nein	Nein (rsync-Protokoll, nicht Shell)
Standard in OpenSSH 9.0+	scp verwendet intern jetzt SFTP.	Ja	Nicht zutreffend, separates Werkzeug
Optimale Bildschirmwahl	Schnelle, skriptgesteuerte Einmalkopien auf vertrauenswürdigen, gepatchten Hosts	Sichere Dateiübertragung für allgemeine Zwecke, Automatisierung, Compliance-Protokollierung	Große Datensätze, Spiegelung, wiederholte Synchronisierungen, unzuverlässige Verbindungen

In der Praxis sollten die meisten Teams für alles, was über eine einmalige Ad-hoc-Kopie hinausgeht, standardmäßig SFTP verwenden und auf rsync zurückgreifen, wenn es bei der Arbeitslast tatsächlich um Synchronisierung und nicht um einmalige Zustellung geht.

Welche bekannten Sicherheitslücken weist SCP auf?

Das ältere scp/rcp-Protokoll von SCP weist zwei bekannte, in CVE-Listen erfasste Schwachstellen auf, über die Sicherheitsteams Bescheid wissen sollten, bevor sie es für neue Implementierungen standardisieren.

CVE-2020-15778 ist eine Command-Injection-Schwachstelle im SCP-Client von OpenSSH 8.3p1 (CVSS 3.1-Wert: 7.4, hoch). Ein Zielargument mit Backtick-Zeichen kann auf dem Remote-Server als Shell-Befehl interpretiert und ausgeführt werden, da das ältere Protokoll Dateinamen an die Remote-Shell weiterleitet, anstatt sie als reine Daten zu behandeln. Die OpenSSH-Entwickler geben an, absichtlich auf die Validierung sogenannter „anomaler Argumentübertragungen“ zu verzichten, da eine strengere Validierung das Risiko birgt, etablierte Skripte und Arbeitsabläufe zu beeinträchtigen. Genau diese Haltung ist der Grund, warum die Schwachstelle so lange ohne vollständige Behebung im OpenSSH-Projekt blieb, obwohl mehrere Distributionen bereits eigene Abhilfemaßnahmen veröffentlichten.

CVE-2026-35385 ist ein neueres Problem der Rechteausweitung, das OpenSSH vor Version 10.3 betrifft (CVSS 3.1-Wert: 7.5, hoch). Wenn eine Datei heruntergeladen wird mit scp als Root unter Verwendung des Legacy-Protokolls ( -O Flagge), ohne auch zu übergeben -p Um den Dateimodus beizubehalten, kann die resultierende Datei mit Setuid- oder Setgid-Rechten installiert werden – ein Ergebnis, das die meisten Administratoren weder erwarten noch beabsichtigen. Dies stellt eine echte Möglichkeit zur Rechteausweitung auf jedem System dar, auf dem der Root-Benutzer regelmäßig Dateien per SCP herunterlädt. Die Korrektur wurde in OpenSSH 10.3p1 veröffentlicht.

Beide Probleme lassen sich auf dieselbe Ursache zurückführen: Das veraltete scp/rcp-Protokoll vertraut der Gegenstelle mehr, als ein modernes Übertragungsprotokoll sollte, und es wurde nie für die heutigen Bedrohungen konzipiert. Genau deshalb wurde ab OpenSSH 9.0 im Jahr 2022 Folgendes eingeführt: scp Der Befehl verwendet standardmäßig intern das SFTP-Protokoll. scp Eine aktuelle OpenSSH-Version verwendet das anfällige Legacy-Protokoll nicht mehr, es sei denn, es wird explizit dazu gezwungen. -O Red Hat ging in RHEL 9 noch einen Schritt weiter und erklärte den veralteten scp/rcp-Protokollpfad offiziell für veraltet und kennzeichnete ihn zur späteren Entfernung, genau weil, wie Red Hat es ausdrückte, das Protokoll „mehrere Sicherheitsrisiken und Probleme birgt, für die es keine einfachen Lösungen gibt“, da es „von Natur aus authentifizierten Sitzungen vertraut“.

Die praktische Schlussfolgerung: Wenn auf Ihren Systemen eine aktuelle OpenSSH-Version installiert ist, geben Sie Folgendes ein: scp Läuft heutzutage wahrscheinlich schon über SFTP. Falls Sie es dennoch erzwingen, -O Aus Gründen der Kompatibilität mit älteren Systemen oder beim Ausführen ungepatchter OpenSSH-Versionen sind Sie den beiden oben genannten CVEs ausgesetzt.

Wem sollten die SSH-Schlüssel hinter SCP-Übertragungen gehören?

SCP ist nur so sicher wie der SSH-Schlüssel, der es authentifiziert, und im Gegensatz zu einem TLS-Zertifikat hat ein SSH-Schlüssel kein integriertes Ablaufdatum. Die Inhaberschaft muss explizit zugewiesen werden, sonst häufen sich die Schlüssel einfach an. In der Praxis verteilt sich die Inhaberschaft über den gesamten Lebenszyklus auf drei Rollen:

• Sicherheits- oder Identitätsteam: Besitzt die Ausgaberichtlinie, die genehmigten Schlüsseltypen und -längen sowie das zentrale Inventar aller verwendeten Schlüssel, einschließlich der in Skripten und CI/CD-Pipelines eingebetteten Schlüssel.
• System- oder Anwendungsbesitzer: besitze die authorized_keys Einträge befinden sich auf ihren eigenen Servern und sie sind dafür verantwortlich, den Zugriff zu entfernen, wenn ein Benutzer, ein Dienst oder ein Vertrag endet.
• Plattform- oder DevOps-Teams: Sie verfügen über eigene automatisierte Dateiübertragungsschlüssel, die von Build-Pipelines, Backup-Jobs und Integrationen verwendet werden, und sind dafür verantwortlich, jeden Schlüssel auf den einzelnen Host und Befehl zu beschränken, den er tatsächlich benötigt.

Wenn eine dieser Rollen nicht eindeutig zugeordnet ist, werden SSH-Schlüssel standardmäßig demjenigen zugewiesen, der sie erstellt hat. So kommt es, dass Organisationen am Ende Schlüssel besitzen, an deren Vergabe sich niemand mehr erinnert und die niemand mehr löschen möchte.

Wann sollten die von SCP verwendeten SSH-Schlüssel rotiert werden?

Die Rotation sollte ereignisgesteuert und nicht nur kalenderbasiert erfolgen, wobei ein Kalender als zusätzliche Sicherheitsmaßnahme weiterhin sinnvoll ist. Zu den Auslösern, die eine Rotation des SSH-Schlüssels für jedes mit SCP oder SFTP verwendete Konto erzwingen sollten, gehören:

1. Eine feste maximale Gültigkeitsdauer für Schlüssel, üblicherweise 90 bis 180 Tage für interaktive Benutzerschlüssel und kürzer für Dienstkonten mit hohen Berechtigungen.
2. Das Ausscheiden eines Mitarbeiters oder Auftragnehmers bzw. ein Rollenwechsel, der den Zugriff auf einen bestimmten Host überflüssig macht.
3. Verdacht auf oder bestätigte Kompromittierung einer Workstation, eines Build-Servers oder des Schlüsselmaterials selbst.
4. Eine offengelegte Schwachstelle im verwendeten SSH-Client, -Server oder in der Schlüsselgenerierungsbibliothek, wie beispielsweise CVE-2026-35385 oben.
5. Die Migration eines Systems auf eine neue Infrastruktur ist ein naheliegender Zeitpunkt, um Schlüssel neu auszustellen, anstatt sie einfach zu kopieren.
6. Entdeckung eines Schlüssels während einer Zugriffsprüfung, der keinem dokumentierten Besitzer oder Zweck mehr zugeordnet ist.

Die manuelle Rotation über Dutzende oder Hunderte von Hosts hinweg ist der Punkt, an dem die meisten Organisationen stillschweigend aufgeben. Dies ist das eigentliche Argument für eine zentrale SSH-Schlüsselverwaltung und nicht für eine strengere Rotationsrichtlinie auf dem Papier.

Welche Zugriffsrichtlinie sollte die Berechtigungen für die Dateiübertragung regeln?

Der Zugriff auf Dateiübertragungen sollte dem gleichen Prinzip der minimalen Berechtigungen folgen wie jeder andere Produktionszugriff, ergänzt durch einige SCP- und SFTP-spezifische Kontrollmechanismen:

• Kennwortauthentifizierung deaktivieren für SCP/SFTP-fähige Konten und erfordern stattdessen eine schlüssel- oder zertifikatsbasierte Authentifizierung.
• Einschränkung nach Benutzer und Gruppe und AllowUsers or AllowGroups Richtlinien und nach Quell-IP-Bereich, wobei Übertragungen ausschließlich aus bekannten Netzwerken stammen.
• Chroot und Beschränkung von SFTP-exklusiven Konten mit OpenSSH ChrootDirectory und ForceCommand internal-sftpEin Dateitransferkonto kann daher niemals eine interaktive Shell öffnen.
• Bereich der Servicekontoschlüssel eng mit einem command= Einschränkung in authorized_keys Ein Automatisierungsschlüssel kann also genau einen Übertragungsbefehl für einen einzigen Pfad ausführen, nichts anderes.
• Für neuen Zugriff ist eine Genehmigung erforderlich. auf Produktionshosts anstatt die Möglichkeit der Selbstverwaltung von Schlüsseln zu ermöglichen, und jegliche Ausnahmezugriffe zeitlich zu begrenzen.

Diese Kontrollmechanismen sind wichtiger als die Wahl zwischen SCP und SFTP an sich. Ein gut konfiguriertes SCP-Konto auf einem gehärteten, gepatchten Host ist sicherer als ein uneingeschränktes SFTP-Konto mit gemeinsamem Schlüssel und ohne Protokollierung.

Wie erstellt man Prüfnachweise für Dateiübertragungen?

Sowohl Prüfer als auch Einsatzkräfte im Krisenmanagement benötigen dasselbe: eine Dokumentation darüber, wer was wann wohin transferiert hat. Diese Nachweise stammen aus einigen konkreten Kontrollmechanismen:

• Stelle den LogLevel VERBOSE auf SSH-Servern, die Dateiübertragungen verarbeiten, sodass Authentifizierungsereignisse den spezifischen Fingerabdruck des verwendeten Schlüssels und nicht nur den Benutzernamen enthalten.
• Aktivieren Sie die Protokollierung des SFTP-Subsystems, die einzelne Dateivorgänge (Öffnen, Lesen, Schreiben, Umbenennen, Löschen) aufzeichnet, was mit dem shellbasierten Modell von SCP nicht möglich ist.
• Leiten Sie SSH- und SFTP-Protokolle an einen zentralen, manipulationssicheren Protokollspeicher oder ein SIEM-System weiter, wobei die Aufbewahrungsfrist Ihren Compliance-Anforderungen entspricht (üblicherweise ein Jahr oder länger gemäß PCI DSS und SOC 2).
• Führen Sie regelmäßige Zugriffsüberprüfungen durch, die alle Zugriffe abgleichen. authorized_keys Eintragung gegen Vorlage eines Nachweises über den Eigentümer und die geschäftliche Begründung.
• Ordnen Sie die Protokollierung von Dateiübertragungen und die Kontrollen der Schlüsselinventur direkt den entsprechenden Kontrollfamilien in Rahmenwerken wie ISO/IEC 27001, SOC 2 und PCI DSS zu, sodass die gleichen Nachweise sowohl für Sicherheits- als auch für Prüfungszwecke verwendet werden können.

Hier liegt der strukturelle Vorteil von SFTP gegenüber SCP: Da jede Operation eine einzelne, protokollierte Anfrage und kein Shell-Befehl ist, lassen sich die SFTP-Audit-Trails im Nachhinein viel einfacher rekonstruieren.

Wie sieht ein sicherer Workflow für die Bereitstellung von Dateiübertragungen aus?

Unabhängig davon, ob Sie SCP, SFTP oder rsync verwenden, sollte der Einführungsprozess für einen neuen sicheren Dateiübertragungspfad der gleichen Abfolge folgen:

1. Bestätigen Sie die OpenSSH-Version. Auf jedem betroffenen Host muss mindestens Version 10.3p1 aktualisiert werden, um CVE-2026-35385 zu beheben, oder alternativ eine Version ab 9.0 installiert werden. scp Standardmäßig wird das SFTP-Protokoll verwendet.
2. Wählen Sie das richtige Werkzeug für die jeweilige Arbeitslast: SFTP für allgemeine und automatisierte Übertragungen, rsync für große oder wiederholte Synchronisierungen, SCP nur für schnelle, manuelle, einmalige Kopien auf Hosts, denen Sie vertrauen und die Sie kontrollieren.
3. Generieren Sie SSH-Schlüssel mit Gültigkeitsbereich pro System oder Dienst, unter Verwendung moderner Schlüsseltypen (Ed25519 bevorzugt, RSA 3072-Bit oder höher, wenn Ed25519 nicht unterstützt wird), niemals ein einziger gemeinsamer Schlüssel über mehrere Integrationen hinweg.
4. Serverseitigen Zugriff einschränken und AllowUsers/AllowGroups, gegebenenfalls per chroot eingebundenes SFTP, und command= Beschränkungen für Automatisierungsschlüssel.
5. Ausführliche Protokollierung aktivieren und leiten Sie es vor dem ersten Produktionstransfer an einen zentralen Speicher weiter, nicht erst nach einem Vorfall.
6. Dokumentenverantwortung und Rotationsplan für jeden erstellten Schlüssel, der mit den oben genannten Auslösern verknüpft ist.
7. Testen Sie den Fehlerpfad: Prüfen Sie, was bei einer unterbrochenen Übertragung, einem widerrufenen Schlüssel und einer falsch konfigurierten Berechtigung passiert, bevor Sie sich im Produktivbetrieb auf die Konfiguration verlassen.

Wie unterscheiden sich die SCP- und SFTP-Unterstützungen auf verschiedenen Plattformen?

Linux, macOS und die meisten Unix-Systeme werden mit OpenSSH ausgeliefert. scp und sftp Da Clients und Server integriert sind, ist die Unterstützung konsistent, solange die OpenSSH-Version aktuell ist. Windows schloss diese Lücke ab Windows 10 Version 1809 (veröffentlicht 2018), als Microsoft den OpenSSH-Client und -Server direkt in das Betriebssystem integrierte. Dadurch sind beide Befehle nativ über PowerShell oder das Windows Terminal verfügbar, ohne dass Tools von Drittanbietern wie PuTTY benötigt werden.

Enterprise-Linux-Distributionen raten Nutzern aktiv vom veralteten SCP-Protokoll ab. RHEL 9 hat den alten SCP/RCP-Protokollpfad als veraltet markiert und neue Übertragungen standardmäßig auf das in OpenSSH 9.0 eingeführte SFTP-basierte Verhalten umgestellt. Zudem wird darauf hingewiesen, dass der alte Pfad zukünftig vollständig entfernt wird. Diese Abschaffung bringt eine praktische Schwierigkeit mit sich, die bei der Planung berücksichtigt werden sollte: SCP und SFTP behandeln symbolische Links und Pfade mit Tilde-Erweiterung unterschiedlich. Daher sind Übertragungen zwischen einem modernen und einem älteren Host, die auf dem alten Protokoll basieren, nicht immer zuverlässig. ~ Verknüpfungen können sich unerwartet verhalten. Die Verwendung absoluter Pfade umgeht dieses Problem.

Für Organisationen, die verschiedene OpenSSH-Versionen auf Linux-, Windows- und macOS-Systemen oder ältere Netzwerkgeräte mit älteren, integrierten SSH-Stacks betreiben, besteht die praktikable Lösung nicht darin, das Standardverhalten jeder Plattform einzeln zu verfolgen. Vielmehr empfiehlt sich die zentrale Verwaltung der SSH-Schlüssel und Zugriffsrichtlinien, sodass das vom jeweiligen Host standardmäßig verwendete Übertragungsprotokoll eine geringere Rolle spielt.

Wie sollte man auf kompromittierte Anmeldeinformationen für den Dateitransfer reagieren?

Wenn der Verdacht besteht, dass ein für SCP oder SFTP verwendeter SSH-Schlüssel kompromittiert wurde, ist Geschwindigkeit wichtiger als absolute Fehlerfreiheit. Eine praktische Vorgehensweise:

1. Sofort widerrufen. Entfernen Sie den Schlüssel von jedem authorized_keys Die Datei, in der sie erscheint, wird gelöscht, oder das entsprechende SSH-Zertifikat wird widerrufen, falls eines ausgestellt wurde.
2. Seitliche Bewegungen eindämmen. Prüfen Sie, ob derselbe Schlüssel oder dasselbe Schlüsselmaterial auf anderen Hosts oder Diensten wiederverwendet wurde, und widerrufen Sie ihn auch dort.
3. Protokolle sichern und überprüfen. Ziehen Sie SSH- und SFTP-Protokolle heran, die den vermuteten Expositionszeitraum abdecken, um festzustellen, worauf tatsächlich zugegriffen oder was übertragen wurde.
4. Zugehörige Anmeldeinformationen rotieren. Jeder Schlüssel, der auf derselben kompromittierten Workstation generiert wurde, oder jeder Schlüssel, den ein Angreifer möglicherweise berührt hat, sollte als verdächtig behandelt und ausgetauscht werden.
5. Prüfen Sie, ob Zufahrtswege angelegt wurden. Überprüfen Sie die Host-Schlüssel und authorized_keys Dateien für Einträge, die der rechtmäßige Eigentümer nicht hinzugefügt hat.
6. Interessengruppen benachrichtigen gemäß Ihren Anforderungen an die Reaktion auf Zwischenfälle und, falls zutreffend, an die Offenlegungspflichten gegenüber den Aufsichtsbehörden.
7. Führen Sie eine Nachbesprechung des Vorfalls durch um herauszufinden, wie der Schlüssel offengelegt wurde, und um diese spezifische Lücke zu schließen, sei es ein unverschlüsselter Schlüssel auf der Festplatte, eine zu weit gefasste Zugriffsberechtigung oder eine fehlende Rotationsrichtlinie.

Organisationen, die innerhalb weniger Minuten nach Eingang einer Meldung die Frage „Welcher Schlüssel, welche Hosts, seit wann?“ beantworten können, verfügen bereits vor dem Vorfall über ein tatsächlich vorhandenes SSH-Schlüsselinventar und stellen dieses nicht erst währenddessen zusammen.

Einschränkungen

Neben den oben genannten Sicherheitsproblemen weist SCP funktionale Einschränkungen auf, die es für alles, was über schnelle, manuelle Übertragungen hinausgeht, ungeeignet machen. Unterbrochene Übertragungen können nicht fortgesetzt werden: Schlägt ein Kopiervorgang aufgrund einer Verbindungsunterbrechung oder eines Netzwerkproblems fehl, muss die gesamte Übertragung von vorn beginnen. SCP kennt keine inkrementelle Synchronisierung; selbst die Änderung einer einzigen Zeile in einer großen Datei erfordert das erneute Kopieren der gesamten Datei. Da SCP die Delta-Transfer-Optimierungen, auf denen Tools wie rsync basieren, nicht bietet, ist es bei wiederholten oder umfangreichen Übertragungen ressourcen- und bandbreitenintensiver. Diese Einschränkungen, zusammen mit den oben genannten Sicherheitslücken, sind der Grund, warum SCP am besten für gelegentliche, einmalige Kopien und nicht für produktive Dateiübertragungsprozesse eingesetzt werden sollte.

Was würde Encryption Consulting empfehlen?

Bei Neuinstallationen empfehlen wir Teams SFTP gegenüber SCP und rsync-over-SSH für alle Anwendungen mit umfangreichen oder wiederholten Synchronisierungen. Die Wahl des Protokolls ist jedoch selten der eigentliche Risikofaktor. In nahezu jeder von uns analysierten SCP- oder SFTP-Umgebung stellen unkontrollierte SSH-Schlüssel die größte Gefahr dar: Schlüssel ohne dokumentierten Besitzer, ohne Rotationsplan und ohne Protokoll, das eine Übertragung einer Person oder einem Dienst zuordnet.

Genau diese Lücke schließt SSH Secure . Es bietet Ihnen eine zentrale Übersicht aller SSH-Schlüssel in Ihrer Umgebung, eine automatische Rotation basierend auf den oben beschriebenen Auslösern und die Durchsetzung von Richtlinien, sodass Dateitransferschlüssel auf den jeweiligen Host und Befehl beschränkt bleiben. Für Teams, die auch TLS- oder Codesignaturzertifikate ausstellen und verwalten, sorgt die Kombination mit CertSecure Manager dafür, dass der gesamte Lebenszyklus von Zertifikaten und Schlüsseln zentral und nicht auf verschiedene Tools verteilt ist. Und wenn private Schlüssel in einer gehärteten, FIPS 140-3-konformen Umgebung und nicht auf der Festplatte gespeichert werden müssen, beseitigt HSM-as-a-Service dieses Risiko vollständig.

Wenn Sie sich nicht sicher sind, wo Ihre Organisation heute steht, kann unser Team für Verschlüsselungsberatung eine gezielte Bewertung Ihres SSH-Schlüsselbestands und Ihrer Dateitransfer-Zugriffskontrollen durchführen und Ihnen einen priorisierten Sanierungsplan aushändigen, nicht nur eine Liste der Ergebnisse.

Fazit

SCP hat nach wie vor seine Berechtigung für schnelle, manuelle und einmalige Kopien zwischen zwei vertrauenswürdigen Hosts. Für automatisierte, wiederholte oder Compliance-Prüfungen unterliegende Vorgänge ist SFTP jedoch die technisch ausgereiftere Wahl und bereits Standard in modernen Systemen. scp Der Befehl wird standardmäßig ausgeführt. Rsync-over-SSH übernimmt dann, wenn es bei der Aufgabe tatsächlich um die Synchronisierung großer oder sich häufig ändernder Datensätze geht und nicht um die Übertragung einer einzelnen Datei.

All das ist jedoch irrelevant, wenn die SSH-Schlüssel, die der Übertragung zugrunde liegen, keinen Besitzer, keinen Rotationsplan und keine Protokollierung haben. Die korrekte Implementierung des Protokolls ist in einem Nachmittag erledigt. Entscheidend für die langfristige Sicherheit von Dateiübertragungen ist jedoch das korrekte Lebenszyklusmanagement der SSH-Schlüssel – und genau hier besteht bei den meisten Organisationen noch erheblicher Handlungsbedarf.

Häufig gestellte Fragen

Ist die Verwendung von SCP im Jahr 2026 noch sicher?
Auf einer aktuellen, gepatchten OpenSSH-Version, die ausgeführt wird scp ist relativ sicher, da es nun standardmäßig das SFTP-Protokoll verwendet und nicht mehr das anfällige ältere scp/rcp-Protokoll. Das Risiko kehrt zurück, wenn Sie es erzwingen. -O Flag für Kompatibilität oder wenn auf dem Host eine ungepatchte OpenSSH-Version ausgeführt wird, die von CVE-2020-15778 oder CVE-2026-35385 betroffen ist.

Worin besteht der eigentliche Unterschied zwischen SCP und SFTP?
Das ältere SCP-Protokoll erstellt und führt Shell-Befehle auf dem Remote-Host aus, um Dateien zu kopieren. SFTP hingegen ist ein dediziertes, paketbasiertes Protokoll, bei dem der Client einzelne Dateioperationen anfordert und der Server antwortet – ohne dass Shell-Befehle auf dem Remote-Host erstellt werden. Dieser architektonische Unterschied ist der Grund, warum SFTP das Fortsetzen von Übertragungen, interaktives Browsen und eine präzisere Protokollierung unterstützt, SCP dies jedoch nicht.

Warum war CVE-2020-15778 für SCP-Nutzer relevant?
Es zeigte sich, dass ein manipulierter Zielpfad, der Backtick-Zeichen verwendete, während einer SCP-Übertragung über das Legacy-Protokoll als Befehl auf dem Remote-Server ausgeführt werden konnte. Die Entwickler von OpenSSH verzichteten aus Kompatibilitätsgründen auf eine strenge Validierung. Dies trug mit dazu bei, dass die Branche das Standardverhalten änderte, anstatt den Fehler dauerhaft mit Patches zu umgehen.

Sollte ich jeden Workflow von SCP auf SFTP umstellen?
Für automatisierte, Compliance-relevante oder wiederholte Vorgänge ist dies ausreichend. Für eine einmalige manuelle Kopie zwischen zwei vertrauenswürdigen, gepatchten Hosts genügt SCP über das moderne, SFTP-basierte Standardprotokoll. In beiden Fällen hat die Verwaltung des SSH-Schlüssels während der Übertragung höchste Priorität, nicht die Wahl des Protokolls.

Nutzt rsync SSH auf die gleiche Weise wie SCP?
Rsync nutzt üblicherweise SSH zur Verschlüsselung und Authentifizierung, genau wie SCP und SFTP. Die Logik für Dateivergleich und -übertragung basiert jedoch auf einem eigenen, darüberliegenden Protokoll von Rsync. Dadurch bietet Rsync eine höhere Effizienz bei Delta-Übertragungen und die Möglichkeit, Übertragungen fortzusetzen – etwas, das SCP allein nicht leisten kann.

Referenzen

• OpenSSH 9.0 VersionshinweiseOpenSSH.org
• CVE-2020-15778Nationale Schwachstellendatenbank
• CVE-2026-35385-BeratungGitHub-Beratungsdatenbank
• OpenSSH SCP wird in RHEL 9 nicht mehr unterstützt, Red Hat
• OpenSSH-Handbuchseiten (scp, sftp)OpenSSH.org