Web-palvelimen liikenteen salaaminen

Asennetaan Apache ja mod_ssl -laajennusosa.

$ sudo yum install httpd mod_ssl

Kopioidaan avaimet käyttöjärjestelmän vakiohakemistoihin. (Huom! Älä siirrä varmennetiedostoja kopioinnin sijaan, koska silloin ne eivät saa tarvittavia SELinux-labeleita.)

$ sudo cp markonnakkijadata.fi.crt /etc/pki/tls/certs/
$ sudo cp markonnakkijadata.fi.key /etc/pki/tls/private/

Tämän jälkeen konfiguroidaan palvelimen varmenne ja avaimet (tiedostossa /etc/httpd/conf.d/ssl.conf).

SSLCertificateFile /etc/pki/tls/certs/markonnakkijadata.fi.crt
SSLCertificateKeyFile /etc/pki/tls/private/markonnakkijadata.fi.key

Jos yksityinen avain (SSLCertificateFile) on suojattu salasanalla, httpd kysyy käynnistyessään salasanan konsolista. Vaihtoehtoisesti salasana voidaan pyytää ohjelmalta, joka on valittavissa asetuksella SSLPassPhraseDialog. Lisäksi on mahdollista ottaa käyttöön laitteistopohjainen turvallisuusmoduuli (HSM-laite) käyttäen asetusta _SSLCryptoDevice _ja laitteistokohtaisia muita asetuksia.

Lisätään samaan asetustiedostoon HSTS (HTTP Strict Transport Security, RFC 6797), joka opastaa selaimia olemaan ottamatta salaamattomia yhteyksiä palvelimeen. Tämän nykyään yleisesti suositeltu käytäntö.

Header always set Strict-Transport-Security "max-age=15768000"

Valitaan kohtalaisen turvallinen yhdistelmä sallittyja salausprotokollia ja -algoritmeja ja lisätään se jälleen asetustiedostoon. Useimmat ohjelmistot tukevat yhteensopivuussyistä myös vanhempia protokollien versioita (TLS 1.0 & 1.1) ja salaualgoritmeja (md4, 3DES, jne.), joiden turvallisuus on nykyään kyseenalaista. Niiden poistaminen käytöstä on suositeltavaa, ellei niiden käytölle löydy erityisiä syitä.

Asetuksien valitsemiseen voi käyttää esim. Mozilla SSL Configuration Generator -työkalua. Esimerkin asetukset eivät toimi Firefox 27, Chrome 30, IE 11, Edge, Opera 17, Safari 9, Android 5.0 ja Java 8 vanhemmilla ohjelmistoilla.

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite          ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLHonorCipherOrder     on
SSLCompression          off

Jos varmentaja käyttää, käynnistetään OCSP stapling. Tämä selviää tarkastelemalla varmentajien varmenteita - jos niissä näkyy OCSP-palvelun osoitteet, käyttö on suositeltavaa. OCSP staping -tekniikkaa käytettäessä web-palvelin yrittää antaa pyyntöjen yhteydessä selaimille tiedon varmenteiden sulkulistauksen tilanteesta, jotta selaimien ei tarvitsisi erikseen käydä suorittamassa tarkastusta.

# OCSP Stapling, toimii httpd jälkeen
# Asetus ei toimi VirtualHostin sisällä
SSLUseStapling          on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache        shmcb:/var/run/ocsp(128000)

Huom! Web-palvelin yrittää OCSP:ä käytettäessä ottaa yhteyksiä varmentajien OCSP-palveluihin noutaakseen tiedot. Useimmissa ympäristöissä tämä vaatii palomuurien avaamisen web-palvelimelta ulospäin tarvittaviin osoitteisiin, jotka ovat varmentajakohtaisia ja löytyvät varmentajien varmenteista.

Käynnistetään web-palvelin ja asetetaan se käynnistymään automaattisesti.

$ sudo systemctl start httpd
$ sudo systemctl enable httpd

