Sikkerhed

Optimeret SSH-konfiguration til udviklere – sikkerhed og komfort i ét

En godt gennemtænkt SSH-konfiguration kombinerer stærk autentificering, klare serverregler og komfortable klient-workflows til en sikker og hurtig hverdag for udviklere. Jeg viser, hvordan jeg kombinerer nøgler, sshd_config, MFA, overvågning og komfortfunktioner, så fjernadgang forbliver sikker, og implementeringer kører problemfrit.

Centrale punkter

Følgende centrale aspekter forener sikkerhed og komfort og udgør den røde tråd i denne vejledning.

nøgle i stedet for adgangskoder og fornuftig brug af agenter
sshd_config Målrettet hærdning og aktivering af protokoller
MFA og IP-spærringer som et ekstra beskyttelseslag
Klientkonfiguration til korte kommandoer og flere taster
Tunneling, SFTP/SCP og CI/CD-integration

SSH-nøgler i stedet for adgangskoder: hurtig omstilling med effekt

Jeg erstatter konsekvent adgangskoder med nøglepar, fordi jeg dermed effektivt kan afværge brute force-forsøg og ordbogsangreb. Den private nøgle forbliver på min enhed, den offentlige ligger på serveren i authorized_keys, og logningen beviser kryptografisk ejerskabet uden at overføre hemmeligheden. Til nye par bruger jeg ssh-keygen og satser på Ed25519 eller tilstrækkeligt stærke RSA-længder, så nøglekraften er korrekt. Jeg beskytter den private nøgle med en adgangskode og indlæser den i en SSH-agent, så jeg ikke behøver at indtaste den ved hver forbindelse. På den måde fungerer interaktive logins, automatiseringer og CI-jobs sikkert og uden unødvendige problemer.

Hærdning af SSH-server: de afgørende parametre i sshd_config

På serveren placerer jeg sshd_config således, at unødvendige angrebsflader forsvinder, og stærke procedurer håndhæves. Jeg deaktiverer PasswordAuthentication og PermitRootLogin, tildeler en klar adgangsfortegnelse via AllowUsers og flytter porten for at reducere trivielle scanninger. Jeg indstiller eksplicit moderne krypterings- og MAC-suiter, så klienter ikke forhandler svagere algoritmer. Derudover begrænser jeg autentificeringsforsøg, login-tidsvinduer og holder styr på sessioner med ClientAlive-parametre. For mere information Tips til at gøre Linux mere sikker Jeg supplerer med firewall-regler, hastighedsbegrænsning og ren pakkevedligeholdelse.

MFA og ekstra beskyttelseslag

For administrative tilgange tilføjer jeg en anden Faktor tilføjes, så en aflyttet nøgle alene ikke er nok. TOTP via en smartphone eller sikkerhedstoken supplerer ejerskabsbeviset og blokerer uautoriserede forsøg. I OpenSSH kombinerer jeg publickey med keyboard-interactive, styrer det via PAM-modulet og dokumenterer logningen ordentligt. Derudover bruger jeg Fail2ban eller lignende værktøjer, der tæller fejlagtige forsøg og automatisk blokerer adresser i en periode. På den måde mindsker jeg risikoen for succesfulde angreb uden at bremse mine legitime processer.

Protokollering og overvågning med sans for proportioner

Jeg forhøjer LogLevel på VERBOSE, så log-hændelser registreres med kontekst, og revisioner får pålidelige spor. Jeg videresender logfilerne centralt til Syslog, Log-Server eller SIEM, så jeg kan genkende mønstre og ikke kun ser enkeltstående tilfælde. Alarmer udløses ved mange fejlagtige forsøg, usædvanlige regioner eller afvigende tidspunkter, så jeg kan handle hurtigt. Især teams med flere SSH-brugere drager fordel af klar logning, fordi ansvarsområder og handlinger forbliver sporbare. På den måde forbliver miljøet transparent, og jeg kan reagere hurtigere på reelle hændelser.

Komfort på klienten: Brug ~/.ssh/config på en fornuftig måde

