Allt om säker kopieringsprotokoll

Secure Copy Protocol (SCP) flyttar filer över en krypterad SSH-anslutning med hjälp av en syntax som de flesta ingenjörer kan skriva från minnet. Den enkelheten är också problemet: SCP:s underliggande protokoll går tillbaka till 1983 års rcp, det har levererats med avslöjade sårbarheter inklusive en kommandoinjektionsfel från 2020 och en bugg för privilegieeskalering från 2026, och OpenSSH självt använder nu en säkrare överföringsmetod bakom samma kommandonamn.

Publicerad: april 2026. Uppdaterad: augusti 2026. Granskad av Encryption Consultings SSH- och nyckelhanteringsteam.

Vad är Secure Copy Protocol (SCP) och hur fungerar det?

SCP är ett kommandoradsverktyg som kopierar filer mellan en lokal värd och en fjärrvärd, eller mellan två fjärrvärdar, över en befintlig SSH- anslutning. Det existerar eftersom det ursprungliga Remote Copy Protocol (RCP) som det bygger på inte hade någon kryptering alls. SCP använder RCP:s enkla kopieringssemantik och lägger SSH:s autentisering och kryptering ovanpå, så att en fil som är under överföring inte kan läsas eller ändras av någon som sitter på nätverksvägen.

Under huven körs en SCP-överföring i två möjliga riktningar när SSH-tunneln är uppe. Sink-läget skickar filer från den lokala värden till fjärrvärden; källläget hämtar filer från fjärrvärden till den lokala värden. Vilket läge som körs beror helt på hur kommandot är skrivet, inte på någon separat flagga: SCP startar bara motsvarande scp processen i fjärränden och strömmar fildata via SSH-kanalen.

Den grundläggande kommandostrukturen är:

scp [alternativ] källdestination

Så här skickar du en lokal fil till en fjärrvärd:

scp file.txt användare@fjärrvärd:/hem/användare/

För att hämta samma fil tillbaka till den aktuella lokala katalogen:

scp användare@fjärrvärd:/hem/användare/fil.txt .

Den efterföljande punkten spelar roll: den anger att SCP ska skriva filen till den katalog som kommandot körs från. -r för att kopiera en hel katalog rekursivt. För autentisering fungerar lösenordsinloggning, men SSH-nyckelautentisering är standarden för allt som automatiseras eller upprepas:

scp -i ~/.ssh/id_rsa file.txt användare@fjärrvärd:/home/användare/

Andra flaggor värda att känna till: -v för utförlig utmatning när en anslutning inte fungerar som den ska, -P att ställa in en icke-standard SSH-port, och -p för att bevara filändringstider och behörigheter på kopian. Att glömma kolon i fjärrsökvägen är det vanligaste misstaget, eftersom SCP utan det behandlar hela argumentet som en lokal sökväg istället för en fjärrsökväg.

SCP vs. SFTP vs. Rsync över SSH: Hur står de sig i jämförelse?

Alla tre verktygen flyttar filer över en krypterad SSH-kanal, men de når dit genom väldigt olika protokolldesigner, och den skillnaden är precis det som driver deras säkerhets- och tillförlitlighetsluckor. SFTP i sig växte fram ur samma behov som SCP tog itu med: se vår genomgång av Secure File Transfer Protocol (SFTP) och dess fördelar för en närmare titt på det protokollet i sig.

Det äldre scp/rcp-protokollet fungerar genom att ha den lokala scp klienten anropar en fjärrkontroll scp process med odokumenterade flaggor (-t för handfat, -f för källkod), och skickar sedan filsökvägar som det fjärrstyrda skalet delvis tolkar, inklusive jokerteckensexpansion. Denna skalinblandning är roten till SCP:s värsta kända brister. SFTP ersätter detta helt med ett specialbyggt, paketbaserat förfrågnings-svarsprotokoll: klienten ber om diskreta operationer (öppna, läsa, skriva, stat, byta namn) och servern svarar, utan att någon skalkommandokonstruktion är inblandad någon gång. Rsync-over-SSH har en tredje metod och använder SSH enbart som en säker transport medan rsyncs eget protokoll hanterar den faktiska jämförelsen och överföringen, inklusive deltakodning så att endast de ändrade delarna av en fil flyttas över kabeln.

