OpenSSH 10 ændrer kryptografien: Derfor skal ældre SFTP-integrationer have en oprydningsplan

Af Greg Nowak. Senest opdateret 2026-06-24.

Pr. 24. juni 2026 er den aktuelle OpenSSH 10.x-version 10.3, og det kompatibilitetsarbejde, der begyndte med 10.0, er ikke længere teoretisk. Hvis din virksomhed stadig er afhængig af gamle SFTP-dropbokse, natlige filoverførsler, leverandørers indsamlingsscripts eller kunders automatiseringer, som drives af et bureau, er risikoen ikke kun, at SSH kan fejle. Den større risiko er, at ingen ejer detaljerne, før en fil mangler i forbindelse med lønkørsel, rapportering, ordrebehandling eller en kundeoverdragelse.

Hvad er ændret i OpenSSH 10?

OpenSSH 10.0 fjernede understøttelsen af DSA-signaturalgoritmen. Det er vigtigt, fordi en server eller klient, der stadig er afhængig af DSA, ikke blot bruger en umoderne nøgle. Den er afhængig af nøglemateriale, som OpenSSH nu har udfaset efter flere års deprecation. For en virksomhedsejer er det praktiske svar enkelt: DSA-nøgler skal udskiftes, ikke omgås.

OpenSSH 10.1 tilføjede en klientadvarsel, når en forbindelse forhandler sig frem til en nøgleudveksling, der ikke er post-kvantesikker. Overførslen kan stadig lykkes, men advarslen er et nyttigt tidligt signal. OpenSSH beskriver problemet som risikoen for, at krypterede sessioner opsamles i dag og dekrypteres senere, hvis fremtidige kvantecomputere kan bryde nøgleaftalen. Den relevante løsning ligger som regel på serversiden: Understøt moderne hybride nøgleudvekslinger som mlkem768x25519-sha256 eller sntrup761x25519-sha512, og kontrollér, at en lokal politik ikke har deaktiveret dem.

OpenSSH 10.0 indsnævrede også standardindstillingerne på serversiden ved at fjerne den ældre finite-field Diffie-Hellman-gruppe og group-exchange-metoderne fra serverens standardliste over KexAlgorithms. OpenSSH 10.3 giver endnu en påmindelse om skrøbelige integrationer ved at fjerne bug-kompatibilitet for implementeringer, der ikke understøtter rekeying. Sagt uden omsvøb: Gamle overførselsveje kan bryde af flere kryptografiske årsager, og versionsnumrene alene fortæller ikke, hvad der rent faktisk kan forhandles.

Signal	Sandsynlig årsag	Første forretningsmæssigt forsvarlige handling
DSA-nøglen fejler efter en OpenSSH-opdatering	Integrationen er stadig afhængig af udfaset DSA-nøglemateriale	Udskift nøglen, og test det konkrete batchjob fra ende til anden
Der vises en advarsel om manglende post-kvantesikkerhed	Serveren tilbyder ikke en understøttet hybrid nøgleudveksling	Opgrader eller omkonfigurer serveren, før advarslerne undertrykkes
Nøgleudvekslingen matcher ikke	Klienten og serveren har ikke længere fælles acceptable KEX-algoritmer	Undersøg begge sider, og undgå ældre fallback-indstillinger på tværs af hele miljøet
Manuel login virker, men automatiseringen fejler	Jobbet bruger en anden identitet, konfigurationssti eller agenttilstand	Fastlås den tilsigtede identitet, og test med indstillingerne for batch mode

En praktisk triagematrix til oprydning i SFTP-integrationer i forbindelse med OpenSSH 10.

Begynd med en kortlægning, ikke med undtagelser

Det forkerte første skridt er at indsætte ældre algoritmer i en global SSH-konfiguration og håbe, at advarslerne forsvinder. Begynd med et register over endpoints: host, port, ansvarlig, leverandørkontakt, forretningsproces, tidsplan, klientversion, serverversion, hvis den er kendt, autentifikationsnøgle, host key, den forhandlede nøgleudveksling, og om jobbet er interaktivt, et batchjob eller indlejret i et andet værktøj.