Jeg gemmer tilbagevendende forbindelsesdata i SSH-konfiguration fast, så jeg arbejder med korte host-aliaser og undgår fejl ved lange kommandoer. Jeg tildeler bruger, port, hostnavn og identitetsfil pr. alias, så staging eller produktion kan nås med et enkelt ord. For separate projekter vedligeholder jeg separate nøgler og integrerer dem via den passende host-linje. Agenten indlæser nøglerne efter den første adgangskodeindtastning, og konfigurationen beslutter automatisk, hvilken nøgle der hører hvorhen. Det sparer tid, reducerer fejl, og jeg kan holde fokus i konsollen.

Portvideresendelse og tunneling i hverdagen

Med LocalForward, Med RemoteForward og dynamisk SOCKS-tunnel får jeg sikker adgang til interne tjenester uden at åbne porte offentligt. Jeg får adgang til databaser, dashboards eller interne API'er på en krypteret, testbar og midlertidig måde. Til fejlfinding er det ofte nok for mig at oprette en kort tunnel i stedet for at opbygge en ekstra VPN-struktur. Jeg sørger for klare tidsvinduer og logger, når tunneler berører produktive systemer. På den måde holder jeg angrebsfladen lille og kan alligevel foretage hurtige analyser.

Filoverførsel, Git og CI/CD via SSH

Til artefakter, logfiler og sikkerhedskopier bruger jeg SFTP interaktivt og SCP i scripts, når det skal gå hurtigt. I CI/CD-pipelines forbinder Runner sig via SSH med målsystemer, henter repositorier, implementerer migrationer og starter rollouts. Værktøjer som Ansible eller Fabric bruger SSH til at udføre kommandoer sikkert på afstand og synkronisere filer. For botnøgler indstiller jeg begrænsede rettigheder, begrænser kommandoer og spærrer pseudo-TTY, så adgangen kun er egnet til det tilsigtede formål. Denne vejledning giver mig et praktisk overblik over sammenkoblingen SSH, Git og CI/CD, som jeg bruger som tjekliste.

Finmalet Højre med authorized_keys

Jeg kontrollerer, hvad en nøgle må gøre, direkte i authorized_keys via indstillinger som command=, from=, no-port-forwarding, no-agent-forwarding eller no-pty. På den måde knytter jeg automatiseringer til en foruddefineret startkommando, begrænser oprindelige IP-rum eller forbyder tunneler, hvis de ikke er nødvendige. På den måde minimerer jeg konsekvenserne af en nøglekompromittering, fordi nøglen ikke kan bruges frit interaktivt. Jeg adskiller projektrelaterede nøgler strengt, så jeg kan fjerne dem målrettet ved offboarding. Denne holdning skaber overblik og reducerer sidebevægelser i tilfælde af en hændelse.

SSH og valg af hosting: hvad jeg lægger vægt på

Når det gælder hosting-tilbud, tjekker jeg først SSH-adgang, understøttelse af flere nøgler pr. projekt og tilgængeligheden af vigtige CLI-værktøjer. Staging-miljøer, Cron, Git-integration og adgang til databaser via tunnel letter pålidelige arbejdsgange. Til langvarige projekter har jeg brug for daglige sikkerhedskopier, skalering og klar logføring, så revisioner kan gennemføres. En aktuel oversigt over Udbydere med SSH-adgang hjælper mig med at sammenligne passende platforme og undgå blinde vinkler. På den måde sikrer jeg mig et miljø, der ikke står i vejen for min arbejdsstil.

Host-nøgler, opbygning af tillid og known_hosts

Beskyttelse begynder med modpart: Jeg kontrollerer og fastgør hostnøgler konsekvent. Med StrictHostKeyChecking=ask/yes forhindrer jeg stille man-in-the-middle-risici. UpdateHostKeys hjælper med automatisk at hente nye hostnøgler uden at flyve i blinde. For teams vedligeholder jeg centrale Known-Hosts-filer (GlobalKnownHostsFile) og lader den personlige UserKnownHostsFile fungere som supplement. DNS-baserede SSHFP-poster kan gøre kontrollen lettere, men jeg bruger kun VerifyHostKeyDNS, hvis jeg stoler på DNSSEC. Det er også vigtigt for mig at aktivt rotere og slette gamle eller kompromitterede host-nøgler, så jeg ikke sidder fast i historiske tillidsforhold. Jeg bruger HashKnownHosts til at anonymisere servernavne i known_hosts og dermed reducere metadata.

