SSH Kovettaminen Linuxissa (2026)

Johdanto: Miksi SSH:n kovettaminen on kriittistä vuonna 2026?

SSH on jokaisen Linux-ylläpitäjän päivittäinen työkalu — portti palvelimille, tuotantoympäristöihin ja kaikkeen kriittiseen infrastruktuuriin. Ja juuri siksi se on myös yksi hyökkääjien suosikkikohteista. Vuonna 2025 Linux-ytimestä paljastui 5 530 CVE-haavoittuvuutta, ja SSH-brute-force-hyökkäykset pyörivät edelleen täysillä automaattisissa hyökkäyksissä ympäri internetiä.

Mutta samaan aikaan kryptografian puolella on tapahtunut jotain merkittävää.

OpenSSH 10.0 (julkaistu huhtikuussa 2025) teki post-kvanttisalauksesta oletusasetuksen avaintenvaihdossa, ja OpenSSH 10.1 varoittaa aktiivisesti yhteyksistä, jotka eivät käytä kvanttiresistenttiä algoritmia. FIDO2-laitteistotunnisteet kuten YubiKey tarjoavat käytännössä murtamatonta todennusta. Sertifikaattipohjainen SSH-todennus taas skaalautuu suuriin ympäristöihin ilman avainten manuaalista kopiointia — ja tämä on iso juttu, jos olet koskaan joutunut hallinnoimaan kymmeniä palvelimia käsin.

Suomenkielisestä SSH-tietoturvamateriaalista puuttuu lähes kokonaan näiden modernien teknologioiden käsittely. Tässä oppaassa käymme läpi kaiken Ed25519-avaimista FIDO2-laitteistotunnisteisiin, post-kvanttisalauksesta kovennettuun sshd_config-konfiguraatioon ja SSH-auditoinnista sertifikaattipohjaiseen todennukseen. Kaikki esimerkit on testattu vuoden 2026 jakeluissa.

OpenSSH 10.0 ja post-kvanttisalaus: Uusi aikakausi

Miksi kvanttitietokoneet uhkaavat SSH:ta?

Kvanttitietokoneiden uhka perustuu niin sanottuun "tallenna nyt, pura myöhemmin" (store now, decrypt later) -strategiaan. Käytännössä tämä tarkoittaa, että vastustajat voivat tallentaa salattua SSH-liikennettä tänään ja purkaa sen tulevaisuudessa, kun kvanttitietokoneet ovat riittävän tehokkaita. Kuulostaa ehkä scifi:ltä, mutta asiantuntijat arvioivat kryptografisesti merkittävien kvanttitietokoneiden ilmestyvän 5–20 vuoden kuluessa — todennäköisimmin 2030-luvun puolivälissä.

Se on yllättävän lähellä.

OpenSSH:n post-kvantti-aikajana

OpenSSH on tarjonnut post-kvantti-avaintenvaihtoa oletuksena jo versiosta 9.0 (huhtikuu 2022) alkaen sntrup761x25519-sha512-algoritmilla. Kehitys on edennyt nopeasti sen jälkeen:

OpenSSH 9.9 — Lisäsi hybridin post-kvantti-avaintenvaihtoalgoritmin mlkem768x25519-sha256, joka perustuu NIST FIPS 203 -standardoituun ML-KEM-algoritmiin yhdistettynä X25519 ECDH:hon. DSA-tuki poistettiin käytöstä oletuksena.
OpenSSH 10.0 (huhtikuu 2025) — mlkem768x25519-sha256 asetettiin oletusavaintenvaihtoalgoritmiksi. DSA-tuki poistettiin kokonaan. Todennusvaihe eriytettiin uuteen sshd-auth-binääriin hyökkäyspinnan pienentämiseksi.
OpenSSH 10.1 — Varoittaa käyttäjää, kun yhteys ei käytä post-kvantti-avaintenvaihtoa. Varoituksen voi poistaa WarnWeakCrypto-asetuksella.

Post-kvanttisalauksen tarkistaminen

Näin varmistat, että SSH-yhteytesi käyttävät post-kvantti-algoritmia:

# Tarkista OpenSSH-versio
ssh -V

# Testaa yhteys yksityiskohtaisella lokituksella
ssh -vvv käyttäjä@palvelin 2>&1 | grep "kex:"

# Odotettu tulos OpenSSH 10.0+:
# kex: algorithm: mlkem768x25519-sha256