Sallitaan liikenne palvelimen https-porttiin (443/TCP).

sudo firewall-cmd --permanent --zone=public --add-service=https
sudo firewall-cmd --reload

Testataan palvelun toimivuus. HTTPS:n pitäisi toimia palvelussa, minkä erottaa mm. vihreän lukon kuvasta selaimen osoiterivin vieressä.

Varmennepohjainen tunnistautuminen

Rakennetaan web-palveluun varmennepohjainen tunnistautuminen. Esimerkissä käytetään tiedostovarmenteita, mikä eroaa toimikorteista (virkakortit, HST-kortti) tai mobiilivarmenteista vain käytettyjen varmenteiden osalta.

Kopioidaan varmententajan/varmentajien varmenteet käyttöjärjestelmän vakiohakemistoihin. Tiedoston tulee sisältää kaikki tunnistautumiseen hyväksyttyjen varmenteiden varmentajien varmenteet, juurivarmenteeseen asti. Web-palvelin antaa asiakkaille yhteyden salausta muodostettaessa selaimelle listan varmentajista, joiden tuottamat varmenteet kelpaavat tunnistautumiseen. Asiakkailla saattaa olla käytettävissä useita varmenteita, joten tieto tarvitaan oikean valitsemiseksi. Lisäksi varmenteita käytetään asiakkaan todentamisessa.

$ sudo cp markonnakkijaCA.fi.crt /etc/pki/tls/certs

Tämän jälkeen kytketään selainpohjainentunnistautuminen päälle. Asetus SSLCACertificate kertoo web-palvelimelle hyväksyttävien varmentajien varmenteet. SSLVerifyClient pakottaa tunnistautumisen tai käyttäjälle annetaan (varsin tyly, kuten myöhemmin huomataan) virheilmoitus. SSLVerifyDepth kertoo web-palvelimelle kuinka pitkälle varmenteen varmennehierarkiasta etsitään hyväksyttäviä varmentajia. 0 tarkoittaisi itse-allekirjoitettuja varmenteita, 1 suoraan varmentajan allekirjoittamia, 2 joko varmentajan tai välivarmentajan allekirjoittamia, jne.

# /etc/httpd/conf.d/ssl.conf
SSLCACertificateFile /etc/pki/tls/certs/markonnakkijaCA.fi.crt
SSLVerifyClient require
# Useimmiten 0-2, riippuen käyttötarkoituksesta
SSLVerifyDepth  10

Tämän jälkeen uudelleenkäynnistetään web-palvelin.

$ sudo systemctl restart httpd

Testataan palvelun toimivuus. Jos käyttäjällä ei ole tarjota palvelimelle varmennetta, tietoliikenteen salauksen kättely epäonnistuu ja käyttäjä saa varsin ruman virheilmoituksen.Käyttäjä voi saada varmenteen montaa kautta (esim. toimikortista tai tiedostovarmenteena). Kun yhteensopiva varmenne näkyy selaimen asetuksissa, varmennepohjainen tunnistautuminen voi toimia.Yritettäessä testata palvelua uudestaan käyttäjältä kysytään mitä varmennetta web-palvelulle tarjotaan. Eri ympäristöissä kysely saattaa näyttää erilaiselta tai saattaa puuttua kokonaan (esim. DigiSign saattaa toimia käyttäjän puolesta).ddf

Tämän jälkeen palvelu vastaa normaalisti, eikä käyttäjä erota tunnistautuneensa palveluun.

Tunnistautumistiedon välittäminen edelleen

Apache httpd osaa yhdistää syntyneen tunnistautumistiedon esim. käyttäjähakemistoista (LDAP) tuleviin käyttäjätietoihin ja rajoittaa pyyntöjä resursseihin ryhmäjäsenyyksiin perustuen. Web-palvelinta käytetään kuitenkin harvoin siten, koska se on haastavaa ja toisaalta hieman turhaakin.

