Slik gir du SSH en ekstra autentiseringsfaktor

Enhver som setter opp en Linux-server som er eksponert på internett, ser at det ikke tar lang tid før andre datamaskiner begynner å hamre på SSH-porten og vil inn. I utgangspunktet er det kun brukernavnet og passordet som beskytter datamaskinen mot innlogging fra uvedkommende, så selv svært anonyme servere kan oppleve mange hundre eller tusenvis av innbruddsforsøk hver dag, så lenge de er tilgjengelige via internett.

Det det meste av dette er trolig passordspraying, hvor det bare gjøres noen få forsøk med vanlige passord og vanlige brukernavn, før angrepet går videre til neste SSH-server. Slike angrepsforsøk er enkle å stoppe med et godt passord. Men som Microsoft oppgir i denne artikkelen, er det mange angrepsformer hvor kvaliteten på passordet ikke spiller noen rolle.

Konklusjonen til Microsoft er at det er mange tilfeller hvor kvaliteten på passordet spiller liten eller ingen rolle, fordi angripere ofte benytter velkjente teknikker for å finne ut hva passordet er.

SSH-forsterkning

SSH-protokollen brukes av svært mange som administrerer små og store Linux-baserte systemer. SSH er i utgangspunktet en ganske sikkerhet protokoll, men vanligvis krever standardoppsettet bare et brukernavn til en eksisterende brukerkonto på systemet, samt det tilhørende passordet.

Det er relativt enkelt å forsterke sikkerheten til SSH, blant annet ved å begrense hvilke kontoer som det er mulig å logge seg på via SSH ved å benytte en hviteliste. Root-kontoen bør ikke være blant kontoene det skal være mulig å logge seg direkte inn på via SSH. Det kan også være fornuftig å blokkere kontoer midlertidig dersom det registreres mer enn noen få mislykkede innloggingsforsøk rett etter hverandre.

En løsning som fail2ban kan i tillegg automatisk stenge IP-adresser ute dersom det for eksempel registreres mange mislykkede innloggingsforsøk over kort tid fra den samme kilden. Mange Linux-distribusjoner har fail2ban tilgjengelig i pakkebrønnen.

Alt dette bør være kjent fra før, men ingenting av dette har noen nevneverdig effekt dersom angriperen kjenner innloggingspassordet. Det som derfor må til, er én eller flere ekstra innloggingsfaktor.

Nøkkelpar

En løsning som har vært tilgjengelig «i alle år», er å bruke et benytte et kryptografisk nøkkelpar. Dette kan brukes både i stedet for eller som et supplement til passord. Sikkerheten er svært god, så lenge ingen får tak i den private nøkkelen. Men fleksibiliteten reduseres siden det kun er mulig å logge seg på fra systemer hvor en slik nøkkel er tilgjengelig for brukeren.

I denne saken er det derimot bruk av engangspassord som 2FA-løsning for SSH som er temaet. Mer om hvordan SSH kan settes opp til å benytte nøkkelpar som autentiseringsfaktor, finnes blant annet her.

Engangspassord fra mobilapp

En mer fleksibel løsning enn kryptografiske nøkler, er å benytte deler av den samme teknologien som blant annet Google tilbyr for to-faktor autentisering ved innlogging på selskapets tjenester. Den aktuelle metoden innebærer bruk av en tidsbegrenset engangskode som genereres av programvare eller app som er installert på en enhet brukeren har tilgang til.

Dette er relativt raskt og enkelt å installere og konfigurere på Linux-baserte systemer. På Ubunbu og andre systemer som benytter pakkeverktøyet apt-get, installeres den nødvendige programvaren med følgende kommandoen.

I CentOS og andre Red Hat-baserte Linux-distribusjoner, ligger den nødvendige pakken i EPEL-pakkebrønnen (Extra Packages for Enterprise Linux). Dersom støtte for EPEL ikke allerede er installert, kan i blant annet CentOS 7.x gjøres med følgende yum-kommando:

etterfulgt av:

Resten av framgangsmåten er i stor grad uavhengig av Linux-distribusjon.

Den nevnte programvarepakken installerer blant annet verktøyet google-authenticator, og dette må kjøres av hver eneste bruker som skal kunne logge seg på systemet via SSH i framtiden.

Innlogget som denne vanlige brukeren, kjøres kommandoen slik:

Da dukker først dette spørsmålet opp:

Trykk y og Enter. Da vises en QR-kode tilsvarende den nedenfor i terminalvinduet. Denne må leses inn med en autentiseringsapp på mobilen, for eksempel Google Autentisering eller Authy.