SSH-certifikater og centrale CA'er

Når mange systemer og konti mødes, foretrækker jeg at satse på SSH-certifikater. I stedet for at distribuere hver offentlig nøgle enkeltvis, signerer en intern CA bruger- eller værtsnøgler med kort løbetid. På servere gemmer jeg TrustedUserCAKeys, så sshd kun accepterer nøgler, der er nyligt signeret og opfylder de roller/principals, der er gemt i certifikatet. På værtsiden bruger jeg HostCertificate/HostKey, så klienter kun accepterer værter, der er certificeret af den interne CA. Dette reducerer administrationsomkostningerne, forenkler offboarding (certifikater udløber) og forhindrer nøglespredning. Korte gyldighedsperioder (timer til få dage) tvinger en naturlig rotation uden at belaste brugerne.

Agent-videresendelse, jump-hosts og bastion-koncepter

ForwardAgent bliver hos mig standard fra, fordi en kompromitteret hop kan misbruge agenten. I stedet bruger jeg ProxyJump via en bastion-host og opretter også strenge politikker der. Hvis agent-forwarding er uundgåeligt, begrænser jeg det via authorized_keys-indstillinger (f.eks. restrict, no-port-forwarding) og holder bastionen hærdet og godt overvåget. Derudover bruger jeg from= til IP-scopes, så en nøgle kun fungerer fra kendte netværk. For bastioner indstiller jeg også klare AllowUsers/AllowGroups-regler, adskiller admin- og deploy-veje og tillader kun de nødvendige portvideresendelser (permitopen=) pr. nøgle. På den måde forbliver adgangsvejen kort, overskuelig og snævert afgrænset.

Multiplexing og ydeevne i hverdagen

For hurtige arbejdsgange spiller Multiplexing spiller en stor rolle. Med ControlMaster=auto og ControlPersist=5m åbner jeg en kontrolsocket pr. host og sparer mig for nye håndtryk ved hver kommando. Det fremskynder SCP/SFTP, implementeringer og ad hoc-administration mærkbart. Jeg bruger komprimering afhængigt af linket: Det giver fordele ved langsomme eller forsinkede forbindelser, og i lokale netværk sparer jeg CPU-overhead. Jeg balancerer ServerAliveInterval (klientside) og ClientAliveInterval (serverside) således, at forbindelserne forbliver stabile uden at hænge. Til KEX vælger jeg moderne metoder (f.eks. curve25519), indstiller en fornuftig RekeyLimit (f.eks. data eller tid) og sikrer dermed stabilitet ved lange overførsler og portforwards. Da scp i dag ofte bruger SFTP-protokollen, optimerer jeg primært SFTP-parametre og værktøjskæder.

Livscyklusstyring for nøgler

En god nøgle er kun så god som dens Livscyklus. Jeg tildeler klare navne og kommentarer (projekt, ejer, kontakt), registrerer nøglens oprindelse i dokumentationen og planlægger rotationer (f.eks. halvårligt eller ved projektmilepæle). Jeg vælger lange og brugervenlige adgangskoder, og agenten tager sig af gentagelsen. Til særligt følsomme adgange bruger jeg FIDO2-/hardware-nøgler (f.eks. [email protected]), som er phishing-resistente og gør den private komponent ikke-eksportabel. Hvis et enhed går tabt, tilbagekalder jeg adgangen ved at fjerne den fra authorized_keys eller ved at tilbagekalde certifikater. Streng adskillelse pr. projekt og miljø muliggør målrettet offboarding uden bivirkninger. Sidst, men ikke mindst, sørger jeg for rene filrettigheder: ~/.ssh med 700, private nøgler 600, authorized_keys 600 – og ejeren korrekt angivet.

Kun SFTP, chroot og match-blokke