Capability	SCP	SFTP	Rsync över SSH
Överföringsmodell	Skalbaserad push/pull	Delsystemet för begäran och svar	Delta-synkronisering över SSH-transport
Återuppta avbruten överföring	Nej	Ja, stöd för delvis filhantering	Ja, byggd för det
Katalogsynkronisering / stegvis kopiering	Nej, alltid fullständig filkopia	Begränsat, per session	Ja, inhemsk styrka
Interaktiv fjärrsurfning	Nej	Ja (ls, cd, rm i session)	Nej
Shell-kommandokonstruktion på fjärrsidan	Ja, endast äldre protokoll	Nej	Nej (rsync-protokoll, inte shell)
Standard i OpenSSH 9.0+	scp använder nu SFTP internt	Ja	Ej tillämpligt, separat verktyg
Bästa passform	Snabba, skriptade engångskopior på betrodda, patchade värdar	Allmän säker filöverföring, automatisering, efterlevnadsloggning	Stora datamängder, spegling, upprepade synkroniseringar, opålitliga länkar

I praktiken bör de flesta team använda SFTP som standard för allt utöver en enda ad hoc-kopia, och använda rsync när arbetsbelastningen egentligen handlar om synkronisering snarare än engångsleverans.

Vilka är SCP:s kända säkerhetsbegränsningar?

SCP:s äldre scp/rcp-protokoll har två avslöjade, CVE-spårade sårbarheter som säkerhetsteam bör känna till innan de standardiserar det för nya implementeringar.

CVE-2020-15778 är en sårbarhet för kommandoinjektion i scp-klienten via OpenSSH 8.3p1 (CVSS 3.1-poäng: 7.4, hög). Ett destinationsargument som innehåller backtick-tecken kan tolkas och exekveras som ett shell-kommando på fjärrsidan, eftersom det äldre protokollet skickar filnamn genom fjärrskalet snarare än att behandla dem som rena data. OpenSSHs ansvariga har uppgett att de avsiktligt inte validerar vad de kallar "avvikande argumentöverföringar", med motiveringen att striktare validering riskerade att förstöra långvariga skript och arbetsflöden. Den ståndpunkten är exakt anledningen till att felet fick stå utan en fullständig uppströmsfix så länge, även om flera nedströmsdistributioner levererade sina egna åtgärder.

CVE-2026-35385 är ett nyare problem med eskalering av privilegier som påverkar OpenSSH före version 10.3 (CVSS 3.1-poäng: 7.5, hög). När en fil laddas ner med scp som root med det äldre protokollet (den -O flagga) utan att också passera -p För att bevara filläget kan den resulterande filen installeras som setuid eller setgid, ett resultat som de flesta administratörer inte förväntar sig eller avser. Det är en verklig väg för privilegier som eskaleras på alla system där root rutinmässigt hämtar filer över SCP. Fixen levererades i OpenSSH 10.3p1.

Båda problemen kan spåras tillbaka till samma grundorsak: det äldre scp/rcp-protokollet litar mer på fjärrsidan än ett modernt överföringsprotokoll borde, och det utformades aldrig med dagens hotmodell i åtanke. Det är just därför, med början i OpenSSH 9.0 år 2022, scp kommandot bytte till att använda SFTP-protokollet som standard. Körs scp på en aktuell OpenSSH-version talar inte längre det sårbara äldre protokollet om inte någon uttryckligen tvingar fram det med -O flagga. Red Hat gick längre i RHEL 9, genom att formellt avskriva den äldre scp/rcp-protokollsökvägen och flagga den för eventuell borttagning, just för att, som Red Hat uttryckte det, protokollet "medför flera säkerhetsrisker och problem som inte har några enkla lösningar" eftersom det "i sig är tillförlitligt för autentiserade sessioner".

Den praktiska slutsatsen: om dina system använder en aktuell OpenSSH-version, skriv scp idag körs troligen redan över SFTP. Om du fortfarande tvingar fram -O för kompatibilitet med äldre system, eller för att köra opatchade OpenSSH-versioner, exponeras du för båda CVE:erna ovan.