Jos palvelin ei tue post-kvanttialgoritmeja, näet varoituksen OpenSSH 10.1:ssä. Tämä kertoo selkeästi, että palvelimen SSH-konfiguraatio kaipaa päivitystä.

Ed25519-avaimet: Moderni standardi

Miksi Ed25519 eikä RSA?

Ed25519 on vuonna 2026 ehdottomasti suositeltu SSH-avaintyyppi. Rehellisesti sanottuna, RSA:lle ei ole enää juurikaan syytä uusissa asennuksissa. Ed25519 tarjoaa merkittäviä etuja:

Kompakti koko — 256-bittinen avain vs. RSA:n 3072–4096 bittiä, mutta yhtä turvallinen
Nopeampi — Avaimen luonti, allekirjoitus ja varmennus ovat huomattavasti nopeampia
Yksinkertaisempi toteutus — Vähemmän mahdollisuuksia sivukanavahyökkäyksille
Deterministiset allekirjoitukset — Ei tarvetta satunnaislukugeneraattorille allekirjoitushetkellä, mikä eliminoi kokonaisen hyökkäysvektorin

Ed25519-avaimen luominen

# Luo Ed25519-avain vahvalla salasanalla
ssh-keygen -t ed25519 -C "nimi@organisaatio-$(date +%Y%m)"

# Parametrit:
# -t ed25519    = Avaintyyppi
# -C "kommentti" = Tunnistava kommentti (sisältää päivämäärän kierrätystä varten)

# Avain tallentuu oletuksena:
# ~/.ssh/id_ed25519      (yksityinen avain)
# ~/.ssh/id_ed25519.pub  (julkinen avain)

Avaimen siirtäminen palvelimelle

# Kopioi julkinen avain palvelimelle
ssh-copy-id -i ~/.ssh/id_ed25519.pub käyttäjä@palvelin

# Tai manuaalisesti:
cat ~/.ssh/id_ed25519.pub | ssh käyttäjä@palvelin "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Avainten hallinta ja kierrätys

Hyvä käytäntö on kierrättää SSH-avaimet vuosittain ja sisällyttää luontipäivämäärä avaimen kommenttiin. Näin vanhat avaimet on helppo tunnistaa. Vanhentuneet avaimet tulee tietysti poistaa authorized_keys-tiedostosta:

# Listaa palvelimen authorized_keys-tiedoston avaimet
ssh käyttäjä@palvelin "cat ~/.ssh/authorized_keys"

# Poista vanha avain (korvaa VANHA_AVAIN avaimen kommentilla)
ssh käyttäjä@palvelin "sed -i '/VANHA_AVAIN/d' ~/.ssh/authorized_keys"

FIDO2-laitteistotunnisteet: Käytännössä murtamaton SSH-todennus

Miksi FIDO2 on ylivoimainen?

Tässä kohtaa mennään todella mielenkiintoisiin vesiin. FIDO2-turvalaitteet kuten YubiKey tarjoavat SSH-todennuksen korkeimman turvallisuustason. Yksityinen avainmateriaali ei koskaan poistu laitteistosta — toisin kuin ohjelmistoavaimissa, joissa yksityinen avain on levyllä (vaikkakin salattuna). Jokainen todennusoperaatio vaatii fyysisen kosketuksen laitteeseen, ja valinnaisesti myös PIN-koodin tai biometrisen vahvistuksen.

Mitä tämä käytännössä tarkoittaa? Vaikka työasemasi olisi täysin murrettu haittaohjelmalla, hyökkääjä ei voi käyttää SSH-avaimiasi ilman fyysistä pääsyä YubiKey-laitteeseen. Se on aika rauhoittava ajatus.

Vaatimukset

YubiKey 5 -sarja, YubiKey Bio tai Security Key by Yubico (FIDO2-tuella)
OpenSSH 8.2+ (FIDO2-tuki), suositeltavaa 8.3+ (verify-required-tuki)
YubiKey Manager FIDO2 PIN:n asettamiseen
YubiKey-laiteohjelmisto vähintään versio 5.2.3

FIDO2 PIN:n asettaminen

# Asenna YubiKey Manager
# Debian/Ubuntu:
sudo apt install yubikey-manager

# Fedora/RHEL:
sudo dnf install yubikey-manager

# Aseta FIDO2 PIN:
ykman fido access change-pin

FIDO2-avainten luominen

