En gammel administratornøgle ligger stadig i projektmappen. Den virker på flere servere, men ingen ved præcist, hvem der har en kopi. Skiftet fra adgangskoder til SSH-nøgler har ændret loginmetoden uden at afklare ansvaret.
Brugbar SSH-administration forbinder individuelle identiteter, passende målrettigheder og pålidelig tilbagekaldelse. Afhængigt af miljøet kan vedligeholdte offentlige nøgler med en god fortegnelse være nok. Større eller ofte skiftende miljøer kan have gavn af kortlivede SSH-certifikater. Begge veje kræver en drift, der kan håndteres.
Fire ting, der ikke bør forveksles
Den private brugernøgle gør det muligt at bevise egen identitet. Den opbevares beskyttet og distribueres ikke via chat, mail eller en ubeskyttet projektmappe. Den tilhørende offentlige nøgle kan registreres på de planlagte målsystemer for at tillade adgang. Dens fingeraftryk hjælper med entydig identifikation i fortegnelsen.
Værtsnøglen identificerer derimod den server, der kontaktes. Værtskontrollen forhindrer, at forbindelsen ubemærket ender hos den forkerte modpart. Et SSH-certifikat føjer en signeret erklæring til en offentlig nøgle, eksempelvis om identitet og gyldighed. OpenSSH-certifikater har deres eget format og er ikke almindelige TLS-/X.509-certifikater.
Adskil personlige login fra tekniske job
Administrativt arbejde knyttes til personer og deres tilladte opgaver. En fælles, langtidsgyldig rootnøgle gør fratrædelse, rotation og sporbarhed unødigt vanskeligt. Individuelle login med passende regulerede administratorrettigheder giver et bedre grundlag.
Et backup- eller udrulningsjob har brug for sin egen tekniske identitet med dokumenteret ansvar. Hvor det er muligt, begrænses adgangen til den konkrete funktion, eksempelvis med en tvungen kommando og passende regler for videresendelse. En medarbejders private nøgle bør ikke ubemærket blive en permanent forudsætning for et automatisk job.
Fra nøglefortegnelse til kortlivede certifikater
Ved få systemer kan kontrolleret distribution af offentlige nøgler være tilstrækkelig. Fortegnelsen registrerer person eller tjeneste, fingeraftryk, målsystemer, omfang og planlagt dato for kontrol eller udskiftning. Det afgørende er pålidelig vedligeholdelse af rettigheder på alle berørte mål.
En SSH-certifikatautoritet kan i stedet signere offentlige nøgler for en begrænset periode og bestemte identiteter. Serverne stoler på den udpegede CA og kontrollerer deres øvrige regler. Den private loginnøgle skal ikke sendes til CA’en. CA-nøglerne og udstedelsesreglerne beskyttes særligt.
Korte gyldighedsperioder begrænser brugstiden for en udstedt legitimation. De afslutter dog ikke en eksisterende session og erstatter ikke tilbagekaldelsesprocessen. Efter en fratrædelse skal udstedelse af nye certifikater også forhindres. En central platform til hemmeligheder er en mulig driftsform; den skal faktisk understøtte det konkrete SSH-forløb.
| Administrationsvej | Passer til | Krav til driften |
|---|---|---|
| Vedligehold offentlige nøgler | Et overskueligt, godt registreret sæt målsystemer. | Distribution, fjernelse af gamle rettigheder og stedfortrædere. |
| Udsted SSH-certifikater | Begrænset gyldighed og definerede identiteter. | CA-beskyttelse, udstedelsesregler, servertillid og tilbagekaldelse. |
| Tekniske identiteter | Automatisering med en klar opgave. | Begrænsede målrettigheder, ansvar og rotationsprocedure. |
| Agent eller hardwarenøgle | Egnede metoder til personligt login. | Grænser for videresendelse, versionskontrol og gendannelse. |
Brug agent og hardwarenøgler bevidst
En SSH-agent kan muliggøre login med indlæste nøgler uden at kopiere den private nøglefil til hver målserver. Videresendelse af agenten giver dog et fjernsystem adgang til dens signeringsfunktioner. OpenSSH advarer udtrykkeligt om, at en angriber med tilstrækkelig adgang til dette system kan logge ind med de indlæste identiteter uden at udlæse selve nøglerne.
Agentvideresendelse sættes derfor kun op til den nødvendige vej. Understøttede tids- eller målbegrænsninger kan sætte yderligere grænser. Hardwaresikkerhedsnøgler er en anden mulighed til egnede interaktive adgange. Klient, server, nøgletype og krav om berøring eller PIN skal passe sammen; et ubemandet job har andre behov end et personligt login.
Rotation og tilbagekaldelse skal nå målet
En udskiftning på notebooken fjerner ikke den gamle adgang fra serveren. Ved registrerede offentlige nøgler skal rettigheder opdateres på alle berørte mål. Certifikater kan desuden benytte spærringsmekanismer som OpenSSH Key Revocation Lists. En spærring virker først, når de planlagte servere håndhæver den korrekt.
Forløbet omfatter også en mistet enhed, en kompromitteret nøgle og en utilgængelig administrationstjeneste. Uafhængig nødadgang beskyttes, dokumenteres og testes kontrolleret. Gendannelse må ikke afhænge af netop den adgangsvej, der er svigtet.
Gå differentieret frem i Linux- og Proxmox-miljøer
I blandede miljøer registreres versioner og de OpenSSH-funktioner, der faktisk understøttes. En aktuel manual garanterer ikke, at alle eksisterende Linux-installationer har de samme muligheder. Nye regler indføres med en udpeget testadgang og en kontrolleret vej tilbage.
Proxmox VE bruger også SSH til egne klyngefunktioner, herunder bestemte konsol-, migrerings- og replikeringsveje. Disse tekniske tillidsforhold vurderes adskilt fra personlige administratoradgange. Generel oprydning eller overskrivning af nøglefiler kan forstyrre driften. Ændringer kontrolleres derfor mod dokumentationen for den installerede version.
Hvad et overskueligt første skridt indeholder
DAXS registrerer eksisterende SSH-adgange, fordeler ansvar og planlægger passende administration. Piloten tester login, rettigheder, tilbagekaldelse, logning og gendannelse. Et vellykket login alene er ikke tilstrækkeligt som acceptkriterium. Rene loginlogfiler er heller ikke automatisk en fuldstændig registrering af alle udførte kommandoer.
Infrastrukturydelserne og artiklen om Proxmox i virksomheden sætter driften i perspektiv. For fælles portaler supplerer artiklen om bokse, roller og fratrædelse perspektivet. Du kan anmode om en kortlægning af administrative adgange.
Ofte stillede spørgsmål
Må jeg dele en offentlig nøgle?
Den offentlige del er beregnet til passende distribution. Tilknytningen til den rette person og det rette mål skal stadig kontrolleres. Den private del beskyttes og sendes ikke rundt som fælles adgangsfil.
Er et kortlivet certifikat nok til øjeblikkelig tilbagekaldelse?
Nej. Udstedelse, resterende gyldighed, kontrol af spærringer og eksisterende sessioner skal ses samlet. En kort periode erstatter ikke denne proces.
Er en central certifikatautoritet altid nødvendig?
Nej. Omfang, ændringshyppighed, automatisering og driftskapacitet afgør den passende løsning. Velholdt nøgleadministration kan være egnet til et overskueligt antal systemer.
Kilder: OpenSSH: login og autoriserede nøgler (eksternt link) · OpenSSH: certifikater og spærringslister (eksternt link) · OpenSSH: serverens tillids- og spærringsregler (eksternt link) · OpenSSH: agentvideresendelse (eksternt link) · OpenSSH: agentnøgler og begrænsninger (eksternt link) · Proxmox VE: administrationsmanual, SSH i klyngen (eksternt link)
Konceptuel vejledning; konkrete funktioner afhænger af installerede versioner og planlagt administration.
