Se miten serveri käyttäytyy, kun joku koputtaa ovea ja pyytää päästä sisään, asetetaan tiedostossa /etc/ssh/sshd_config. Se koskee siis saapuvia yhteyksiä, ei uloslähteviä. Uloslähtevien oletusarvot laitetaan paikalleen tiedostossa /etc/ssh/ssh_config, ja niitä voidaan hienosäätää tiedostossa ~/.ssh/config ja viime kädessä komentorivin ssh-komennolla. Sen sijaan serverin sshd_config ei ole mikään suositus, jonka voi ylittää.
Kuten aina, niin asetuksissa ei ole mitään oikeaa tai väärää asentoa. On vain erilaisia tarpeita, joita estetään, sallitaan tai muokataan siten, että saadaan se mitä halutaan. Isoilla servereillä, tai työpaikoilla, on erilaiset tarpeet kuin kodin sisäverkossa, Minä asennan Raspberry Pi:n SSH-serverin varmasti eri tavalla kuin naapurin tietokonenörtti ja meistä kumpikin käyttää erilaisia ratkaisuja kuin IP-palveluja tarjoava yritys.
Minä esittelen vain ne asiat, jotka ovat toimineet minun tarpeisiini parin Windows 10 koneen ja yhden Raspberryn sisäverkossa, jonne täytyy aika ajoin päästä iPadillä tien päältä sekä itsehostatuista virtuaaliservereistä.
Iso kasa kommentoituja
Paria Ubuntun asettamaa lisäystä lukuunottamassa kaikki kohdat sshd_config tiedostossa ovat kommentoituja. Tällä kertaa se ei tarkoita sitä, että ne eivät ole käytössä, vaan juurikin päinvastoin. Jokainen kommentoitu rivi kertoo SSH-serverin käytössä olevan oletusarvon eli ne ovat juuri sellaisina käytössä.
Se tarkoittaa sitä, että jos et halua muuttaa mitään, tai jotain kohtaa, niin siihen ei tarvitse koskea. Sen sijaan kaikki muutokset tehdään poistamalla kommentointi ja muuttamalla sen arvoa.
Jokaisen muutoksen jälkeen SSH-serveri on käynnistettävä uudestaan tutulla komennolla:
systemctl restart ssh
PermitRootLogin yes
Root oikeus kirjautua sisään on vähintään yhtä keskusteltu asia kuin root-tunnuksen käyttö. Koska minä käytän root-tunnusta, niin haluan myös kirjautua sillä.
Minulla on tuohon olemassa kuitenkin yksi poikkeus. Joudun aika ajoin kirjautumaan matkoilla vieraasta tietokoneesta joko sisäverkkoni serverin roolissa olevaan Raspberryyn tai sitten omalle Windows-koneelle. Koska käytän tuntematonta konetta, niin en halua kirjautua rootin tilille suoraan – eikä yleensä ole tarvettakaan – vaan sallin sen oikeuden vain tunnetuista osoitteista. Sen teen myöhemmin AllowUser säännöllä. Sillä estän omat ajatushäröt sekä turhan root-tunnuksen koputtelut.
PasswordAuthentication yes
Salliako vai estää salasanalla kirjautuminen on samanlainen väännön aihe kuin rootin salliminen. Pelkästään SSH-avainten salliminen on täysin perusteltua, jos kirjautumiset tapahtuvat aina tutuista ja turvallisista omista laitteista. Kenen tahansa muun koneesta kirjautuminen täytyy tietenkin tapahtua salasanalla.
Joten itselläni se on sallittuna.
Koska SSH-avaimen salliva PubkeyAuthentication yes on ennen salasanaa, niin sitä käytetään ensisijaisesti. Vasta kun avainta ei löydy, niin siirrytään salasanaan. Ja tässä on käyttötapojen filosofian suurin ero:
- kun kirjautuminen sallitaan vain SSH-avaimilla, niin kyseessä on turvallisuuteen pohjaava teko
- kun kirjautuminen sallitaan molemmilla, niin kyseessä on käytettävyysratkaisu
Ollaan taas realisteja. Jos salasanaa ei löydy sanakirjoista ja (kiinalaisten) koputtelijoiden netistä hankkimiinsa listoihin, ja kun käytetään Fail2bannia, niin salasana on täysin yhtä turvallinen kuin SSH-avaimet. Ja kuten todettua – kun avainta ei voida käyttää, niin salasanan estäminen on sama asia kuin että ei käytetä sitä serveriä ollenkaan. Kotiverkoissa auttaa myös muuttuva IP-osoite. Ei se botti viikkoa kauempaa ehdi murtoa yrittää.
Salasanan kieltäminen on sinällään silti perusteltua omassa sisäverkossa – kunhan muistaa kytkeä sen päälle siksi ajaksi, kun ottaa käyttöön uuden julkisen SSH-avaimen.
Mutta jos on ehdottomasti salasanakirjautumista vastaan, niin silti voi jättää itselleen takaoven auki. Minä olen tehnyt asiat näin virtuaaliservereilläni, koska siellä SSH-avainten vaatiminen on lähtökohtaisesti vain järkevää – ne ovat niin jatkuvan murtoyritysten kohteena, eikä niitä käytetä SSH:n käyttäjätasolla mihinkään muuhun työhön. Tai voi käyttää, mutta yleensä ei.
Kielletään salasanojen käyttö, mutta sallitaankin se määrätylle IP-osoitteelle, hostille tai käyttäjälle:
PasswordAuthentication no
#Match User root
# PasswordAuthentication yes
Match Address 11.22.33.44/32,*
PasswordAuthentication yes
#Match Host example.tld
# PasswordAuthentication yes
Huomaa tapa ilmoittaa IP-osoite CIDR-muodossa jatkettuna pilkulla ja tähdellä. Jokainen netin neuvo kehoittaa käyttämään pelkkää IP-osoitetta ja silloin minulla oli SSH samantien ketarat levällään.
Host vaatii ollaakseen myös kaatamatta SSH:ta, että UseDNS yes. Tosin minulle hostin käyttö oli turhaa. Esinnäkään siinä ei voi käyttää dynaamiseen DNS:ään kytkettyå domainia, koska se kääntyy aidosti operaattorin host-nimeen ja se muuttuu IP:n muuttuessa. Oman koti-IP:n hostia operaattorin puolelta ei voi käyttää, koska asteriksilla wildcard ei toimi, koska host-nimen täytyy olla absoluuttisesti oikea – sinänsä mielenkiintoista, että 99 % neuvoista väittää kivenkoveen, että sshd_config sallii wildcardin. Minä väitän, että se on vaan kopioitu config tiedoston säännöistä, eikä kukaan ole vaivautunut kokeilemaan. Tai sitten se on toiminut joskus vuonna miekka ja kivi.
Minulla ei myöskään toiminut User rajoitus. En jaksanut enää penkoa miksi. Minulla riitti siinä vaiheessa, että minulla on yksi takaportti ja se on VPN:n käyttämä IP-osoite.
Mielenkiintoinen nyanssi. Kun jokin match-sääntö kaatoi SSH:n, niin minun piti kommentoida jokainen match, myös toimiva, ennenkuin SSH suostui käynnistymään uudestaan. Sen jälkeen pystyin laittamaan toimivan match-säännön päälle ja käynnistämään SSH:n uudestaan.
Jos nyt onnistun kämmäämään SSH-avaimeni, niin pääsen kuitenkin sisään. Tai aina ei tarvitse olla edes vieras kone. Käytän matkakoneena iPadia ja vaikka luotankin Applen kykyyn suojata laitteet pääsääntöisesti myös NSA:ta vastaan, niin silti en halua mahdollisesti katoavan koneen päästävän ketään root- tai millään muillakaan oikeuksilla suoraan sisään. Siksi käytän siinä salasanoja.
AllowUsers
Pienissä kotiverkoissa käytetään ehdottomasti AllowUsers sääntöä. Puhdas turvallisuustoimenpide, jolla estetään mahdolliset vuodot jonkun pseudo-tunnuksen kautta,
Yksinkertaisimmillaan se on muotoa AllowUsers tunnus tunnus1 tunnus2. Jos tämä on käytössä, eikä root näy listalla, niin on aivan se ja sama mitä sääntö PermitRootLogin sanoo – root ei sitten kirjaudu. Tämä oli minulle hieman yllätys, koska säännönmukaisesti asiat tehdään sen mukaan mikä ensimmäisenä määrää jotain ja luulin, että PermitRootLogin riittäisi. Ilmeisesti nuo tekevät kuitenkin niin eri asioita, että sääntö ensimmäinen pätee ei päde tässä.
Minä olen kuitenkin virittänyt tuota kevyesti. Minulla on perheen tunnukset pelkkinä tunnuksina, joten ne kelpaavat riippumatta mistä ne tulevat. Sen sijaan root on rajoitettu vain sisäverkon töihin IP-osoitteisiin.
sshd_config:
# Allow password auth from XYZ
Match Address 10.10.100.0/24
PasswordAuthentication yes
# Allow password auth from ABC
Match Address 192.168.200.0/24
PasswordAuthentication yes
# Match’s equivalent of a closing brace?
Match Address 0.0.0.0/0
PasswordAuthentication no
Teen B2B-markkinoille sisällöntuottoa sekä UX-testauksia. Samaan liittyy myös koulutukset yrityksille ja webmaailman kanssa muutoin painiville. Serverien sielunelämää on joutunut ohessa opettelmaan. Toinen puoli toiminnasta on koirien ravitsemuksen ja ruokinnan suunnittelua sekä varsinkin omistajien kouluttamista hoitamaan koiriaan oikein ja vielä paremmin.
Profiili: Jakke Lehtonen
Keskustele foorumilla Meta/KATISKA