Alles over Secure Copy Protocol

Secure Copy Protocol (SCP) verplaatst bestanden via een versleutelde SSH-verbinding met behulp van een syntax die de meeste programmeurs uit hun hoofd kunnen opschrijven. Die eenvoud is echter ook meteen het probleem: het onderliggende protocol van SCP stamt uit 1983 (rcp), het is geleverd met bekende kwetsbaarheden, waaronder een command-injectiefout uit 2020 en een privilege-escalatiebug uit 2026, en OpenSSH zelf gebruikt nu standaard een veiligere overdrachtsmethode achter dezelfde commandonaam.

Gepubliceerd: april 2026. Bijgewerkt: augustus 2026. Beoordeeld door het SSH- en sleutelbeheerteam van Encryption Consulting.

Wat is Secure Copy Protocol (SCP) en hoe werkt het?

SCP is een commandoregelprogramma waarmee bestanden tussen een lokale host en een externe host, of tussen twee externe hosts, via een bestaande SSH- verbinding kunnen worden gekopieerd. Het is ontstaan ​​omdat het oorspronkelijke Remote Copy Protocol (RCP), waarop het is gebaseerd, helemaal geen encryptie bevatte. SCP neemt de eenvoudige kopieersemantiek van RCP en voegt daar de authenticatie en encryptie van SSH aan toe, zodat een bestand tijdens de overdracht niet kan worden gelezen of gewijzigd door iemand die zich op hetzelfde netwerkpad bevindt.

Een SCP-overdracht kan, zodra de SSH-tunnel actief is, in twee richtingen verlopen. In de sink-modus worden bestanden van de lokale host naar de externe host gepusht; in de source-modus worden bestanden van de externe host naar de lokale host gehaald. Welke modus wordt gebruikt, hangt volledig af van de manier waarop het commando is geschreven, niet van een aparte vlag: SCP start simpelweg de bijbehorende overdracht. scp Het proces vindt aan de andere kant plaats en de bestandsgegevens worden via het SSH-kanaal verzonden.

De basisopdrachtstructuur is als volgt:

scp [opties] bron bestemming

Om een ​​lokaal bestand naar een externe host te uploaden:

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

Om datzelfde bestand terug te halen naar de huidige lokale map:

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

Die punt aan het einde is belangrijk: hij geeft SCP de opdracht om het bestand te schrijven in de map van waaruit de opdracht wordt uitgevoerd. -r Een volledige map recursief kopiëren. Voor authenticatie werkt inloggen met een wachtwoord, maar authenticatie met een SSH-sleutel is de standaard voor alles wat geautomatiseerd of herhaaldelijk gebeurt.

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

Andere vlaggen die het vermelden waard zijn: -v voor uitgebreide uitvoer wanneer een verbinding niet goed functioneert, -P om een ​​niet-standaard SSH-poort in te stellen, en -p Om de wijzigingstijden en machtigingen van het bestand op de kopie te behouden. Het vergeten van de dubbele punt in het externe pad is de meest voorkomende fout, omdat SCP zonder deze dubbele punt het hele argument als een lokaal pad in plaats van een extern pad behandelt.

SCP versus SFTP versus Rsync via SSH: hoe verhouden ze zich tot elkaar?

Alle drie de tools verplaatsen bestanden via een versleuteld SSH-kanaal, maar ze doen dat via zeer verschillende protocolontwerpen, en dat verschil is precies wat hun tekortkomingen op het gebied van beveiliging en betrouwbaarheid veroorzaakt. SFTP is zelf ontstaan ​​uit dezelfde behoefte waaraan SCP tegemoetkwam: zie onze analyse van Secure File Transfer Protocol (SFTP) en de voordelen ervan voor een nadere beschouwing van dat protocol.