Useimmat web-palvelimet välittävät asiakkaiden pyynnöt taustalla oleville sovelluspalvelimille. Tieto varmennepohjaisesta tunnistautumisesta syntyy TLS-yhteyden muodostavassa palvelinkomponentissa (web-palvelin, kuormantasain, tms.), joten se täytyy välittää sovelluksille. Useimmat sovellukset pystyvät tekemään tiedon perusteella tarvittavat käyttövaltuuksien tarkastukset normaalia web-palvelinta tehokkaammin ja helpommin.

Tietojen välittämiseksi taustapalveluihin kytketään päälle TLS-kättelyn tietojen julkaiseminen pyyntökohtaisiin muuttujiin (/etc/httpd/conf.d/ssl.conf). Tämän jälkeen valitaan edelleen välitettävät varmenteiden tiedot. Muuttujat kannattaa aina tyhjentää ennen asettamista, koska joissakin harvinaisissa vikatilanteissa asettaminen epäonnistuu, jolloin asiakkaalta tullut versio saattaa lähteä taustapalveluun mahdollistaen tietojen väärentämisen.

# Julkaistaan muuttujat
SSLOptions +ExportCertData
RequestHeader set TLS_CLIENT_CERT_CN ""
# DN:stä CN-osio. 
RequestHeader set TLS_CLIENT_CERT_CN "%{SSL_CLIENT_S_DN_CN}s"

Saatavilla olevilla muuttujilla on vaikeata välittää eteenpäin varmenteiden sähköpostiosoite-kenttää, koska se on varmenteen laajennusosissa. Käytettäessä esim. VRK:n kortteja tunnistautumiseen saattaa kannattaa välittää asiakkaan varmenne sellaisenaan taustapalveluun sähköpostiosoitteen tulkitsemista varten, koska muut tunnisteet muuttuvat varmenne- ja korttikohtaisesti samankin henkilön ollessa kyseessä.

RequestHeader set TLS_CLIENT_CERT "%{SSL_CLIENT_CERT}s"

Kuvitellaan, että samalla palvelimella pyörii myös sovelluspalvelin, joka vastaa portista 8000/TCP HTTP-protokollalla. Sovelluspalvelin on esimerkissä pieni python-ohjelma, joka tulostaa konsoliin sisään tulleiden pyyntöjen tiedot. Asetetaan httpd ohjaamaan pyynnöt taustapalvelimeen.

# Yhteys sovelluspalvelimeen...
ProxyPass / http://localhost:8000/
ProxyPassReverse / http://localhost:8000/

Sallitaan httpd:n ottaa yhteyksiä ulospäin.

setsebool -P httpd_can_network_connect=1
setsebool httpd_can_network_connect=1

Tämän jälkeen uudelleenkäynnistetään web-palvelin.

$ sudo systemctl restart httpd

Kun käyttäjä kirjautuu varmenteella web-palveluun, sovelluspalvelin tulostaa vastaanottamansa pyynnön. Otsaketiedoista löytyvät TLS_CLIENT_CERT_CN ja TLS_CLIENT_CERT, kuten oli tarkoituskin.

Sulkulistojen tarkastaminen

Asiakkaat, joiden varmenteet ovat sulkulistalla, eivät saa tunnistautua. Jos varmentaja tukee OCSP-tekniikalla tapahtuvaa varmenteiden tilan tarkastamista, se kytketään päälle asetuksella SSLOCSPEnable.

SSLOCSPEnable on

Vaihtoehtoisesti jos ei haluta sallia palvelimen tekevän OCSP-pyyntöjä ja varmentaja tukee perinteistä sulkulistaa, sitä voidaan käyttää varmenteiden tilan tarkastamiseen.

SSLCARevocationCheck chain
SSLCARevocationFile /etc/pki/tls/ca-bundle-client.crl

Perinteisen sulkulistan käyttö on hieman hankalaa, koska sulkulistat ovat voimassa vain lyhyen ajan (tunneista muutamaan päivään) ja httpd ei osaa hakea uutta automaattisesti. Toisaalta hakeminen voidaan tehdä useilla erilaisilla tavoilla.