Vem borde äga SSH-nycklarna bakom SCP-överföringar?

SCP är bara så säker som SSH-nyckeln som autentiserar den, och till skillnad från ett TLS-certifikat har en SSH-nyckel inget inbyggt utgångsdatum. Äganderätten måste tilldelas explicit, annars ackumuleras nycklarna helt enkelt. I praktiken delas livscykelägandet upp i tre roller:

• Säkerhets- eller identitetsteam: äger utgivningspolicyn, de godkända nyckeltyperna och längderna, samt den centrala inventeringen av varje nyckel som används, inklusive nycklar inbäddade i skript och CI/CD-pipelines.
• System- eller applikationsägare: äga authorized_keys poster på sina egna värdar och är ansvariga för att ta bort åtkomst när en användare, tjänst eller ett kontrakt upphör.
• Plattforms- eller DevOps-team: egna automatiserade filöverföringsnycklar som används av byggpipelines, säkerhetskopieringsjobb och integrationer, och ansvarar för att tilldela varje nyckel till den enskilda värd och det kommando den faktiskt behöver.

Utan en av dessa roller tydligt kopplade till SSH-nycklarna som standard den som genererade dem, vilket är så organisationer får nycklar som ingen minns att de beviljat och som ingen är villig att radera.

När ska du rotera SSH-nycklarna som SCP förlitar sig på?

Rotation bör utlösas av händelser, inte bara en kalender, även om en kalender-backstop fortfarande spelar roll. Utlösare som bör tvinga fram en SSH-nyckelrotation för alla konton som används med SCP eller SFTP inkluderar:

1. En fast maximal nyckelålder, vanligtvis 90 till 180 dagar för interaktiva användarnycklar och kortare för tjänstkonton med hög behörighet.
2. En anställds eller entreprenörs offboarding, eller en rollbyte som tar bort behovet av en given värds åtkomst.
3. Misstänkt eller bekräftad intrång i en arbetsstation, byggserver eller själva nyckelmaterialet.
4. En avslöjad sårbarhet i SSH-klienten, servern eller nyckelgenereringsbiblioteket som används, till exempel CVE-2026-35385 ovan.
5. Migrering av ett system till ny infrastruktur, vilket är en naturlig tidpunkt att utfärda nycklar på nytt snarare än att kopiera dem framåt.
6. Upptäckt, under en åtkomstgranskning, av en nyckel som inte längre är kopplad till en dokumenterad ägare eller ett dokumenterat syfte.

Manuell rotation mellan dussintals eller hundratals värdar är där de flesta organisationer tyst ger upp, vilket är det verkliga argumentet för centraliserad SSH-nyckelhantering snarare än en starkare rotationspolicy på pappret.

Vilken åtkomstpolicy bör styra behörigheter för filöverföring?

Filöverföringsåtkomst bör följa samma disciplin för lägsta privilegier som all annan produktionsåtkomst, med några SCP- och SFTP-specifika kontroller på lager:

• Inaktivera lösenordsautentisering för SCP/SFTP-kompatibla konton och kräver istället nyckel- eller certifikatbaserad autentisering.
• Begränsa efter användare och grupp med AllowUsers or AllowGroups direktiv och efter käll-IP-intervall där överföringar endast kommer från kända nätverk.
• Chroot och begränsa endast SFTP-konton med hjälp av OpenSSH ChrootDirectory och ForceCommand internal-sftp, så ett filöverföringskonto kan aldrig öppna ett interaktivt skal.
• Omfånga servicekontonycklar snävt med en command= begränsning i authorized_keys så en automatiseringsnyckel kan köra exakt ett överföringskommando mot en sökväg, inget annat.
• Kräv godkännande för ny åtkomst till produktionsvärdar istället för att tillåta självbetjänande nycklar och tidsbunden åtkomst till eventuella undantag.

Dessa kontroller är viktigare än valet av SCP kontra SFTP i sig. Ett väldefinierat SCP-konto på en härdad, patchad värd är säkrare än ett obegränsat SFTP-konto med en delad nyckel och ingen loggning.

Hur tar man fram revisionsbevis för filöverföringar?