Het oude scp/rcp-protocol werkt door de lokale scp client roept een externe functie aan scp proces met niet-gedocumenteerde vlaggen (-t voor de gootsteen, -f (voor de bron), waarna bestandspaden worden doorgegeven die de externe shell gedeeltelijk interpreteert, inclusief wildcard-expansie. Die betrokkenheid van de shell is de oorzaak van de bekendste tekortkomingen van SCP. SFTP vervangt dit volledig door een speciaal ontwikkeld, pakketgebaseerd verzoek-antwoordprotocol: de client vraagt ​​om afzonderlijke bewerkingen (openen, lezen, schrijven, status, hernoemen) en de server reageert, zonder dat er op enig moment shell-opdrachten worden geconstrueerd. Rsync-over-SSH kiest een derde benadering, waarbij SSH puur als beveiligd transport wordt gebruikt, terwijl het eigen protocol van rsync de daadwerkelijke vergelijking en overdracht afhandelt, inclusief delta-codering, zodat alleen de gewijzigde delen van een bestand worden verzonden.

Bekwaamheid	SCP	SFTP	Rsync via SSH
Overdrachtsmodel	Shell-gebaseerde push/pull	Verzoek-antwoord-subsysteem	Delta-synchronisatie via SSH-transport
Hervat onderbroken overdracht	Nee	Ja, gedeeltelijke bestandsondersteuning	Ja, daarvoor is hij gemaakt.
Mappensynchronisatie / incrementele kopie	Nee, altijd een volledige bestandskopie	Beperkt, per sessie	Ja, aangeboren kracht
Interactief browsen op afstand	Nee	Ja (ls, cd, rm tijdens de sessie)	Nee
Shell-opdrachtconstructie aan de externe zijde	Ja, alleen het oude protocol.	Nee	Nee (rsync-protocol, niet shell)
Standaard in OpenSSH 9.0+	scp gebruikt nu intern SFTP.	Ja	Niet van toepassing, apart gereedschap
Beste pasvorm	Snelle, geautomatiseerde eenmalige kopieën op vertrouwde, gepatchte hosts.	Algemene, veilige bestandsoverdracht, automatisering, nalevingsregistratie	Grote datasets, mirroring, herhaalde synchronisaties, onbetrouwbare links

In de praktijk zouden de meeste teams standaard SFTP moeten gebruiken voor alles wat verder gaat dan een eenmalige, ad-hockopie, en rsync moeten inzetten wanneer het werk echt draait om synchronisatie in plaats van eenmalige levering.

Wat zijn de bekende beveiligingsbeperkingen van SCP?

Het verouderde scp/rcp-protocol van SCP kent twee openbaar gemaakte, via CVE geregistreerde kwetsbaarheden waar beveiligingsteams van op de hoogte moeten zijn voordat ze het protocol standaardiseren voor nieuwe implementaties.

CVE-2020-15778 is een command-injectiekwetsbaarheid in de scp-client via OpenSSH 8.3p1 (CVSS 3.1-score: 7.4, hoog). Een bestemmingsargument dat backticks bevat, kan aan de externe kant worden geïnterpreteerd en uitgevoerd als een shellcommando, omdat het verouderde protocol bestandsnamen doorgeeft aan de externe shell in plaats van ze als pure data te behandelen. De beheerders van OpenSSH hebben verklaard dat ze opzettelijk geen validatie uitvoeren op wat zij "anomale argumentoverdrachten" noemen, omdat strengere validatie het risico met zich meebrengt dat lang bestaande scripts en workflows worden verbroken. Die houding is precies de reden waarom de kwetsbaarheid zo lang onopgelost is gebleven, zelfs toen verschillende distributies hun eigen oplossingen uitbrachten.

CVE-2026-35385 Dit is een recenter probleem met privilege-escalatie dat OpenSSH vóór versie 10.3 trof (CVSS 3.1-score: 7.5, hoog). Wanneer een bestand wordt gedownload met scp als root met behulp van het oude protocol (de -O vlag) zonder ook door te geven -p Om de bestandsmodus te behouden, kan het resulterende bestand uiteindelijk als setuid of setgid worden geïnstalleerd, een uitkomst die de meeste beheerders niet zouden verwachten of bedoelen. Dat is een reële mogelijkheid tot privilege-escalatie op elk systeem waar root routinematig bestanden via SCP downloadt. De oplossing is opgenomen in OpenSSH 10.3p1.

Beide problemen zijn terug te voeren op dezelfde oorzaak: het verouderde scp/rcp-protocol vertrouwt de externe partij meer dan een modern overdrachtsprotocol zou moeten doen, en het is nooit ontworpen met het huidige dreigingsmodel in gedachten. Dat is precies de reden waarom, vanaf OpenSSH 9.0 in 2022, de scp De opdracht is standaard overgeschakeld naar het SFTP-protocol. De uitvoering is voltooid. scp Een recente OpenSSH-build ondersteunt het kwetsbare, verouderde protocol niet meer, tenzij iemand dit expliciet afdwingt met de -O Red Hat ging in RHEL 9 nog een stap verder door het verouderde scp/rcp-protocol formeel af te schrijven en aan te geven dat het uiteindelijk verwijderd zou worden. Dit was precies omdat, zoals Red Hat het zelf verwoordde, het protocol "meerdere beveiligingsrisico's en -problemen met zich meebrengt waarvoor geen eenvoudige oplossingen bestaan", aangezien het "inherent betrouwbaar is voor geauthenticeerde sessies".

De praktische conclusie: als uw systemen een recente OpenSSH-versie gebruiken, kunt u het volgende typen: scp Tegenwoordig draait het waarschijnlijk al via SFTP. Als je het nog steeds forceert, is dat waarschijnlijk niet het geval. -O Voor compatibiliteit met oudere systemen, of bij het gebruik van niet-gepatchte OpenSSH-versies, bent u blootgesteld aan beide bovengenoemde CVE's.

Wie zou de SSH-sleutels achter SCP-overdrachten moeten bezitten?

De veiligheid van een SCP hangt af van de beveiliging van de SSH-sleutel waarmee deze wordt geverifieerd, en in tegenstelling tot een TLS-certificaat heeft een SSH-sleutel geen ingebouwde vervaldatum. Het eigenaarschap moet expliciet worden toegewezen, anders stapelen de sleutels zich simpelweg op. In de praktijk is het eigenaarschap gedurende de levenscyclus verdeeld over drie rollen:

• Beveiligings- of identiteitsteam: is verantwoordelijk voor het uitgiftebeleid, de goedgekeurde sleuteltypen en -lengtes, en de centrale inventaris van alle gebruikte sleutels, inclusief sleutels die zijn ingebed in scripts en CI/CD-pipelines.
• Eigenaren van het systeem of de applicatie: bezit de authorized_keys Ze beheren de gegevens op hun eigen servers en zijn verantwoordelijk voor het verwijderen van de toegang wanneer een gebruiker, dienst of contract eindigt.
• Platform- of DevOps-teams: Ze beheren hun eigen geautomatiseerde bestandsoverdrachtssleutels die worden gebruikt door build-pipelines, back-uptaken en integraties, en zijn verantwoordelijk voor het koppelen van elke sleutel aan de specifieke host en opdracht die deze daadwerkelijk nodig heeft.

Zonder een duidelijke verantwoordelijke voor een van deze rollen, worden SSH-sleutels standaard toegewezen aan degene die ze heeft gegenereerd. Dit is de reden waarom organisaties sleutels hebben die niemand zich herinnert te hebben verleend en die niemand wil verwijderen.

Wanneer moet je de SSH-sleutels die SCP gebruikt, vervangen?

Sleutelrotatie moet worden geactiveerd door gebeurtenissen, niet alleen door een kalender, hoewel een kalender als back-up nog steeds van belang is. De triggers die een SSH-sleutelrotatie moeten afdwingen voor elk account dat wordt gebruikt met SCP of SFTP zijn onder andere:

1. Een vaste maximale sleutelleeftijd, doorgaans 90 tot 180 dagen voor interactieve gebruikerssleutels en korter voor serviceaccounts met hoge privileges.
2. Het vertrek van een werknemer of contractant, of een functieverandering waardoor de toegang tot een bepaalde host niet langer nodig is.
3. Vermoedelijke of bevestigde inbreuk op een werkstation, buildserver of het sleutelmateriaal zelf.
4. Een openbaar gemaakte kwetsbaarheid in de gebruikte SSH-client, -server of sleutelgeneratiebibliotheek, zoals CVE-2026-35385 hierboven.
5. Bij de migratie van een systeem naar een nieuwe infrastructuur is het logisch om nieuwe sleutels uit te geven in plaats van ze te kopiëren.
6. Ontdekking, tijdens een toegangscontrole, van een sleutel die niet langer gekoppeld is aan een gedocumenteerde eigenaar of doel.

Handmatige rotatie over tientallen of honderden hosts is waar de meeste organisaties stilletjes de brui aan geven, en dat is precies het argument voor gecentraliseerd SSH-sleutelbeheer in plaats van een strenger rotatiebeleid op papier.

Welk toegangsbeleid moet gelden voor machtigingen bij bestandsoverdracht?

Toegang tot bestandsoverdracht moet volgens hetzelfde principe van minimale privileges worden gewaarborgd als elke andere toegang tot de productieomgeving, met een aantal SCP- en SFTP-specifieke extra controles:

• Wachtwoordverificatie uitschakelen voor SCP/SFTP-compatibele accounts en vereisen in plaats daarvan authenticatie op basis van sleutels of certificaten.
• Beperken op gebruiker en groep with AllowUsers or AllowGroups richtlijnen, en op basis van het bron-IP-bereik, waarbij overdrachten uitsluitend afkomstig zijn van bekende netwerken.
• Chroot en beperk SFTP-only accounts met behulp van OpenSSH's ChrootDirectory en ForceCommand internal-sftpEen account voor bestandsoverdracht kan dus nooit een interactieve shell openen.
• Het toepassingsgebied van serviceaccount-sleutels is beperkt. met een command= beperking in authorized_keys Een automatiseringssleutel kan dus precies één overdrachtsopdracht uitvoeren op één pad, en verder niets.
• Nieuwe toegang vereist goedkeuring. naar productiehosts in plaats van zelfservice voor het toevoegen van sleutels toe te staan, en toegang tot uitzonderingen te beperken tot een bepaalde tijd.

Deze beveiligingsmaatregelen zijn belangrijker dan de keuze tussen SCP en SFTP zelf. Een goed afgebakend SCP-account op een beveiligde, gepatchte host is veiliger dan een onbeperkt SFTP-account met een gedeelde sleutel en zonder logboekregistratie.

Hoe genereer je auditbewijs voor bestandsoverdrachten?

Zowel auditors als incidentbestrijders hebben hetzelfde nodig: een registratie van wie wat heeft overgedragen, waarheen of vandaan, en wanneer. Dat bewijs komt van een paar concrete controles:

• Set LogLevel VERBOSE Op SSH-servers die bestandsoverdrachten afhandelen, omvat de authenticatie de specifieke sleutelvingerafdruk die is gebruikt, en niet alleen de gebruikersnaam.
• Schakel logboekregistratie voor het SFTP-subsysteem in. Hiermee worden individuele bestandsbewerkingen (openen, lezen, schrijven, hernoemen, verwijderen) vastgelegd op een manier die het op de shell gebaseerde model van SCP niet kan evenaren.
• Stuur SSH- en SFTP-logboeken door naar een gecentraliseerde, fraudebestendige logboekopslag of SIEM, met een bewaartermijn die voldoet aan uw complianceverplichtingen (doorgaans een jaar of langer onder PCI DSS en SOC 2).
• Voer periodieke toegangscontroles uit die alles op elkaar afstemmen. authorized_keys invoer tegen een gedocumenteerde eigenaar en zakelijke rechtvaardiging.
• Koppel logboekregistratie van bestandsoverdrachten en controles op sleutelinventarisatie rechtstreeks aan de relevante controlefamilies in raamwerken zoals ISO/IEC 27001, SOC 2 en PCI DSS, zodat hetzelfde bewijsmateriaal zowel voor beveiligings- als auditdoeleinden dient.

Dit is het gebied waar SFTP structureel een voordeel heeft ten opzichte van SCP: omdat elke bewerking een afzonderlijk, geregistreerd verzoek is in plaats van een shell-commando, zijn SFTP-auditlogboeken achteraf veel gemakkelijker te reconstrueren.

Hoe ziet een workflow voor beveiligde bestandsoverdracht eruit?

Of je nu kiest voor SCP, SFTP of rsync, het implementatieproces voor een nieuwe beveiligde bestandsoverdrachtsmethode moet in dezelfde volgorde verlopen:

1. Controleer de OpenSSH-versie. op elke betrokken host, en patch naar minimaal 10.3p1 om CVE-2026-35385 te verhelpen, of naar een versie van 9.0 of hoger. scp Standaard wordt het SFTP-protocol gebruikt.
2. Kies het juiste gereedschap voor de betreffende werkzaamheden: SFTP voor algemene en geautomatiseerde overdrachten, rsync voor grote of herhaalde synchronisaties, SCP alleen voor snelle, handmatige, eenmalige kopieën op hosts die u vertrouwt en beheert.
3. Genereer scoped SSH-sleutels per systeem of service, met gebruikmaking van moderne sleuteltypen (Ed25519 heeft de voorkeur, RSA 3072-bit of hoger waar Ed25519 niet wordt ondersteund), nooit één gedeelde sleutel voor meerdere integraties.
4. Beperk de toegang tot de server. with AllowUsers/AllowGroups, chrooted SFTP waar nodig, en command= Beperkingen op automatiseringssleutels.
5. Uitgebreide logging inschakelen en het naar een centrale opslaglocatie transporteren vóór de eerste productietransfer plaatsvindt, niet na een incident.
6. Eigendom van documenten en rotatieschema voor elke aangemaakte sleutel, gekoppeld aan de bovenstaande triggers.
7. Test het faalpad.Controleer wat er gebeurt bij een onderbroken overdracht, een ingetrokken sleutel en een verkeerd geconfigureerde machtiging, voordat u op de configuratie vertrouwt in een productieomgeving.

Hoe verschilt de ondersteuning voor SCP en SFTP op verschillende platformen?

Linux, macOS en de meeste Unix-systemen worden geleverd met OpenSSH. scp en sftp Clients en servers zijn ingebouwd, waardoor de ondersteuning consistent blijft zolang de OpenSSH-versie actueel is. Windows heeft die kloof gedicht vanaf Windows 10 versie 1809 (uitgebracht in 2018), toen Microsoft de OpenSSH-client en -server rechtstreeks in het besturingssysteem integreerde, waardoor beide commando's native beschikbaar zijn vanuit PowerShell of Windows Terminal zonder tools van derden zoals PuTTY.

Enterprise Linux-distributies zijn actief begonnen gebruikers weg te leiden van het verouderde scp-protocol. RHEL 9 heeft het oude scp/rcp-protocol afgekeurd en nieuwe overdrachten standaard ingesteld op het SFTP-gedrag dat is geïntroduceerd in OpenSSH 9.0. Er wordt tevens gewaarschuwd dat het oude protocol uiteindelijk volledig zal worden verwijderd. Deze afkeuring brengt een praktisch probleem aan het licht waar rekening mee moet worden gehouden: SCP en SFTP behandelen symbolische links en paden met een tilde anders, waardoor overdrachten tussen een moderne en een oudere host die afhankelijk zijn van SFTP anders verlopen. ~ Snelkoppelingen kunnen zich onverwacht gedragen. Het gebruik van absolute paden omzeilt dit probleem.

Voor organisaties die een mix van OpenSSH-versies gebruiken op Linux-, Windows- en macOS-systemen, of voor oudere netwerkapparaten met ingebouwde SSH-stacks, is de praktische oplossing niet om het standaardgedrag van elk platform afzonderlijk aan te passen. Het is beter om de SSH-sleutels en het toegangsbeleid centraal te beheren, zodat het overdrachtsprotocol dat een bepaalde host standaard gebruikt, minder belangrijk wordt.

Hoe moet u reageren als uw inloggegevens voor bestandsoverdracht zijn gecompromitteerd?

Wanneer er een vermoeden bestaat dat een SSH-sleutel die gebruikt wordt voor SCP of SFTP is gecompromitteerd, is snelheid belangrijker dan perfectie van het proces. Een praktische reactievolgorde:

1. Onmiddellijk intrekken. Verwijder de sleutel uit elk authorized_keys het bestand waarin het voorkomt, of trek het bijbehorende SSH-certificaat in als dat is uitgegeven.
2. Beperkt laterale beweging. Controleer of dezelfde sleutel of hetzelfde sleutelmateriaal op andere hosts of services is hergebruikt en trek deze daar ook in.
3. Bewaar en controleer logboeken. Haal de SSH- en SFTP-logboeken op die de periode bestrijken waarin het datalek vermoedelijk heeft plaatsgevonden, om te achterhalen wat er daadwerkelijk is geopend of overgedragen.
4. De bijbehorende referenties roteren. Elke sleutel die is gegenereerd op hetzelfde gecompromitteerde werkstation, of elke sleutel waarvan aannemelijk is dat een aanvaller deze heeft aangeraakt, moet als verdacht worden beschouwd en worden vervangen.
5. Controleer of er toegang is tot de beplanting. Controleer de host-sleutels en authorized_keys bestanden voor items die de rechtmatige eigenaar niet heeft toegevoegd.
6. Belanghebbenden op de hoogte stellen conform uw incidentrespons en, waar van toepassing, de wettelijke openbaarmakingsvereisten.
7. Voer een evaluatie na het incident uit. Om te achterhalen hoe de sleutel is blootgesteld en dat specifieke lek te dichten, of het nu gaat om een ​​onversleutelde sleutel op de schijf, een te ruime toegangsmachtiging of een ontbrekend rotatiebeleid.

Organisaties die binnen enkele minuten na een melding kunnen antwoorden op de vragen "welke sleutel, welke hosts, sinds wanneer" zijn de organisaties die al vóór het incident een gedegen inventaris van SSH-sleutels hadden, en niet de organisaties die deze inventaris tijdens het incident aan het samenstellen zijn.

Beperkingen

Naast de hierboven genoemde beveiligingsproblemen kent SCP functionele beperkingen waardoor het minder geschikt is voor alles behalve snelle, handmatige overdrachten. Het kan een onderbroken overdracht niet hervatten: als een kopie halverwege mislukt, bijvoorbeeld door een verbroken verbinding of een netwerkstoring, begint de hele overdracht opnieuw. Het kent geen concept van incrementele synchronisatie, dus het wijzigen van één regel in een groot bestand betekent nog steeds dat het hele bestand opnieuw gekopieerd moet worden. En omdat het de delta-transfer-optimalisaties mist waar tools zoals rsync op gebouwd zijn, is SCP meer resource- en bandbreedte-intensief voor herhaalde of grootschalige overdrachten. Deze tekortkomingen, in combinatie met de hierboven genoemde beveiligingsbeperkingen, zijn precies de reden waarom SCP het best gebruikt kan worden voor incidentele, eenmalige kopieën in plaats van voor grootschalige bestandsoverdrachtprocessen.

Wat zou Encryption Consulting aanbevelen?

Voor nieuwe implementaties zouden we teams adviseren om SFTP via SCP te gebruiken, en rsync via SSH voor alles wat grote of herhaalde synchronisaties betreft. Maar de protocolkeuze is zelden waar het werkelijke risico schuilt. In bijna elke SCP- of SFTP-omgeving die we beoordelen, is het werkelijke risico gelegen in onbeheerde SSH-sleutels: sleutels zonder gedocumenteerde eigenaar, zonder rotatieschema en zonder auditspoor dat een overdracht koppelt aan een persoon of een dienst.

Dat is precies de lacune die SSH Secure wil dichten. Het biedt een gecentraliseerd overzicht van elke SSH-sleutel in uw omgeving, geautomatiseerde rotatie gekoppeld aan de hierboven beschreven triggers en beleidshandhaving zodat sleutels voor bestandsoverdracht beperkt blijven tot de specifieke host en opdracht die ze nodig hebben. Voor teams die ook TLS- of codeondertekeningscertificaten uitgeven en beheren, zorgt de combinatie met CertSecure Manager ervoor dat het overzicht van de levenscyclus van certificaten en sleutels op één plek blijft, in plaats van verspreid over verschillende tools. En wanneer privésleutels in een beveiligde, FIPS 140-3 gevalideerde omgeving moeten worden bewaard in plaats van op schijf, elimineert HSM-as-a-Service dat risico volledig.

Als u niet zeker weet hoe uw organisatie er momenteel voor staat, kan ons team van Encryption Advisory Services een gerichte beoordeling uitvoeren van uw SSH-sleutelinventaris en toegangscontroles voor bestandsoverdracht. We zullen u vervolgens een plan voor verbetering met prioriteit aanbieden, in plaats van alleen een lijst met bevindingen.

Conclusie

SCP is nog steeds nuttig voor snelle, handmatige, eenmalige kopieën tussen twee vertrouwde hosts. Maar voor alles wat geautomatiseerd, herhaaldelijk of onderworpen aan compliance-controles moet gebeuren, is SFTP de beter ontworpen keuze, en het is al de standaard voor moderne systemen. scp De opdracht wordt standaard uitgevoerd. Rsync-over-SSH neemt het vervolgens over wanneer het gaat om het synchroniseren van grote of vaak veranderende datasets in plaats van het leveren van één enkel bestand.

Dat alles doet er echter niet veel toe als de SSH-sleutels achter de overdracht geen eigenaar hebben, geen rotatieschema en geen auditspoor. Het protocol correct implementeren is een middagje werk. Het goed beheren van de levenscyclus van SSH-sleutels is echter het onderdeel dat bestandsoverdrachten daadwerkelijk veilig houdt, en dat is waar de meeste organisaties nog steeds grote tekortkomingen hebben.

Veelgestelde Vragen / FAQ

Is SCP in 2026 nog steeds veilig te gebruiken?
Op een recente, gepatchte OpenSSH-build, het volgende uitvoeren: scp is redelijk veilig omdat het nu standaard het SFTP-protocol gebruikt, in plaats van het kwetsbare, verouderde scp/rcp-protocol. Het risico keert terug als je het forceert. -O vlag voor compatibiliteit, of als de host een niet-gepatchte OpenSSH-versie gebruikt die getroffen is door CVE-2020-15778 of CVE-2026-35385.

Wat is nu precies het verschil tussen SCP en SFTP?
Het traditionele SCP-protocol bouwt en voert shell-opdrachten uit op de externe host om bestanden te kopiëren. SFTP is een specifiek, pakketgebaseerd protocol waarbij de client afzonderlijke bestandsbewerkingen aanvraagt ​​en de server daarop reageert, zonder dat er op afstand shell-opdrachten worden geconstrueerd. Dit architectonische verschil verklaart waarom SFTP het hervatten van overdrachten, interactief browsen en nauwkeurigere logboekregistratie ondersteunt, terwijl SCP dit niet doet.

Waarom was CVE-2020-15778 belangrijk voor SCP-gebruikers?
Het toonde aan dat een kwaadwillig opgestelde bestemmingspad, met behulp van backticks, tijdens een SCP-overdracht via een verouderd protocol als commando op de externe server kon worden uitgevoerd. De beheerders van OpenSSH kozen ervoor om geen strikte validatie toe te voegen, vanwege compatibiliteitsproblemen. Dit is mede de reden waarom de industrie het standaardgedrag heeft aangepast in plaats van de kwetsbaarheid permanent te blijven omzeilen met patches.

Moet ik alle workflows van SCP naar SFTP overzetten?
Voor geautomatiseerde processen, processen die aan compliance-eisen voldoen of processen die herhaaldelijk worden uitgevoerd, is het antwoord ja. Voor een eenmalige handmatige kopie tussen twee vertrouwde, gepatchte hosts is SCP via de moderne, op SFTP gebaseerde standaard prima. In beide gevallen is het beheren van de SSH-sleutel achter de overdracht belangrijker dan het kiezen van het protocol.

Gebruikt rsync SSH op dezelfde manier als SCP?
Rsync maakt doorgaans gebruik van een SSH-protocol voor encryptie en authenticatie, net als SCP en SFTP, maar de logica voor bestandsvergelijking en -overdracht is gebaseerd op een eigen protocol van rsync. Dat is wat rsync de efficiëntie van delta-transfers en de mogelijkheid tot hervatten biedt, eigenschappen die standaard SCP niet heeft.

Referenties

• Release-opmerkingen voor OpenSSH 9.0OpenSSH.org
• CVE-2020-15778Nationale kwetsbaarheidsdatabase
• CVE-2026-35385 AdviesGitHub-adviesdatabase
• OpenSSH SCP wordt afgeschaft in RHEL 9., Rode Hoed
• OpenSSH-handleidingen (scp, sftp)OpenSSH.org