Salasanakirjautuminen SSH:n yli on tavallisen palvelimen suurin avoin pinta. Sitä vastaan sekä Fail2ban että kaikki kynnykset ovat voimattomia: tuhat osoitetta yhdellä yrityksellä tunnissa ei saavuta koskaan mitään rajaa, ja ne jatkavat täsmälleen niin kauan kuin arvaaminen on ylipäätään mahdollista. Avaimet poistavat itse mahdollisuuden, ja se on koko koventamislistan ainoa asetus, joka muuttaa tilanteen perusteellisesti.

Pelottavaa on vain yksi: kytkeä salasana pois ja jäädä ulkopuolelle. Alla järjestys, jossa se ei ole mahdollista.

Avain

Luodaan omalla koneella, ei palvelimella:

ssh-keygen -t ed25519 -C "työläppäri"

ed25519 RSA:n sijaan — lyhyempi, nopeampi ja ilman kysymyksiä avaimen pituudesta. RSA:ta tarvitaan vain, jos on määrä ottaa yhteys johonkin hyvin vanhaan; silloin -t rsa -b 4096.

Salalause avaimelle kannattaa asettaa: avaintiedosto voidaan varastaa läppäriltä, ja ilman salalausetta se toimii heti. Sitä ei tarvitse kirjoittaa joka kerta — siitä huolehtii ssh-agent, ja macOS:ssä sekä useimmissa työpöytä-Linuxeissa se on jo käynnissä.

Kopiointi palvelimelle yhdellä komennolla, kun salasana vielä toimii:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@203.0.113.25

Jos ssh-copy-id ei ole käytettävissä, .pub-tiedoston sisältö lisätään rivinä tiedostoon ~/.ssh/authorized_keys palvelimella. Oikeudet ovat tärkeitä: hakemiston .ssh pitää olla 700, tiedoston 600 ja omistajan käyttäjä itse. Muilla oikeuksilla sshd kieltäytyy hiljaa lukemasta tiedostoa, ja se on yleisin syy siihen että ”avain ei toimi”.

Tarkistus, joka ratkaisee kaiken

Ennen kuin kytket mitään pois — avaa toinen yhteys sulkematta ensimmäistä:

ssh -o PasswordAuthentication=no user@203.0.113.25

Valitsin kieltää asiakasta palaamasta salasanaan — jos kirjautuminen onnistui, se tapahtui siis avaimella. Ennen kuin tuo komento menee läpi, seuraavaan vaiheeseen ei saa siirtyä. Eikä ensimmäistä yhteyttä suljeta ennen kuin kaikki on valmista: sen kautta korjataan kaikki, mitä voi rikkoa.

Kytkeminen pois ja yksi ei-ilmeinen ansa

Asetukset laitetaan omaan tiedostoon, jottei paketin päivitys ylikirjoittaisi niitä. Mutta tiedoston nimellä on merkitystä:

sudo tee /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PasswordAuthentication no
PermitRootLogin no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LogLevel VERBOSE
EOF

Asia on niin, että OpenSSH käyttää parametrin ensimmäistä kohdattua arvoa, ei viimeistä, kuten lähes kaikkialla muualla. Hakemiston sshd_config.d tiedostot luetaan aakkosjärjestyksessä, ja Ubuntun pilvikuvat laittavat sinne tiedoston 50-cloud-init.conf, jossa usein lukee PasswordAuthentication yes. Tiedostosi numerolla 90 ei silloin tee mitään: asetus näyttää tehdyltä, mutta salasana toimii yhä. Siitä numero 10 — se luetaan aiemmin.

Mitä lopputulokseksi todella tuli, ei tarvitse arvailla:

sudo sshd -T | grep -Ei 'passwordauth|permitrootlogin|pubkeyauth'

Komento tulostaa voimassa olevan asetuskokonaisuuden kaikkien sisällytysten jälkeen. Luota siihen äläkä tiedostojen sisältöön.

Sitten syntaksin tarkistus ja palvelun pehmeä uudelleenlataus:

sudo sshd -t && sudo systemctl reload ssh

sshd -t on pakollinen: kirjoitusvirhe asetuksissa restart-komennon yhteydessä jättää palvelun alas ja sinut ulkopuolelle. reload ei myöskään katkaise avoimia istuntoja.

Ubuntu 24.04: portti ei muutu siellä

Oma ansansa tuoreissa Ubuntuissa: sshd käynnistetään siellä systemd-socketin kautta. Rivi Port tiedostossa sshd_config ei tuossa tilassa tee mitään — kuunteleva osapuoli on socket, ei demoni. Jos vaihdat porttia, sitä pitää muokata:

sudo systemctl edit ssh.socket

ja määrittää ListenStream= (tyhjä arvo nollaa edellisen) uudella portilla. Oire, josta tämän tunnistaa: asetukset on muutettu, palvelu käynnistetty uudelleen, ja palvelin vastaa yhä porttiin 22.

Portin vaihdosta muuten: suojauksena se ei toimi — skannerit löytävät palvelun mistä tahansa portista minuuteissa. Ainoa vaikutus on, että lokeissa on hiljaisempaa, koska massa-arvailu kohdistuu vain porttiin 22. Se on kätevää, mutta älä sekoita sitä turvallisuuteen.

Kuka ylipäätään saa kirjautua

Hyödyllinen lisäys on nimenomainen lista:

AllowUsers deploy admin

Kaikki mitä ei ole lueteltu, torjutaan jo ennen avaimen tarkistusta. Se kattaa samalla tapauksen, jossa jokin paketti luo järjestelmäkäyttäjän komentotulkilla ja kotihakemistolla.

Varatie sisään

Yksi avain yhdellä läppärillä on yksittäinen vikapiste. Levy hajoaa, läppäri katoaa, ja palvelin muuttuu pysyvästi tavoittamattomaksi. Järkevä vähimmäistaso:

  • toinen avain toiselta laitteelta tiedostossa authorized_keys;
  • kopio yksityisestä avaimesta salasanojen hallintaohjelmassa tai salatulla muistitikulla;
  • testattu konsolipääsy palveluntarjoajalla — VNC tai sarjaportti. Testattu tarkoittaa, että olet kirjautunut sinne vähintään kerran, ei sitä että ”paneelissa on jossain nappi”.

Katso samalla, mitä tiedostossa authorized_keys jo on — sekä omalla käyttäjälläsi että rootilla. Vieras avain siellä selviää mistä tahansa salasanan vaihdosta ja pysyy toimivana pääsynä.

Jälkeenpäin

Salasanojen arvailu ei häviä minnekään, siitä tulee vain hyödytöntä: lokeihin jää tuhansia Failed password -rivejä, joista yksikään ei voi päättyä onnistumiseen. Sen sijaan kannattaa nyt katsoa onnistuneita kirjautumisia: mistä osoitteesta, millä käyttäjällä, mihin aikaan. Onnistunut avainkirjautuminen tuntemattomasta osoitteesta on paljon tärkeämpi tapahtuma kuin miljoona epäonnistunutta yritystä ja huomattavasti vaikeampi havaita yleisestä virrasta. Juuri tuon kuvan näyttää alla oleva esittelysivu.