Sulkulistan noutaminen ja kelpoisuuden tarkastaminen voidaan tehdä esimerkiksi seuraavanlaisella skriptillä. Skripti hakee sulkulistan HTTP-protokollalla ja kopioi sen toivottuun sijaintiin vain, jos varmentajan allekirjoitus kyetään varmentamaan.

#! /bin/sh
CACERT="/tmp/vrkcqc.pem"
CRLURL="http://proxy.fineid.fi/crl/vrkcqcc.crl"
CRLFILE="/etc/pki/tls/ca-bundle-client.crl"
TMP=`cat /dev/urandom | tr -cd 'a-f0-9' | head -c 32`

curl -s $CRLURL -o /tmp/$TMP.crl
openssl crl -inform DER -in /tmp/$TMP.crl -outform PEM -out /tmp/$TMP.pem
VERIFY=$(openssl crl -in /tmp/$TMP.pem -CAfile $CACERT -noout 2>&1)
if [ "$VERIFY" = "verify OK" ]
then
  # CRL seems ok
  cp /tmp/$TMP.pem $CRLFILE
fi
rm /tmp/$TMP.crl
rm /tmp/$TMP.pem

Jos sulkulista halutaan hakea LDAP-protokollalla, se onnistuu korvaamalla curl-komento ldapsearch-komennolla.

#curl -s $CRLURL -o /tmp/$TMP.crl
LDAPCERT=`ldapsearch -o ldif-wrap=no -x -t -LLL -h ldap.fineid.fi -b "cn=VRK CA for Qualified Certificates,ou=Organisaatiovarmenteet,o=Vaestorekisterikeskus CA,dmdName=FINEID,c=FI" "certificaterevocationlist;binary" | awk -F 'file://' '{print $2}'`
cp $LDAPCERT /tmp/$TMP.crl
rm $LDAPCERT

Ldapsearchin heikkoutena on, että se ei osaa tulostaa binäärikenttiä suoraan syötteeseen, josta se olisi helppo putkittaa tiedostoon. Suositeltavaa onkin antaa työkalun tallentaa kentän sisältö väliaikaistiedostojen hakemistoon (oletuksena /tmp/) ja lukea tiedot sieltä.

Kuormantasaimet

lol

obs, tossa on tietoturvaongelma

 when HTTP_REQUEST {
    if { [SSL::cert count] > 0 } {
        HTTP::header insert "tls-client-cert" [X509::whole [SSL::cert 0]]
    }
}

VPN-ratkaisut

Virtual Private Network (VPN) tarkoittaa liikenteen tunnelointia suojattuun yhteyteen siten, ulkopuoliset tahot eivät pysty urkkimaan tietoja. Tyypillisesti VPN-ratkaisut ovat käyttäjilleen läpinäkymättömiä, eli ohjelmistot eivät tarvitse erityistä tukea toimiakseen tunneloinnin kanssa. Tyypillisesti käyttäjät pyritään tunnistamaan vahvoilla menetelmillä, jotta vain toivotut tahot pääsevät käyttämään suojatun yhteyden takana olevia palveluja.

VPN:n voi toteuttaa monella eri tekniikalla, kuten esimerkiksi IPSEC, TLS, OpenVPN, SSH, PPTP tai L2TP, ja moneen eri käyttötarkoitukseen hieman toisistaan eroavilla tavoilla. Palvelut ja tietoverkot, joita julkaistaan VPN:llä, saattavat erota hyvinkin merkittävästi toisistaan. Seuraavassa esitetään yksinkertaistettu esimerkki OpenVPN-ohjelmistolla, koska se on erittäin suosittu ja tukee varmennepohjaista osapuolten tunnistautumista ja toimikortteja (esim. virkakortti) PKCS#11-rajapinnalla. Palvelin toteutettu esimerkissä RedHat Linux-alustalla ja asiakasohjelmisto Microsoft Windows -käyttöjärjestelmällä, koska se on todennäköisesti mielenkiintosin yhdistelmä.