OpenSSH giver dig nyttige kommandoer til at undersøge miljøet, før du ændrer politikken:

ssh -Q kex
ssh -Q HostKeyAlgorithms
ssh -Q PubkeyAcceptedAlgorithms

Kommandoerne viser, hvad den installerede klient understøtter. Test derefter jobbets faktiske kørselsvej – ikke en bekvem manuel genvej. Hvis produktionsjobbet bruger SFTP, batch mode, en navngiven nøgle og et cron-miljø, skal du teste netop denne konfiguration direkte:

sftp -vvv -oBatchMode=yes partner-legacy-sftp

Målet er at afdække den adfærd, der faktisk bliver forhandlet, ikke at bevise, at en eller anden SSH-forbindelse kan oprettes fra en udviklers laptop.

Udskift svage nøgler ordentligt

Planlæg en kontrolleret udskiftning af nøgler alle de steder, hvor DSA optræder. Ed25519 er et godt standardvalg, når partnersystemet understøtter det, mens RSA med SHA-2-signaturer kan være nødvendigt til visse ældre kommercielle appliances. Det vigtige er ikke kun nøgletypen, men også udrulningen: Opret den nye nøgle, installér den offentlige nøgle hos partneren, test parallelt, hvis det er muligt, opdater automatiseringen, og fjern den gamle nøgle fra den autoriserede adgang.

ssh-keygen -t ed25519 -f ~/.ssh/vendor_sftp_2026 -C vendor-sftp-2026

Til job uden opsyn bør den tilsigtede identitet fastlåses, så jobbet ikke ved et tilfælde lykkes, fordi en agent tilbyder en anden nøgle:

Host partner-legacy-sftp
    HostName sftp.partner.example
    User upload
    IdentityFile ~/.ssh/vendor_sftp_2026
    IdentitiesOnly yes

Hold undtagelser små og synlige

Nogle partnere moderniserer ikke efter din tidsplan. Det er normalt, men bør håndteres som en udtrykkelig undtagelse. OpenSSH-klienten understøtter Host- og Match-blokke, og WarnWeakCrypto kan undertrykke advarslen om manglende post-kvantesikkerhed for en bestemt host. Brug det med omtanke:

Match host partner-legacy-sftp
    WarnWeakCrypto no-pq-kex

Denne linje er ikke en løsning. Den er en dokumenteret accept af risikoen, mens serverens ejer indhenter efterslæbet. Angiv en begrundelse, en ansvarlig og en revisionsdato ud for den i dit endpointregister. Placér ikke den samme indstilling under Host *, for så lærer du alle fremtidige SSH-forbindelser at være mere stille, netop når de burde give flere oplysninger.

Hvad efterlader et godt oprydningsprojekt?

En nyttig OpenSSH 10-oprydning er lille, men disciplineret. Resultatet bør være moderne nøgler, hvor det er muligt, afgrænsede kompatibilitetsindstillinger, hvor de er uundgåelige, en fortegnelse over de endpoints, der stadig kræver handling fra en partner, samt enkel overvågning af de overførsler, der er vigtige. For de fleste teams betyder det alarmer ved fejlede exitkoder, manglende forventede filer og nye kryptografiadvarsler i migreringsperioden.

Bureauer kan anvende den samme tilgang på tværs af kundemiljøer uden at gøre enhver undtagelse til en permanent, skræddersyet særtilfælde. For driftsansvarlige giver den noget bedre end en diffus sikkerhedsbekymring: en afgrænset liste over endpoints, ansvarlige, risici og løsninger. Hvis du vil have arbejdet håndteret som et afgrænset udviklingsprojekt, kan du tale med Greg om en SSH/SFTP-oprydning.

Relateret indhold på GrN.dk

Har du brug for hjælp til denne type arbejde?

Afgræns en SSH/SFTP-oprydning sammen med Greg. Kontakt Greg.

Kilder

Sidst ændret

2026-09-02