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
- Du er låst ute: Logg inn i Proxmox-konsollen, slett filen du laget i
/etc/ssh/sshd_config.d/og kjørsudo systemctl reload ssh. sshd -tgir feilmelding: Meldingen viser fil og linjenummer. Rett skrivefeilen før du laster inn.- 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 visersudo journalctl -u ssh -n 20hvorfor 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-IPblir 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_keyspå mange servere.
Kilde: OpenSSH – sshd_config.