Revisorer och incidentberedskapspersonal behöver båda samma sak: en förteckning över vem som överförde vad, till eller från var och när. Dessa bevis kommer från några konkreta kontroller:

• uppsättning LogLevel VERBOSE på SSH-servrar som hanterar filöverföringar så att autentiseringshändelser inkluderar det specifika nyckelfingeravtrycket som används, inte bara användarnamnet.
• Aktivera SFTP-undersystemsloggning, som registrerar enskilda filåtgärder (öppna, läsa, skriva, byta namn, ta bort) på ett sätt som SCP:s skalbaserade modell inte kan matcha.
• Vidarebefordra SSH- och SFTP-loggar till en centraliserad, manipulationssäker loggförvaring eller SIEM, med lagring som uppfyller dina efterlevnadsskyldigheter (vanligtvis ett år eller längre enligt PCI DSS och SOC 2).
• Kör regelbundna åtkomstgranskningar som avstämmer alla authorized_keys införsel mot en dokumenterad ägare och affärsmässig motivering.
• Mappa filöverföringsloggning och viktiga lagerkontroller direkt till relevanta kontrollfamiljer i ramverk som ISO/IEC 27001, SOC 2 och PCI DSS, så att samma bevis tjänar både säkerhets- och revisionsändamål.

Det är här SFTP har en strukturell fördel jämfört med SCP: eftersom varje operation är en diskret, loggad begäran snarare än ett skalkommando, är SFTP-granskningsspår mycket enklare att rekonstruera i efterhand.

Hur ser ett arbetsflöde för säker filöverföringsdistribution ut?

Oavsett om du landar på SCP, SFTP eller rsync, bör utrullningsprocessen för en ny säker filöverföringssökväg följa samma sekvens:

1. Bekräfta OpenSSH-versionen på varje inblandad värd, och patcha till minst 10.3p1 för att stänga CVE-2026-35385, eller till en version på eller senare än 9.0 så scp använder SFTP-protokollet som standard.
2. Välj rätt verktyg för arbetsbelastningen: SFTP för allmänna och automatiserade överföringar, rsync för stora eller upprepade synkroniseringar, endast SCP för snabba, manuella, engångskopior på värdar du litar på och kontrollerar.
3. Generera scoped SSH-nycklar per system eller tjänst, med moderna nyckeltyper (Ed25519 föredras, RSA 3072-bitars eller större där Ed25519 inte stöds), aldrig en enda delad nyckel över flera integrationer.
4. Begränsa åtkomst på serversidan med AllowUsers/AllowGroups, chrootad SFTP där så är lämpligt, och command= begränsningar för automatiseringsnycklar.
5. Aktivera utförlig loggning och dirigera den till centraliserad lagring innan den första produktionsöverföringen körs, inte efter en incident.
6. Dokumentägarskap och rotationsschema för varje skapad nyckel, kopplad till triggarna ovan.
7. Testa felvägenBekräfta vad som händer vid en avbruten överföring, en återkallad nyckel och en felkonfigurerad behörighet innan du förlitar dig på inställningarna i produktion.

Hur skiljer sig SCP- och SFTP-stödet åt mellan plattformar?

Linux, macOS och de flesta Unix-system levereras med OpenSSH scp och sftp klienter och servrar inbyggda, så stödet är konsekvent så länge OpenSSH-versionen är aktuell. Windows täppte till det gapet från och med Windows 10 version 1809 (släppt 2018), då Microsoft integrerade OpenSSH-klienten och -servern direkt i operativsystemet, vilket gjorde båda kommandona tillgängliga direkt från PowerShell eller Windows Terminal utan tredjepartsverktyg som PuTTY.

Enterprise Linux-distributioner har börjat aktivt styra användare bort från det äldre scp-protokollet. RHEL 9 avskaffade den äldre scp/rcp-protokollsökvägen, vilket som standard satte nya överföringar till det SFTP-baserade beteendet som introducerades i OpenSSH 9.0 och varnade för att den äldre sökvägen så småningom kommer att tas bort helt. Denna avskrivning väcker en praktisk nackdel som är värd att planera för: SCP och SFTP hanterar symlänkar och tilde-expanderade sökvägar på olika sätt, så överföringar mellan en modern värd och en äldre värd som förlitar sig på ~ Genvägar kan bete sig oväntat. Att använda absoluta sökvägar kringgår problemet.