OpenVPN:n palvelinohjelmisto on suoraan tuotantovalmis vaativimpiinkin ympäristöihin. Sen sijaan asiakasohjelmistot ovat ominaisuuksiltaan hieman puutteellisia. Asiakasohjelmistojen toteutukset ovat jaettu kahtia siten, että niiden taustapalvelut ja käyttöliittymäkerros ovat eriytetty toisistaan. Sen ansiosta asiakasohjelmistoa ei ole jouduttu toteuttamana täysin uudestaan eri alustoilla, mutta toisaalta kaikki käyttöliittymät eivät tue kaikkia toimintoja. Esimerkiksi Microsoft Windows-versioon ei ole kehitetty käyttöliittymäkomponenttia oikean varmenteen valitsemiselle useista. Suositeltavinta onkin räätälöidä muutamalla kymmenellä tuhannella eurolla organisaatiokohtainen käyttöliittymä, jos käyttöä aiotaan laajentaa.

OpenVPN server

Asennetaan Extra Packages for Enterprise Linux (EPEL) ja tämän jälkeen OpenVPN-ohjelmisto.

$ sudo yum install epel-release
$ sudo yum install openvpn

Laaditaan yksinkertainen VPN-palvelun asetustiedosto.

/etc/openvpn/server.conf:

local 192.168.122.222
port 1194
proto udp
dev tun
ca /etc/openvpn/ca.pem
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh2048.pem
crl-verify /etc/openvpn/vrkqc2c.crl
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
cipher AES-256-GCM
user nobody
group nobody
comp-lzo
persist-key
persist-tun

Luodaan uudet Diffie-Hellman -parametrit, ladataan VRK:n juuri- ja välivarmenteet, konvertoidaan ne sopivaan muotoon ja kopioidaan VPN-palvelun varmenteet avaimineen paikoilleen.

$ sudo openssl dhparam -out /etc/openvpn/dh2048.pem 2048
$ curl -O http://vrk.fineid.fi/certs/vrkqc2.crt
$ curl -O http://vrk.fineid.fi/certs/vrkrootc.crt
$ openssl x509 -inform der -in vrkqc2.crt -out vrkqc2.pem
$ openssl x509 -inform der -in vrkrootc.crt -out vrkrootc.pem
$ sudo cat vrkqc2.pem vrkrootc.pem >> /etc/openvpn/ca.pem
$ sudo cp markonnakkijadata.fi.crt /etc/openvpn/server.crt
$ sudo cp markonnakkijadata.fi.key /etc/openvpn/server.key
$ sudo chmod 700 /etc/openvpn/server.key

Tehdään pieni skripti sulkulistojen automatisoitua päivittämistä varten.

/etc/openvpn/updatecrl.sh:

#!/bin/sh
CACERT="/etc/openvpn/vrkqc2.pem"
CRLURL="http://proxy.fineid.fi/crl/vrkqc2c.crl"
CRLFILE="/etc/openvpn/vrkqc2c.crl"
TMP=`cat /dev/urandom | tr -cd 'a-f0-9' | head -c 32`

curl -s $CRLURL -o /tmp/$TMP.crl
openssl crl -inform DER -in /tmp/$TMP.crl -outform PEM -out /tmp/$TMP.pem
VERIFY=$(openssl crl -in /tmp/$TMP.pem -CAfile $CACERT -noout 2>&1)
if [ "$VERIFY" = "verify OK" ]
then
# CRL seems ok
cp /tmp/$TMP.pem $CRLFILE
fi
rm /tmp/$TMP.crl
rm /tmp/$TMP.pem

Annetaan scriptille ajo-oikeudet.

$ sudo chmod +x /etc/openvpn/updatecrl.sh

Asetetaan skripti käynnistymään tasatunneittain.

$ sudo crontab -e
0 * * * * /etc/openvpn/updatecrl.sh

