Hopp til innhold

SSH - Herding og sertifikater

Skip to content

Herd SSH-innloggingen og bruk sertifikater

Når nøkkelinnlogging virker, trenger ikke serveren lenger å godta passord over nettverket. Det stopper alle som prøver å gjette passord. I denne delen skrur du av passord- og root-innlogging på en trygg måte. Til slutt ser du hvordan SSH-sertifikater gjør det enklere å styre tilgang til mange servere.

Forutsetninger

  • Nøkkelinnlogging virker, se SSH Level 2.
  • Brukeren din har sudo, se Gjør serveren klar.
  • Konsollen i Proxmox er åpen. Den er reserveveien hvis du låser deg ute av SSH.

Skru av passord- og root-innlogging

SSH-tjenesten leser innstillinger fra /etc/ssh/sshd_config og fra filer i mappen /etc/ssh/sshd_config.d/. Lag en egen fil, så er det lett å se hva du har endret og å angre:

sudo nano /etc/ssh/sshd_config.d/10-sikker.conf

Skriv inn:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

PasswordAuthentication no stenger vanlig passordautentisering. KbdInteractiveAuthentication no stenger også tastaturinteraktiv autentisering, som ellers kan godta passord gjennom PAM. PermitRootLogin no stenger root-innlogging helt.

For de fleste SSH-innstillinger gjelder den første verdien tjenesten leser. Filen din vinner derfor ikke automatisk over andre filer: plasseringen av Include, tidligere innstillinger og eventuelle Match-blokker kan påvirke resultatet. Kontroller de effektive verdiene før du laster inn endringen.

Kontroller innstillingene før du laster dem inn:

sudo sshd -t

Kommer det ingen melding, er syntaksen gyldig. Se deretter hvilke verdier den nye konfigurasjonen gir:

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication) '

Alle tre skal vise no. Får du andre verdier, undersøker du /etc/ssh/sshd_config og filene den inkluderer før du fortsetter. Med Match-regler kontrollerer du også den aktuelle forbindelsen med sudo sshd -T -C user=user,addr=KLIENT-IP,host=KLIENTNAVN; erstatt eksempelverdiene med brukeren, klientadressen og klientnavnet for innloggingen du tester. Gjør samme kontroll av de tre innstillingene.

Når verdiene er riktige, laster du inn endringen:

sudo systemctl reload ssh

Lukk ikke vinduet du er logget inn i. Åpne et nytt terminalvindu og test:

ssh debian-vm                 # skal virke
ssh root@SERVER-IP            # skal bli avvist
ssh -o PubkeyAuthentication=no user@SERVER-IP   # skal bli avvist, ingen passordspørsmål

Passordet til brukeren trenger du fortsatt til sudo. Det skrives på serveren, ikke over nettverket.

Fordypning: SSH-sertifikater

Med ti servere og fem administratorer må hver nøkkel ligge på hver server. Det blir femti oppføringer i authorized_keys, og når noen slutter, må nøkkelen fjernes overalt.

Med sertifikater signerer en sertifikatutsteder (CA) nøkkelen din. Serverne stoler på CA-en, ikke på hver enkelt nøkkel. Sertifikatet inneholder også:

  • principals: navnene sertifikatet gjelder for, for eksempel admin
  • gyldighetstid: når sertifikatet slutter å virke

Sett opp serveren

Du trenger CA-ens offentlige nøkkel fra den som driver CA-en (for eksempel læreren). Legg den på serveren:

sudo nano /etc/ssh/lab_user_ca.pub

Bestem hvilke principals som får logge inn som brukeren user:

sudo mkdir -p /etc/ssh/auth_principals
echo admin | sudo tee /etc/ssh/auth_principals/user

Fortell SSH-tjenesten om CA-en:

sudo nano /etc/ssh/sshd_config.d/10-lab-ca.conf
TrustedUserCAKeys /etc/ssh/lab_user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

%u byttes ut med brukernavnet det logges inn som. Kontroller og last inn med sudo sshd -t og sudo systemctl reload ssh.

Logg inn med sertifikatet

Sertifikatet ligger ved siden av den private nøkkelen og slutter på -cert.pub. Se hva det inneholder:

ssh-keygen -L -f ~/.ssh/id_ed25519-cert.pub

Se etter Principals, Valid og Signing CA. Legg sertifikatet inn i ~/.ssh/config:

Host debian-vm
    HostName SERVER-IP
    User user
    IdentityFile ~/.ssh/id_ed25519
    CertificateFile ~/.ssh/id_ed25519-cert.pub

Nå logger du inn med ssh debian-vm uten at nøkkelen din ligger i authorized_keys på serveren.

Hvordan CA-en signerer (for den som driver CA-en)

ssh-keygen -t ed25519 -f lab_user_ca                  # lag CA-nøkkelen én gang, oppbevar den trygt
ssh-keygen -s lab_user_ca -I elev@skolen -n admin -V +52w id_ed25519.pub

-n er principals, -V er gyldighetstid og -I er en ID som vises i loggene på serveren. Den private CA-nøkkelen gir tilgang til alle serverne som stoler på den, så den skal aldri ligge på en server eller deles.

Hvis noe går galt

  1. Du er låst ute: Logg inn i Proxmox-konsollen, slett filen du laget i /etc/ssh/sshd_config.d/ og kjør sudo systemctl reload ssh.
  2. sshd -t gir feilmelding: Meldingen viser fil og linjenummer. Rett skrivefeilen før du laster inn.
  3. Sertifikatet blir ikke godtatt: Sjekk at principal i sertifikatet (ssh-keygen -L) står i /etc/ssh/auth_principals/user, og at sertifikatet ikke er utløpt. På serveren viser sudo journalctl -u ssh -n 20 hvorfor innloggingen ble avvist.

Viktige begreper

Begrep Forklaring
Herding Å fjerne innstillinger og tjenester en angriper kan utnytte
sshd_config.d Mappe med egne innstillingsfiler for SSH-tjenesten
CA Sertifikatutsteder som signerer nøkler
Principal Navn i sertifikatet som bestemmer hvilke brukere det gir tilgang til
SSH-sertifikat Offentlig nøkkel signert av en CA, med principals og gyldighetstid

Kontroller

  • ssh root@SERVER-IP blir avvist.
  • Innlogging med passord over SSH blir avvist.
  • Du kan forklare hvorfor du testet i et nytt vindu før du lukket det gamle.
  • Fordypning: du kan forklare hvorfor en CA er enklere enn authorized_keys på mange servere.

Kilde: OpenSSH – sshd_config.