För organisationer som kör en blandning av OpenSSH-versioner över Linux-, Windows- och macOS-system, eller äldre nätverksenheter med äldre inbäddade SSH-stackar, är den praktiska lösningen inte att jaga varje plattforms standardbeteende individuellt. Det handlar om att hantera SSH-nycklarna och åtkomstpolicyn centralt, så att vilket överföringsprotokoll en given värd råkar använda som standard spelar mindre roll.

Hur ska du reagera på en komprometterad filöverföringsautentiseringsuppgifter?

När en SSH-nyckel som används för SCP eller SFTP misstänks vara komprometterad, är hastighet viktigare än process perfektion. En praktisk svarssekvens:

1. Återkalla omedelbart. Ta bort nyckeln från varje authorized_keys filen den visas i, eller återkalla motsvarande SSH-certifikat om ett sådant har utfärdats.
2. Innehålla sidorörelser. Kontrollera om samma nyckel eller nyckelmaterial har återanvändts på andra värdar eller tjänster, och återkalla även där.
3. Bevara och granska loggar. Hämta SSH- och SFTP-loggar som täcker det misstänkta exponeringsfönstret för att identifiera vad som faktiskt åtkoms eller överfördes.
4. Rotera relaterade inloggningsuppgifter. Alla nycklar som genereras på samma komprometterade arbetsstation, eller alla nycklar som en angripare troligtvis skulle ha rört, bör behandlas som misstänkta och roteras.
5. Kontrollera för planterad åtkomst. Granska värdnycklar och authorized_keys filer för poster som den legitima ägaren inte har lagt till.
6. Meddela intressenter enligt din incidentrespons och, i tillämpliga fall, myndighetskrav på offentliggörande.
7. Kör en granskning efter incidenten för att identifiera hur nyckeln exponerades och täcka det specifika gapet, oavsett om det är en okrypterad nyckel på disk, en alltför bred åtkomstbehörighet eller en saknad rotationspolicy.

Organisationer som kan svara på "vilken nyckel, vilka värdar, sedan när" inom några minuter efter en rapport är de som har en riktig SSH-nycklarinventering på plats innan incidenten inträffar, inte de som sätter ihop en under tiden.

Begränsningar

Utöver de säkerhetsproblem som nämns ovan har SCP funktionella begränsningar som gör det dåligt lämpat för allt utöver snabba, manuella överföringar. Det kan inte återuppta en avbruten överföring: om en kopia misslyckas halvvägs, på grund av en bruten anslutning eller ett nätverksavbrott, börjar hela överföringen om från början. Det har inget koncept med stegvis synkronisering, så att ändra en rad i en stor fil innebär fortfarande att kopiera hela filen igen. Och eftersom det saknar de delta-överföringsoptimeringar som verktyg som rsync är byggda kring, är SCP mer resurs- och bandbreddsintensivt för upprepade eller storskaliga överföringar. Dessa luckor, i kombination med säkerhetsbegränsningarna ovan, är just därför SCP är bäst reserverat för tillfälliga, engångskopior snarare än produktionsbaserade filöverföringspipelines.

Vad skulle krypteringskonsulter rekommendera?

För nya driftsättningar skulle vi hänvisa team till SFTP över SCP, och till rsync-över-SSH för allt som involverar stor eller upprepad synkronisering. Men protokollvalet är sällan där den verkliga risken ligger. I nästan varje SCP- eller SFTP-miljö vi utvärderar är den faktiska exponeringen ohanterade SSH-nycklar: nycklar utan dokumenterad ägare, inget rotationsschema och ingen revisionslogg som knyter en överföring tillbaka till en person eller en tjänst.

Det är den klyftan som SSH Secure är byggd för att täcka. Den ger dig en centraliserad inventering av varje SSH-nyckel i din miljö, automatiserad rotation kopplad till de triggers som beskrivs ovan, och policytillämpning så att filöverföringsnycklar förblir begränsade till den enda värd och det kommando de behöver. För team som också utfärdar och hanterar TLS- eller kodsigneringscertifikat, håller kombinationen av det med CertSecure Manager certifikat- och nyckellivscykelsynlighet på ett ställe istället för att delas upp över verktyg. Och där privata nycklar behöver finnas i en härdad, FIPS 140-3-validerad miljö snarare än på disk, eliminerar HSM-as-a-Service den risken helt.