Til service- eller partneradgang vælger jeg ofte en Kun SFTP-profil. I sshd_config aktiverer jeg internal-sftp som undersystem og tvinger via Match User/Group et ChrootDirectory, ForceCommand internal-sftp og deaktiverer portforwarding, agent-forwarding og pseudo-TTY. Dermed får disse konti præcis den dataudveksling, de har brug for – ikke mere. Match-blokke er også nyttige for deploy-brugere: Jeg tildeler dem snævre rettigheder, fastlægger en dedikeret sti og forhindrer interaktive shells. På denne måde kan funktionelle krav opfyldes uden at åbne en shell med fuld adgang.

CI/CD og non-interaktiv adgang skal sikres ordentligt

I rørledninger bruger jeg Deploy-nøgler pr. miljø og projekt, aldrig personlige nøgler. Jeg begrænser dem via authorized_keys (from= for Runner-IP-Ranges, command= for Wrapper-scripts, no-pty og no-agent-forwarding), fastgør host-nøgler i pipelinen (known_hosts som en del af repos/Secrets) og lader StrictHostKeyChecking være på sikker. Jeg administrerer hemmeligheder i CI-systemet, ikke i koden. Kortvarige certifikater eller tidsbegrænsede nøgler reducerer angrebsfladen yderligere. Jeg adskiller også læse- og skriveadgang: Pull/Fetch, artefakt-upload og server-deployment får hver deres egne identiteter. På den måde forbliver blast-radius lille, hvis et token løber ud.

Drift, overvågning og nødplan

I virksomheden hører Rutiner Derudover holder jeg OpenSSH opdateret, kontrollerer Logrotate, indstiller fornuftige opbevaringsfrister og tester alarmkæder. Et kort banner henviser til brugsbetingelserne og afskrækker nysgerrige tests. Jeg dokumenterer, hvordan jeg genopretter forbindelsen, når nøglerne er spærret (Break-Glass-procedure med MFA), uden at etablere bagdøre. Af hensyn til compliance adskiller jeg administrator- og applikationskonti, anvender sudo-politikker med logning og kontrollerer regelmæssigt, om AllowUsers/Groups, firewall og Fail2ban-regler stadig passer til den aktuelle situation. Jeg glemmer ikke IPv6: Jeg indstiller ListenAddress eksplicit, så kun de ønskede grænseflader lytter. Planlagte gennemgange (f.eks. kvartalsvis) sikrer, at konfigurationer ikke bliver forældede, og at nye teammedlemmer integreres korrekt.

Praktisk tabel: nyttige sshd_config-indstillinger

Følgende oversigt hjælper mig med at finde frem til de vigtigste Parametre hurtigt at kontrollere og sikre konsistens.

Indstilling	Anbefalet værdi	Effekt
PasswordAuthentication	nej	Deaktiverer adgangskodelogin og forhindrer trivielle gætteangreb.
PermitRootLogin	nej	Forbyder direkte root-login, administratorer bruger sudo via normale konti.
Tillad brugere	deploy adminuser …	Whitelisting begrænser adgangen til definerede konti.
Havn	f.eks. 2222	Reducerer trivielle scanninger, men erstatter ikke hærdning.
Krypteringsalgoritmer	f.eks. aes256-ctr,aes192-ctr,aes128-ctr	Tvinger moderne koder igennem og blokerer forældede procedurer.
MAC'er	hmac-sha2-256,hmac-sha2-512	Sikrer aktuelle integritetstests.
MaxAuthTries	3–4	Begrænset antal fejltagelser pr. forbindelse mærkbar.
LoginGraceTime	30–60	Luk halvåbne logins hurtigere.
ClientAliveInterval	30–60	Holder møder kontrolleret aktive og afbryder inaktive tidligt.
LogLevel	VERBOSE	Logger nøglefingeraftryk og autentificeringsoplysninger.

Praktisk workflow: balance mellem sikkerhed og komfort

Jeg begynder med Nøgler, hærder serveren, aktiverer logfiler og tilføjer MFA, hvor det er nødvendigt. På klienten opretter jeg rene aliaser, adskiller nøgler pr. projekt og bruger tunneler målrettet. Til automatiseringer tildeler jeg dedikerede, begrænsede nøgler, så hver maskine kun udfører sin opgave. Ved hosting tjekker jeg SSH-funktioner tidligt, så platformen understøtter min arbejdsgang. På den måde opstår der en opsætning, der afbøder angreb og samtidig gør min arbejdsdag hurtigere.