Alternativt kan man taste inn nøkkelen som er oppgitt under QR-koden. De fem nødkodene som er oppgitt under dette, bør man ta vare på.

Spørsmålet som vises nederst på bildet over, må man også svare y på. Ellers stopper verktøyet.

Det neste trinnet vises nedenfor:

Her bør man nok en gang svare med en y, denne gang for å forhindre MitM-angrep (Man in the Middle).

Over til neste trinn:

I mobilappen genereres det en ny kode hvert 30. sekund. Dette trinnet handler om å ta høyde for virkelig dårlig synkronisering av tiden mellom klient og server, utover det som i utgangspunktet aksepteres, slik at hele 17 koder på rad aksepteres. Det er en vurderingssak om en bør åpne for dette, men i de fleste veiledninger anbefales det at man svarer y også her.

Da kommer man hit:

Dette handler om beskyttelse mot «brute force»-angrep. Selv om man har beskyttet systemet mot slike angrep med nevnte fail2ban eller lignende, kan man med fordel svare y her.

Med dette er kjøringen av google-authenticator-verktøyet ferdig for denne ene brukeren. Som nevnt må dette gjøres av alle som skal kunne logge inn på sin konto på systemet via SSH.

Endringer av konfigurasjonsfiler

Det som nå gjenstår, er å fortelle systemet at det skal kreve at brukeren oppgir engangskoden under innloggingen. Dette gjøres ved å redigere filen /etc/pam.d/sshd som superbruker, for eksempel med følgende kommando:

Nederst i filen må følgende linje legges til:

Linjen over sørger for at ingen får logget på uten å tastes inn engangskoden. Dette kan være et problem dersom enkelte brukere ikke har kjørt google-authenticator-verktøyet ennå.

I påvente av dette kan man legge til parameteren nullok på slutten av linjen over:

Da kreves det kun engangspassord for innlogging på kontoer hvor dette er satt opp. Se flere detaljer her.

SSH-serveren må få beskjed om at den skal be om engangspassordet. Åpne filen /etc/ssh/sshd_config i et redigeringsverktøy:

Se etter linjen:

Denne må endres til:

Forsiktig testing

Nå er det på tide å starte SSHD, altså SSH-daemonen på serveren på nytt. Det er en viss risiko å gjøre endringer i oppsettet til SSHD dersom man ikke har fysisk tilgang til datamaskinen, for da kan det hende man ikke får logget seg på igjen via SSH. Følgende kommando sjekker blant annet om det er syntaksfeil i konfigurasjonsfilen:

Kommandoen gir ingen tilbakemelding dersom den ikke oppdager at noe er galt. Da kan man i alle fall være rimelig sikker på SSHD ikke nekter å starte på nytt, noe som kan skje dersom programvaren ikke greier å tolke endringene i konfigurasjonsfilen.

Når dette er gjort, startes SSHD på nytt på vanlig måte. Det kan gjøres på ulike måter, for eksempel:

Fortsatt kan det gå galt, så det er viktig å beholde den SSH-forbindelsen du allerede har, i tilfelle noe må endres på serveren.

For å teste det nye oppsettet, bør du derfor starte en separat SSH-økt.

Logg inn på vanlig måte. Dersom alt går bra, må du nå taste inn brukernavn og passord på som tidligere, før du til slutt bli bedt om å oppgi engangskoden som du finner i autentiseringsappen på mobilen.

Er ikke alltid egnet

SSH med engangspassord som sekundær autentiseringsfaktor bør ikke by på noen problemer med ordinære SSH-klienter, men det kan oppstå problemer med andre typer klienter som benytter og har en viss form for innebygd støtte for SSH-tunnelering. Det er langt fra alle slike verktøy som også har støtte for inntastingen av engangspassordet.

Et slikt eksempel er databaseadministrasjonsverktøyet HeidiSQL. Det har riktignok støtte 2FA ved innlogging direkte mot MySQL/MariaDB, altså helt uavhengig av tunnelering. Men verktøyet støtter ikke SSH-tunneler med engangspassord som sekundær autentisering. I stedet får man opp en dialogboks som det ikke er mulig å skrive noe inn i.

Derimot har HeidiSQL støtte for bruk av nøkkelpar som en sekundær faktor i SSH-tunneler, så man er uansett ikke nødt til å greie seg med brukernavn og passord alene.

Det er mulig å omgå hele problemet ved å bruke et separat verktøy til å etablere tunnelen, for eksempel PuTTY. Men dette er selvfølgelig mindre smidig enn at ett eneste verktøy tar seg av alle deler av oppkoblingen.