# 🔑 SSH Key-based Authentication – Øvelse > [!info] Om denne øvelse > **Tid:** 45–60 minutter > **Form:** Parvis – begge studerende genererer hver sit nøglepar og logger ind selvstændigt > **Mål:** Generere SSH-nøglepar, dele public keys med hans via Canvas grupperum, logge ind på en fælles Ubuntu-server i [UpCloud](https://upcloud.com/) – og bagefter undersøge hvad der sker i logfilerne når nogen forsøger at bryde ind. --- > [!tip] Læringsmål > Hvad kan du når du er færdig med denne øvelse? > - Generere et SSH-nøglepar med `ssh-keygen` i terminal / PowerShell > - Forklare forskellen på **public key** og **private key** – og hvad der må deles > - Etablere en SSH-forbindelse til en remote server vha. key-based authentication > - Læse og fortolke systemlogfiler med `cat`, `tail`, `grep` og `tail -f` > - Identificere et konkret logon-forsøg i `auth.log` ud fra en reel hændelse --- > [!abstract] Baggrund > I er ved at forbinde jer til en **Ubuntu 24.04 LTS**-server der kører på **UpCloud** i et europæisk datacenter. > > UpCloud kræver at en SSH public key uploades **inden** en maskine (VM) kan oprettes. Password-login til root er deaktiveret som standard. Det er et bevidst designvalg der fjerner den letteste angrebsvej: automatiserede brute force-angreb mod password-login. > > **Begge** i bodymakker teamet genererer deres eget nøglepar. Begge nøgler installeres på den samme server – så I kan logge ind uafhængigt af hinanden med jeres respektive nøgler. --- ## Del 1 – Begge genererer hvert sit SSH-nøglepar > [!note] Begge udfører disse trin – uafhængigt og på jeres egne maskiner --- ### Trin 1 – Åbn terminal **macOS / Linux:** Åbn `Terminal` **Windows:** Åbn `PowerShell` eller `Windows Terminal` Verificér at SSH er tilgængeligt: ```powershell ssh ``` Du bør se noget i stil med: ```powershell usage: ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface] [-b bind_address] [-c cipher_spec] [-D [bind_address:]port] [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11] [-i identity_file] [-J destination] [-L address] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-P tag] [-p port] [-Q query_option] [-R address] [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]] destination [command [argument ...]] ``` > [!warning] Hvis ssh ikke findes på Windows >Vil du få dette output >```powershell >PS C:\Users\hans> ssh ssh: The term 'ssh' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. >``` >Du skal nu installere OpenSSH på din maskine ser mere hos [MS learn](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse?tabs=powershell&pivots=windows-11) >```powershell >Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*' >``` >```powershell >Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0 >``` --- ### Trin 2 – Generer dit nøglepar Kør følgende – erstat `dit-navn@skole` med din skolemail: ```bash ssh-keygen -t ed25519 -C "dit-navn@skole" ``` Du vil blive spurgt om tre ting: **1. Placering:** ``` Enter file in which to save the key (~/.ssh/id_ed25519): ``` Tryk **Enter** for standardplacering. **2. Passphrase:** ``` Enter passphrase (empty for no passphrase): ``` Vælg en passphrase du kan huske – eller tryk **Enter** for ingen (acceptabelt i øvelsessammenhæng). Ta' en hurtig snak i makkerparret om hvad tilføjelse af et password tilføjer af sikkerhed. **3. Gentag passphrase:** Tast igen og tryk **Enter**. --- ### Trin 3 – Verificér filerne **macOS / Linux:** ```bash ls -la ~/.ssh/ ``` **Windows (PowerShell):** ```powershell dir $env:USERPROFILE\.ssh\ ``` Du bør se to filer: - `id_ed25519` → **din private nøgle** – forlader aldrig din maskine - `id_ed25519.pub` → **din public key** – den du deler --- ### Trin 4 – Se din public key **macOS / Linux:** ```bash cat ~/.ssh/id_ed25519.pub ``` **Windows (PowerShell):** ```powershell Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub ``` Output ser nogenlunde sådan ud: ``` ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... dit-navn@skole ``` > [!danger] Vigtigt > Del **udelukkende** indholdet af `.pub`-filen. > Del **aldrig** indholdet af `id_ed25519` (uden `.pub`) – med nogen, nogensinde. ever! punktum! --- ## Del 2 – Del jeres public keys med HH > [!note] Begge uploader hver sin public key > Gå ind i jeres **Canvas-grupperum** og indsæt indholdet af jeres `.pub`-fil. > Skriv dit navn tydeligt over din nøgle så jeg ved hvem der ejer hvilken. > > Jeg opretter en Ubuntu-VM på UpCloud med **begge nøgler installeret**. > **I får en IP-adresse tilbage** – vent på besked. --- **Mens I venter – diskutér:** Find link i Canvas til at indsende jeres svar > [!question] Refleksion > **Spørgsmål 1:** Hvad ville der ske, hvis I ved en fejl indsatte den private nøgle i stedet for `.pub`-filen? > > **Spørgsmål 2:** Begge jeres public keys installeres på samme server. Betyder det at I kan se hinandens private nøgler? Forklar hvorfor eller hvorfor ikke. --- ## Del 3 – Log ind på serveren Når I har modtaget en IP-adresse, logger **begge** ind – fra jeres egen laptop: ```bash ssh root@<IP-ADRESSE> ``` > [!warning] Første gang I forbinder > SSH spørger om I stoler på serveren: > ``` > The authenticity of host '...' can't be established. > ED25519 key fingerprint is SHA256:... > Are you sure you want to continue connecting (yes/no)? > ``` > Skriv `yes` og tryk **Enter**. Verificér at I begge kan logge ind selvstændigt: **Hvem er I logget ind som?** ```bash whoami ``` **Er I begge på serveren på samme tid?** ```bash who ``` Log ud fra serveren. Forsøg hvor én af jer tilgår internettet via et hotspot via en mobil telefon. Gentag ovenstående inspektion af hvem som er logget ind og hvilke oplysninger i kan se. Hvad har ændret sig? --- ## Del 4 – Undersøg logfilerne > [!abstract] Baggrund > Linux/ubuntu logger alle autentificeringshændelser i `/var/log/auth.log` – SSH-loginforsøg, vellykkede logins, fejlede forsøg og meget mere. I skal nu lære tre måder at læse denne fil på, fra overblik til live overvågning. --- ### 4a – Overblik med cat `cat` udskriver hele filens indhold: ```bash sudo cat /var/log/auth.log | less ``` Brug **pil op/ned** til at navigere, `q` for at afslutte. Hvad ser I? Notér jeres første observationer: Hvad sker der hvis du anvender `more` i stedet for `less` --- ### 4b – De seneste hændelser med tail `tail` viser de **sidste linjer** af en fil: ```bash sudo tail -10 /var/log/auth.log ``` **Spørgsmål:** Ser I mislykkede SSH-loginforsøg? Fra hvilke IP-adresser, og hvad forsøger de at logge ind med? > [!info] Det I sandsynligvis ser > Selv en splinterny server vil have modtaget automatiserede angrebsforsøg inden for de første minutter efter opstart. Bots scanner kontinuerligt alle public IP-adresser på port 22 og prøver kendte brugernavne som `root`, `admin`, `test`, `ubuntu`. > Dette er **path of least resistance** i praksis – og netop det key-based authentication beskytter imod. --- ### 4c – Filtrér med grep `grep` finder kun de linjer der matcher et mønster: **Alle mislykkede forsøg:** ```bash sudo grep "Failed password" /var/log/auth.log ``` **Alle vellykkede logins:** ```bash sudo grep "Accepted publickey" /var/log/auth.log ``` **Ukendte brugernavne der er forsøgt:** ```bash sudo grep "Invalid user" /var/log/auth.log ``` **Kombinér tail og grep:** ```bash sudo tail -100 /var/log/auth.log | grep "Invalid user" ``` > Notér brugernavne der forsøges, antal forsøg og IP-adresser I finder: --- ### 4d – Live overvågning med tail -f `tail -f` holder filen åben og viser **nye linjer løbende i realtid**: ```bash sudo tail -f /var/log/auth.log ``` Lad kommandoen køre i baggrunden. **Én person holder `tail -f` kørende. Den anden åbner en ny terminal** og logger ind på serveren igen: ```bash ssh root@<IP-ADRESSE> ``` **Spørgsmål:** Hvad ser den der overvåger loggen? Find linjen der viser det vellykkede login og skriv den ned: Tryk **Ctrl + C** for at stoppe `tail -f` når I er klar til at gå videre. --- ## Del 5 – Gruppeøvelse: Find brugernavnet i loggen > [!note] Koordinering > Find sammen med en nabo-gruppe og fortæller hvem der starter som "angribere" og hvem der starter som "forsvarere". Nabo-gruppen forsøger at logge ind på **jeres** server, og I skal finde ud af hvad de kaldte sig. --- ### Forsvarer-rollen – jeres gruppe Start live-overvågning af jeres log: Jeres opgave er at **identificere det brugernavn** nabo-gruppen bruger når de forsøger at logge ind. Hvilken kommando anvender du til ovenstående? --- ### Angriber-rollen – nabo-gruppen gør dette mod jeres server De vælger et vilkårligt brugernavn – **et tilfældigt ord, ikke et rigtigt brugernavn** – fx `pirat`, `ninja`, `hacker`, `kaffe`. De aftaler det internt og fortæller det **ikke** til jer. De forsøger at logge ind på jeres server: ```bash ssh <valgt-brugernavn>@<JERES-IP-ADRESSE> ``` Login fejler – det er meningen. Det efterlader alligevel et spor i jeres log. --- **Hvad var brugernavnet nabo-gruppen valgte?** **Hvilken linje i loggen afslørede det?** Er der en måde at se linjenummer på? Hvordan henter i bedst en kopi af auth.log ned på jeres egen maskine til "offline" analyse og efterforskning? --- ### Skift roller Nu bytter I. I vælger et brugernavn og forsøger at logge ind på nabo-gruppens server. De overvåger deres log og skal finde jer. **Det brugernavn I valgte:** **Fandt de det? Hvor hurtigt?** --- ## Del 6 – Afsluttende refleksion *(ca. 5 min)* **Spørgsmål 1** I så at serveren allerede var under angreb fra bots kort efter opstart. Hvad fortæller det jer om vigtigheden af at deaktivere password-login fra sekund ét? **Spørgsmål 2** Brugernavnet optrådte i klartekst i `auth.log`. Hvad er implikationen for en administrator – hvad bør man gøre med den slags logfiler over tid? **Spørgsmål 3** Hvilken risikobehandlingsstrategi svarer det til at UpCloud tvinger key-based authentication frem som eneste mulighed? Og hvad er restrisikoen – hvad beskytter SSH-nøgler **ikke** imod? --- > [!success] Tjekliste – er I i mål? > > - ☐ Vi har begge genereret vores eget Ed25519-nøglepar > - ☐ Vi har begge uploadet vores public key via Canvas-grupperum > - ☐ Vi har begge logget ind selvstændigt på serveren med vores egne nøgler > - ☐ Vi har undersøgt auth.log med `cat`, `tail` og `grep` > - ☐ Vi har brugt `tail -f` til live overvågning og set vores eget login dukke op > - ☐ Vi har identificeret nabo-gruppens valgte brugernavn fra loggen > - ☐ Vi kan forklare hvad en linje i auth.log betyder --- > [!cite] Kilder og videre læsning > - A. Sequeira, *CompTIA Network+ N10-009 Cert Guide*, Kap. 6 – Secure a Network in a Cloud Environment > - OpenSSH dokumentation: https://www.openssh.com/manual.html > - UpCloud – SSH key authentication guide: https://upcloud.com/docs/guides/use-ssh-keys-authentication/ > - Ubuntu – System logs reference: https://ubuntu.com/server/docs/about-system-logging