Sallitaan OpenVPN liikenne palvelimen palomuurissa ja sallitaan osoitteenmuutoksien (esim. NAT) tekeminen.

$ sudo firewall-cmd --add-service openvpn
$ sudo firewall-cmd --permanent --add-service openvpn
$ sudo firewall-cmd --add-masquerade
$ sudo firewall-cmd --permanent --add-masquerade

Asetetaan OpenVPN-palvelu käynnistymään automaattisesti ja käynnistetään se.

$ sudo systemctl -f enable [email protected]
$ sudo systemctl start [email protected]

Jos tiedossa on muita aliverkkoja, joihin reititys VPN-yhteyspoolista halutaan rakentaa, säännöt voidaan lisätä palvelimelle ja pakottaa asiakkaille seuraavanlaisesti.

# Liikennöinti verkkoon 10.9.0.0/24 halutaan mahdollistaa, joten
route 10.9.0.0 255.255.255.0
push "route 10.9.0.0 255.255.255.0"

OpenVPN client

Ladataan ja asennetaan OpenVPN Windows-alustalle.

Sallitaan OpenVPN:n liikenne käyttöjärjestelmän palomuurissa. Tarvittavat toimenpiteet vaihtelevat ympäristöittäin, mutta perusperiaatteena 1194/UDP on sallittava molempiin suuntiin.

Avoimen lähdekoodin OpenVPN client Microsoft Windows-alustoille tukee PKCS#11-rajapinnalla toimivia laitteita, kuten virkakortteja. Se ei kuitenkaan osaa kysyä useista varmenteista oikeata, joten käyttäjän varmenteen tunniste pitää selvittää seuraavalla menetelmällä ja kopioida asetustiedostoon (kohtaan pkcs-11-id).

"\Program Files\OpenVPN\bin\openvpn" --show-pkcs11-ids "\Program Files\Fujitsu\mPollux DigiSign Client\cryptoki.dll"

C:\Program Files\openvpn\config\client.ovpn:

client
dev tun
proto udp
remote 192.168.122.222 1194
nobind
persist-key
persist-tun
verb 3
comp-lzo
ca 'C:\Program Files\openvpn\config\ca.crt'
crl-verify 'C:\Program Files\openvpn\config\vrkroota.pem'
pkcs11-providers 'C:\Program Files\Fujitsu\mPollux DigiSign Client\cryptoki.dll'
pkcs11-id 'VRK\x2DFINEID/FinEID\x20IAS\x2DECC/4600017003459293/Organisaatiokortti/45'
#Jotkin clientit tukevevat varmenteen valintaa, mitä varten seuraava asetus on olemassa
#pkcs11-id-management
ns-cert-type server
cipher AES-256-GCM

Sulkulistan tarkastaminen (asetus crl-verify) on asiakkaan näkökulmasta mielekästä lähinnä VPN-palvelimen varmenteen osalta. Tehdään pieni powershell-skripti, joka lataa VRK:n juuren sulkulistan ja muuntaa sen PEM-muotoon.

C:\Program Files\openvpn\config\updatecrl.ps1:

$url = "http://proxy.fineid.fi/arl/vrkroota.crl"
$output = "$PSScriptRoot\vrkroota.crl"
Invoke-WebRequest -Uri $url -OutFile $output
# TODO: millä Windows-komennolla voisi validoida ladatun CRL-tiedoston?
certutil -encode $PSScriptRoot\vrkroota.crl "C:\Program Files\openvpn\config\vrkroota.pem"

Ajastetaan edellisen skriptin ajaminen tunnin välein.

schtasks /create /sc hourly /tn "UpdateCRLs" /ru <käyttäjä, jolla oikeudet hakemistoihin> /rp <salasana> /tr "powershell.exe -executionpolicy Bypass -file C:\PROGRA~1\openvpn\config\updatecrl.ps1"
schtasks /run /tn "UpdateCRLs"