On kaksi avaintyyppiä, ja ero kannattaa ymmärtää: resident (tallennettu YubiKeylle, siirrettävissä koneiden välillä) ja non-resident (viitetiedosto levyllä, mutta avainmateriaali silti YubiKeyssä).

# Turvallisin vaihtoehto: Resident-avain PIN-vahvistuksella
ssh-keygen -t ed25519-sk -O resident -O verify-required -C "fido2-$(hostname)-$(date +%Y%m)"

# -t ed25519-sk     = FIDO2-suojattu Ed25519-avain
# -O resident        = Tallennetaan YubiKeylle (siirrettävä)
# -O verify-required = Vaatii PIN:n jokaisella käyttökerralla

# Non-resident vaihtoehto (viitetiedosto levyllä):
ssh-keygen -t ed25519-sk -C "fido2-$(hostname)-$(date +%Y%m)"

Resident-avaimen käyttäminen uudella koneella

# Hae resident-avaimet YubiKeystä uudelle koneelle
ssh-keygen -K

# Tämä luo:
# id_ed25519_sk_rk      (viitetiedosto)
# id_ed25519_sk_rk.pub  (julkinen avain)

Varmuuskopiointistrategia

Osta kaksi YubiKeytä. Ihan oikeasti — tämä on tärkein yksittäinen neuvo FIDO2-avainten kanssa. Luo molemmille FIDO2-avaimet ja lisää molempien julkiset avaimet palvelimien authorized_keys-tiedostoihin. Jos pääavain katoaa tai rikkoutuu, varaavain on välittömästi käytettävissä. Ilman varaavainta olet aika pahassa paikassa.

Kovennettu sshd_config: Tuotantovalmis konfiguraatio

Konfiguraatiotiedoston sijainti

SSH-palvelimen asetukset löytyvät tiedostosta /etc/ssh/sshd_config. Moderneissa jakeluissa suositellaan lisäkonfiguraatioiden sijoittamista /etc/ssh/sshd_config.d/-hakemistoon, jotta oletuskonfiguraatio ei ylikirjoitu päivityksissä:

# Varmista, että pääkonfiguraatio sisältää:
Include /etc/ssh/sshd_config.d/*.conf

Täydellinen kovennettu konfiguraatio

Nyt päästään asiaan. Luo tiedosto /etc/ssh/sshd_config.d/99-hardening.conf:

# === SSH-PALVELIMEN KOVENNETTU KONFIGURAATIO (2026) ===
# Yhteensopiva: OpenSSH 9.9+ / Ubuntu 24.04+ / RHEL 9+ / Debian 12+

# --- Protokolla ja portti ---
Port 22
# Harkitse portin vaihtamista (esim. 2222) automaattisten skannerien torjumiseksi

# --- Todennus ---
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no
MaxAuthTries 3
PubkeyAuthentication yes

# Salli vain tietyt käyttäjät/ryhmät
# AllowUsers deployer admin
# AllowGroups sshusers

# --- Avaintyypit ja algoritmit ---
# Ed25519 ja RSA (vähintään 3072-bittinen)
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
RequiredRSASize 3072

# Avaintenvaihtoalgoritmit (post-kvantti ensin)
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512

# Salaukset (vahvimmat ensin)
Ciphers [email protected],[email protected],[email protected]

# MAC-algoritmit (Encrypt-then-MAC)
MACs [email protected],[email protected],[email protected]

# --- Istuntoasetukset ---
ClientAliveInterval 300
ClientAliveCountMax 2
LoginGraceTime 30
MaxSessions 3
MaxStartups 10:30:60

# --- Turvallisuusasetukset ---
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no
GatewayPorts no
DisableForwarding yes

# --- Lokitus ---
LogLevel VERBOSE
SyslogFacility AUTH

# --- Banneri ---
Banner /etc/ssh/banner.txt

Konfiguraation validointi ja käyttöönotto

# Validoi konfiguraatio ennen käyttöönottoa
sudo sshd -t

# Jos ei virheitä, käynnistä SSH uudelleen
sudo systemctl restart sshd

# Tarkista yksityiskohtainen konfiguraatio
sudo sshd -T | head -50

# TÄRKEÄÄ: Pidä toinen SSH-istunto auki testatessasi!
# Jos konfiguraatiossa on virhe, et lukitse itseäsi ulos.

Kriittisten asetusten selitykset

Käydään läpi tärkeimmät koventamisasetukset ja miksi ne ovat merkityksellisiä:

PermitRootLogin no — Estää suoran root-kirjautumisen. Käyttäjien tulee kirjautua omalla tilillään ja käyttää sudo-komentoa. Tämä on yksi niistä asetuksista, joita ei pitäisi koskaan jättää pois.
PasswordAuthentication no — Pakottaa avainpohjaisen todennuksen. Eliminoi käytännössä 99 % automaattisista hyökkäyksistä.
MaxAuthTries 3 — Rajoittaa todennusyritykset kolmeen per yhteys, mikä hidastaa brute-force-hyökkäyksiä merkittävästi.
RequiredRSASize 3072 — Hylkää alle 3072-bittiset RSA-avaimet, jotka eivät enää täytä nykyisiä turvallisuusvaatimuksia.
DisableForwarding yes — Estää porttiohjauksen, agentin välityksen ja tunneloinnin yhdellä asetuksella. Kätevää.
LogLevel VERBOSE — Kirjaa yksityiskohtaiset todennustapahtumat. Ilman kunnollista lokitusta tietoturva-auditointi on mahdotonta.
MaxStartups 10:30:60 — Rajoittaa samanaikaisia todentamattomia yhteyksiä: 10 sallittu, sen jälkeen 30 % todennäköisyydellä pudotus, maksimi 60. Tämä suojaa palvelunestohyökkäyksiltä.

SSH-sertifikaattipohjainen todennus: Skaalautuva ratkaisu

Miksi sertifikaatit avainten sijaan?

Perinteisessä SSH-avaintodennuksessa jokaisen käyttäjän julkinen avain on kopioitava jokaiselle palvelimelle. Tämä ei skaalaudu — kymmenien käyttäjien ja satojen palvelimien ympäristössä avainten hallinta muuttuu nopeasti painajaiseksi. Olen itse nähnyt ympäristöjä, joissa authorized_keys-tiedostot olivat satoja rivejä pitkiä ja kukaan ei tiennyt, mitkä avaimet olivat edelleen käytössä.

SSH-sertifikaatit ratkaisevat tämän elegantisti:

Keskitetty hallinta — Yksi CA (Certificate Authority) allekirjoittaa käyttäjien avaimet
Aikarajoitettu pääsy — Sertifikaateille voi asettaa voimassaoloajan (esim. 8 tuntia, 1 viikko)
Ei avainten kopiointia — Palvelimet luottavat CA:n julkiseen avaimeen, eivät yksittäisiin käyttäjäavaimiin
Automaattinen peruutus — Vanhenevat sertifikaatit eivät vaadi manuaalista poistamista

Vaihe 1: Sertifikaattiviranomaisen (CA) luominen

# Luo erillinen CA käyttäjäsertifikaateille
ssh-keygen -t ed25519 -f /etc/ssh/user_ca -C "SSH User CA"

# Ja erillinen CA palvelinsertifikaateille
ssh-keygen -t ed25519 -f /etc/ssh/host_ca -C "SSH Host CA"

# TÄRKEÄÄ: Erillisten CA-avainten käyttö on kriittistä.
# Jos yksi CA:n yksityinen avain vuotaa, vain toisen tyyppiset
# sertifikaatit on uusittava.

Vaihe 2: Käyttäjän avaimen allekirjoittaminen

# Allekirjoita käyttäjän julkinen avain (voimassa 30 päivää)
ssh-keygen -s /etc/ssh/user_ca   -I "matti.meikalainen@yritys"   -n matti   -V +30d   /home/matti/.ssh/id_ed25519.pub

# Parametrit:
# -s = Allekirjoitusavain (CA:n yksityinen avain)
# -I = Sertifikaatin tunniste (lokitusta varten)
# -n = Sallitut käyttäjätunnukset (principals)
# -V = Voimassaoloaika (+30d = 30 päivää)

# Tulos: /home/matti/.ssh/id_ed25519-cert.pub

# Tarkista sertifikaatin tiedot:
ssh-keygen -L -f /home/matti/.ssh/id_ed25519-cert.pub

Vaihe 3: Palvelimen konfigurointi luottamaan CA:han

# Kopioi CA:n julkinen avain palvelimelle
sudo cp user_ca.pub /etc/ssh/user_ca.pub

# Lisää sshd_config-tiedostoon:
echo "TrustedUserCAKeys /etc/ssh/user_ca.pub" | sudo tee -a /etc/ssh/sshd_config.d/99-certificates.conf

# Käynnistä SSH uudelleen
sudo systemctl restart sshd

Nyt kaikki käyttäjät, joiden avain on allekirjoitettu tällä CA:lla, voivat kirjautua palvelimelle — ilman että heidän yksittäisiä avaimiaan on lisätty authorized_keys-tiedostoon. Aika näppärää.

Lyhytikäiset sertifikaatit tuotantoympäristöissä

# Myönnä sertifikaatti, joka on voimassa vain 8 tuntia (yksi työpäivä)
ssh-keygen -s /etc/ssh/user_ca   -I "matti-tuotanto-$(date +%Y%m%d)"   -n deployer   -V +8h   /home/matti/.ssh/id_ed25519.pub

# Erittäin lyhyille pääsyille (esim. hätätilanne):
# -V +60m  = 60 minuuttia

SSH-auditointi ssh-audit-työkalulla

Miksi auditoida SSH-konfiguraatio?

OpenSSH:n oletuskonfiguraatio priorisoi yhteensopivuutta turvallisuuden kustannuksella. Tämä on ymmärrettävää — OpenSSH:n pitää toimia monenlaisissa ympäristöissä — mutta tarkoittaa myös sitä, että mukana saattaa olla vanhentuneita salausalgoritmeja ja tunnettuja haavoittuvuuksia sisältäviä asetuksia. ssh-audit on erinomainen avoimen lähdekoodin työkalu, joka analysoi SSH-palvelimen ja -asiakkaan konfiguraation ja antaa konkreettiset parannusehdotukset.

ssh-auditin asennus ja käyttö

# Asennus pip:llä
pip install ssh-audit

# Tai Snapilla
sudo snap install ssh-audit

# Tai Dockerilla
docker run -it --rm ghcr.io/jtesta/ssh-audit palvelin.example.com

# Peruskäyttö:
ssh-audit palvelin.example.com

# Tarkempi skannaus tiettyyn porttiin:
ssh-audit -p 2222 palvelin.example.com

# Asiakaspuolen auditointi:
ssh-audit -c

Tulosten tulkinta

ssh-audit antaa kokonaispistemäärän (0–100) ja merkitsee algoritmit värikoodeilla:

Vihreä — Turvallinen algoritmi, suositeltu käyttöön
Keltainen — Hyväksyttävä, mutta vahvempia vaihtoehtoja on saatavilla
Punainen — Haavoittuva tai heikko algoritmi, poistettava välittömästi

Huomionarvoinen yksityiskohta: Maksimipisteet ovat käytännössä 95 % johtuen tunnetusta OpenSSH-ongelmasta, jossa 2048-bittisiä DH-moduleja saatetaan käyttää rajoitetuissa tilanteissa. Älä siis huolehdi, jos et saa täysiä pisteitä.

Koventamisoppaat jakeluittain

ssh-audit tarjoaa valmiit koventamisoppaat eri jakeluille osoitteessa sshaudit.com/hardening_guides.html. Oppaat kattavat muun muassa Ubuntu 24.04 LTS:n, Debian 12/13:n ja Red Hat Enterprise Linux 9:n. Kannattaa ehdottomasti vilkaista omaa jakelua vastaava opas.

Brute-force-suojaus: Fail2Ban ja nftables yhdessä

Fail2Ban SSH-suodattimella

Fail2Ban valvoo todennuslokeja ja estää automaattisesti IP-osoitteet, jotka ylittävät epäonnistuneiden kirjautumisyritysten rajan. Se on eräänlainen välttämättömyys jokaiselle julkiseen verkkoon näkyvälle SSH-palvelimelle. Asenna ja konfiguroi se näin:

# Asennus
sudo apt install fail2ban   # Debian/Ubuntu
sudo dnf install fail2ban   # RHEL/Fedora

# Luo paikallinen konfiguraatio
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Muokkaa /etc/fail2ban/jail.local-tiedostoa:

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600
banaction = nftables-multiport

# Käynnistä Fail2Ban
sudo systemctl enable --now fail2ban

# Tarkista Fail2Banin tila
sudo fail2ban-client status sshd

# Vapauta estetty IP tarvittaessa
sudo fail2ban-client set sshd unbanip 192.168.1.100

nftables-nopeusrajoitus täydentävänä suojana

Fail2Banin lisäksi voit käyttää nftablesia kernel-tason nopeusrajoitukseen. Tämä on erityisen tehokasta, koska se toimii suoraan Netfilter-kehyksessä ilman käyttäjätilan prosessointia:

# nftables-sääntö SSH-yhteysyritysten rajoittamiseen
table inet ssh_ratelimit {
    chain input {
        type filter hook input priority -1; policy accept;
        tcp dport 22 ct state new limit rate 5/minute burst 3 packets accept
        tcp dport 22 ct state new drop
    }
}

Tarkemman nftables-konfiguraation dynaamisilla joukoilla löydät artikkelistamme nftables-palomuurin koventamisesta, jossa käsittelimme SSH-brute-force-suojauksen toteutuksen ilman Fail2Bania.

SSH-turvallisuuden tarkistuslista

Lopuksi kootaan kaikki yhteen. Käytä tätä tarkistuslistaa varmistaaksesi, että SSH-konfiguraatiosi on vuoden 2026 tasolla:

Kriittinen: Ed25519- tai FIDO2-avaimet käytössä
Kriittinen: Salasanatodennus poistettu käytöstä
Kriittinen: Root-kirjautuminen estetty
Korkea: Post-kvantti-avaintenvaihto varmistettu (OpenSSH 10.0+)
Korkea: Fail2Ban tai vastaava brute-force-suojaus käytössä
Korkea: Heikot algoritmit poistettu (ssh-audit-tarkistus)
Keskitaso: Sertifikaattipohjainen todennus suurissa ympäristöissä
Keskitaso: SSH-avainten vuosittainen kierrätys
Keskitaso: Lokien keskitetty valvonta
Valinnainen: Oletusportin vaihto (security by obscurity, mutta auttaa automaattisten bottien kanssa)

Usein kysytyt kysymykset (FAQ)

Onko SSH-portin vaihtaminen todella hyödyllistä?

Portin vaihtaminen on turvallisuutta hämäryydellä (security by obscurity), eikä se estä päättäväistä hyökkääjää löytämästä oikeaa porttia. Se kuitenkin vähentää merkittävästi automaattisten bottien ja skannausten määrää, mikä pienentää lokien kohinaa ja vähentää kuormitusta. Näkisin sen eräänlaisena lisäsuojauksena — ei ensisijaisena turvatoimenpiteenä, mutta ei myöskään turhana.

Tarvitaanko Fail2Bania, jos salasanatodennus on jo poistettu käytöstä?

Kyllä, Fail2Ban on hyödyllinen myös avainpohjaisessa todennuksessa. Se estää IP-osoitteet, jotka yrittävät toistuvasti yhteyksiä — tämä vähentää palvelimen kuormitusta, pienentää lokien kohinaa ja suojaa mahdollisten avaintenvaihtoon liittyvien haavoittuvuuksien hyödyntämistä vastaan. Ja käytännössä Fail2Ban suojaa myös muitakin palvelimella pyöriviä palveluita, joten se kannattaa joka tapauksessa.

Kuinka usein SSH-avaimet tulisi vaihtaa?

Hyvä nyrkkisääntö on kierrättää SSH-avaimet vuosittain. Sertifikaattipohjaisessa ympäristössä sertifikaatit voivat olla lyhytikäisiä (päivistä viikkoihin), mikä automatisoi kierrätyksen kätevästi. Jos epäilet avaimen vuotaneen, vaihda se heti ja poista vanha avain kaikista palvelimista — tässä ei kannata odotella.

Mikä ero on Ed25519-avaimella ja FIDO2-avaimella?

Tavallinen Ed25519-avain tallennetaan levylle ohjelmistona — se on suojattu salasanalla, mutta haittaohjelma voi potentiaalisesti varastaa sen. FIDO2-avain (ed25519-sk) käyttää laitteistoturvalaitetta kuten YubiKeytä: yksityinen avainmateriaali ei koskaan poistu laitteesta, ja jokainen käyttö vaatii fyysisen kosketuksen. FIDO2 on selvästi turvallisempi, mutta vaatii erillisen laitteen ja pienen alkuinvestoinnin.

Tukeeko OpenSSH jo post-kvantti-todennusavaimia?

Toistaiseksi OpenSSH:n post-kvanttituki kattaa vain avaintenvaihdon (key exchange), ei todennusavaimia. Ed25519- ja RSA-avaimet eivät siis ole vielä kvanttiresistenttejä. OpenSSH-projekti seuraa NIST:n post-kvantti-allekirjoitusstandardien (ML-DSA, aiemmin CRYSTALS-Dilithium) kehitystä, ja tuki on odotettavissa tulevissa versioissa. Kannattaa pysyä kuulolla.