Om du är osäker på var din organisation står idag kan vårt team för krypteringsrådgivning göra en fokuserad bedömning av ditt SSH-nycklarinventarium och åtkomstkontroller för filöverföringar och ge dig en prioriterad åtgärdsplan, inte bara en lista med resultat.

Slutsats

SCP har fortfarande plats för en snabb, manuell, engångskopia mellan två betrodda värdar. Men för allt som är automatiserat, upprepat eller föremål för efterlevnadsgranskning är SFTP det bättre konstruerade valet, och det är redan vad en modern scp Kommandot körs som standard. Rsync-over-SSH tar över därifrån när jobbet egentligen handlar om att synkronisera stora eller ofta föränderliga datamängder snarare än att leverera en enda fil.

Inget av det spelar dock någon större roll om SSH-nycklarna bakom överföringen inte har någon ägare, inget rotationsschema och ingen revisionslogg. Att få protokollet rätt är en eftermiddags uppgift. Att få SSH-nycklarnas livscykelhantering rätt är den del som faktiskt håller filöverföringar säkra över tid, och det är där de flesta organisationer fortfarande har verkliga luckor att täppa till.

Vanliga frågor om partihandel med mat och dryck

Är SCP fortfarande säkert att använda år 2026?
På en aktuell, patchad OpenSSH-version, som körs scp är rimligt säkert eftersom det nu använder SFTP-protokollet som standard, inte det sårbara äldre scp/rcp-protokollet. Risken återkommer om du tvingar fram -O flagga för kompatibilitet, eller om värden kör en opatchad OpenSSH-version som påverkas av CVE-2020-15778 eller CVE-2026-35385.

Vad är den faktiska skillnaden mellan SCP och SFTP?
SCP:s äldre protokoll bygger och kör shell-kommandon på fjärrdatorn för att kopiera filer. SFTP är ett dedikerat, paketbaserat protokoll där klienten begär diskreta filoperationer och servern svarar, utan att någon konstruktion av fjärrshell-kommandon är inblandad. Den arkitektoniska skillnaden är anledningen till att SFTP stöder återupptagande av överföringar, interaktiv surfning och mer exakt loggning, medan SCP inte gör det.

Varför var CVE-2020-15778 viktigt för SCP-användare?
Den visade att en skadligt skapad destinationssökväg, med hjälp av backtick-tecken, kunde köras som ett kommando på fjärrservern under en SCP-överföring med äldre protokoll. OpenSSHs utvecklare valde att inte lägga till strikt validering, med hänvisning till kompatibilitetsproblem, vilket är en del av anledningen till att branschen ändrade standardbeteendet istället för att åtgärda felet på obestämd tid.

Bör jag byta alla arbetsflöden från SCP till SFTP?
För allt som är automatiserat, relevant för efterlevnad eller upprepat, ja. För en verkligt enstaka manuell kopia mellan två betrodda, patchade värdar fungerar SCP som körs över den moderna SFTP-baserade standarden. Den största prioriteringen i båda fallen är att hantera SSH-nyckeln bakom överföringen, inte bara att välja protokoll.

Använder rsync SSH på samma sätt som SCP gör?
Rsync körs vanligtvis över en SSH-transport för kryptering och autentisering, på samma sätt som SCP och SFTP gör, men filjämförelsen och överföringslogiken är rsyncs eget protokoll som läggs ovanpå. Det är det som ger rsync delta-överföringseffektivitet och återupptagningsstöd som vanlig SCP inte kan erbjuda.

Referensprojekt

• Versionsinformation för OpenSSH 9.0, OpenSSH.org
• CVE-2020-15778, Nationell sårbarhetsdatabas
• CVE-2026-35385 Rådgivande, GitHub-rådgivningsdatabas
• OpenSSH SCP-utfasning i RHEL 9, Röd hatt
• OpenSSH-manualsidor (scp, sftp), OpenSSH.org