Kopioidaan ca.crt -tiedosto palvelimelta asetustiedostossa mainittuun paikkaan. Tämän jälkeen käynnistetään OpenVPN, joka menee tehtäväpalkin kuvakkeeksi (system tray). Klikataan kuvaketta oikealla napilla, valitaan "Import File..." ja valitaan aiemmin luotu asetustiedosto. Tämän jälkeen valitaan samasta valikosta "Connect".

Tämän jälkeen OpenVPN yrittää muodostaa yhteyttä. Jos käyttäjän työasemassa on asennettuna tarvittavat toimikortinlukija-ajurit ja kortti on lukijassa, DigiSign-client pyytää PIN-koodia.

Yhteyden muodostuttua sovelluksen ikkuna katoaa ja kuvake muuttuu vihreäksi. Kun hiiren osoittimen vie kuvakkeen päälle, OpenVPN kertoo yhteyden tilan.

Secure Shell (SSH)

Secure Shell -yhteyksien tunnistautuminen on mahdollista varmenteilla (X.509v3 Certificates for Secure Shell Authentication, RFC-6187). Tukea tälle ei kuitenkaan ole OpenSSH:ssa, koska kehittäjien mielestä X.509-standardin mukaisten varmenteiden tukeminen kasvattaisi ohjelmiston hyökkäyspinta-alaa liikaa. OpenSSH-projekti on kehittänyt varmennepohjaista tunnistautumista varten oman yksinkertaistetun varmennetyypin, joka eroaa X509:sta seuraavanlaisesti.

SSH-varmenteiden tekninen toteutus on X.509-toteutuksia yksinkertaisempi ja todennäköisesti vähemmän altis toteutusvirheille. Toisaalta sen ominaisuudet ohjaavat herkästi huonolaatuisempaan toimintamalliin. Useat auditointiohjeet vaativat, että jokaisesta käyttöoikeudesta on oltava auditoitavissa vähintään hallinnollinen päätös, pääsyn rakentamiseen liittyvät toimet ja voimassa olevat käyttöoikeudet, eivätkä ne saa olla koskaan ristiriidassa keskenään. SSH:n tyypillisessä toimintamallissa avaintenhallinta on usein puutteellista.

Helpoin tapa hyödyntää x509-varmenteita on luoda olemassa olevista yksityisistä avaimista julkinen SSH-avain, kopioida tieto siitä palvelimille ja käyttää alkuperäisiä yksityisiä avaimia kirjautumiseen. Tämä ei eroa merkittävästi perinteisten SSH-avainten käyttämisestä, koska varmenteiden suurinta etua - luottamusketjua - ei hyödynnetä.

$ ssh-keygen -f markonnakkijadata.fi.key -y > markonnakkijadata.fi.ssh.pub
$ ssh-copy-id -f -i markonnakkijadata.fi.ssh.pub [email protected]
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/marko/markonnakkijadata.fi.ssh.pub"
[email protected]'s password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh '[email protected]'"
and check to make sure that only the key(s) you wanted were added.

$ ssh -i markonnakkijadata.fi.key [email protected]
Last login: Mon Jul 10 20:43:20 2017 from gateway
[marko@centos ~]$

Edellinen onnistuu myös PKCS#11-standardia noudattavilla laitteilla, kuten esim. virkakorteilla, jos lukijaohjelmisto on asennettu oikein.

$ ssh-keygen -D /usr/lib64/libcryptoki.so -y > markonnakkijadata.fi.ssh.pub
$ ssh-copy-id -f -i markonnakkijadata.fi.ssh.pub [email protected]
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/marko/markonnakkijadata.fi.ssh.pub"
[email protected]'s password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh '[email protected]'"
and check to make sure that only the key(s) you wanted were added.

$ ssh -I /usr/lib64/libcryptoki.so [email protected]
Last login: Mon Jul 10 22:06:20 2017 from gateway
[marko@centos ~]$

Luottamusketjujen rakentaminen

Oma CA

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sec-Using_OpenSSH_Certificate_Authentication.html#sec-Introduction_to_SSH_Certificates

Kaupallinen SSH