SSH Beveiligen met sleutel en password
SSH Verbindingen beter beveiligen.
In dit artikel nemen we een kijkje in de wereld van Secure Shell (SSH), We gaan het echter niet hebben over het gebruik van dit programma. Wat we wél gaan doen is jullie tonen hoe je dit nog beter kunt beveiligen.
Dit artikel is opgesplitst in 2 delen, in deel 1 kijken we naar het beveiligen van SSH met een sleutel (gegenereerd op jouw computer) en een password en in deel 2 gaan we nog een stapje verder en vervangen we dit door een YubiKey (4 of nieuwer) 1. De YubiKey is een hardware token die het (bijna) onmogelijk maakt om in te loggen zonder dat deze in 1 van de USB-Poorten zit, en vaak moet je ook nog de knop aanraken waardoor je fysiek aanwezig moet zijn. En als je deze niet hebt kun je ook een OpenPGP smarcard gebruiken. deze smartcard was tot voor kort oa. verkrijgbaar als lidkaart van de FSFE (Free Software Foundation of Europe) waar iedere "Fellow of the FSFe zo', kaart ontving. Daar zijn ze nu vanaf gestapt. Maar je kunt de openPGP smartcard nog steeds kopen bij bijv. FLOSS-Shop zelf heb ik een versie 2.x kaart maar momenteel hebben ze de nieuwere versie 3.3 kaart.
DEEL 1 SSH Beveiligen met sleutel en password
Een van de vele redenen waarom Linux populair is voor servers is, buiten de grote betrouwbaarheid, het feit dat Linux "headless" kan werken en Windows bijvoorbeeld niet. Dit houdt in dat je bij Linux de GUI (Grafische gebruikers omgeving) niet moet gebruiken, sterker nog Linux is eigenlijk een "commando-regel" besturingssysteem en de GUI is een apparte server (X genaamd) die je kunt opstarten indien nodig.
Omdat Linux niet gebouwd is rond een grafische omgeving is het mogelijk om (bijna) alles te doen vanuit deze CLI (Command Line Interface) zoals het vaak genoemd wordt.
Dit stelt systeembeheerders in staat om deze systemen (ook als ze X draaien) te beheren van eender waar, zolang ze maar toegang hebben tot het netwerk waarop deze computer is aangesloten.
Zo kun je bijv. bij een thuisserver deze in de kelder plaatsen (waar het lekker koel is) en deze bedienen vanuit jouw luie zetel in de living.
Het meest gebruikte gereedschap voor dit is SSH (Secure Shell), dit is vergelijkbaar met Telnet, maat Telnet is on- veilig en dient ten alle tijden vermeden te worden (telnet gebruikt geen encryptie en zal dus alles, inclusief wacht- woorden, als "plain text" (gewone tekst) versturen). SSH daarentegen gebruikt altijd een versleutelde verbinding wat dus veel veiliger is.
- client = de computer die we gebruiken om via SSH in te loggen op de "server" (in de kelder)
- server = de computer waarop we van op afstand willen inloggen.
Standaard werkt SSH op poort 22 en met dezelfde gebruikersnaam als de huidige gebruiker. (het is mogelijk dat je op de server het pakket ssh of sshd moet installeren om in te kunnen loggen op die server, de SSH client is meestal wel geïnstalleerd).
dus de simpelste verbinding gaat als volgt:
Dit verteld SSH om een verbinding te maken met 192.168.1.65 als de huidige gebruiker (in mijn geval is dat patrick) op poort 22 (standaard)
Wil ik inloggen op de server maar als gebruiker pkox gebruik ik het volgende commando:
En indien ik het poort nummer heb aangepast (is aan te bevelen omdat er continu krakers zijn die poort 22 gebruiken om toegang te krijgen tot de PC van hun slachtoffers) naar bijv. 4321 2 is het commando:
Als je in plaats van het IP adres van de server een naam gebruiken (is gemakkelijker te onthouden) kun je het be- stand /etc/hosts als root of via sudo aanpassen en de server een naam geven (ook handig bij meerdere servers). $ sudo gedit /etc/hosts Op mijn Debian systeem, bevat dit bestand reeds de volgende gegevens.
127.0.0.1 localhost
127.0.1.1 Laptop.lan Laptop
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodesff02::2 ip6-allroutersDe naam van deze computer is dus Laptop, onderaan kunnen we de server in de kelder toevoegen.
127.0.0.1 localhost
127.0.1.1 Laptop.lan Lapop
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
192.168.1.65 Kelder kelderDe server is nu bereikbaar als Kelder en kelder.
De eerste keer dat je inlogt (of dit probeert) krijg je een melding over de sleutel van deze server.
ssh Kelder The authenticity of host 'kelder (192.168.1.65)' can't be established. ECDSA key fingerprint is SHA256:zCUpFjLS+bW0z8O83TmDX4LgRIJ8bSJaYz9DiZkwloM. Are you sure you want to continue connecting (yes/no)?
Dit is normaal omdat de sleutel van de server nog niet bekend is op de cliënt (als je de volgende keer inlogt krijg je deze melding niet meer) Let op, als je de volgende keer de hostnaam kelder (i.p.v. Kelder) of 192.168.1.65 gebruikt krijg je deze melding opnieuw.
Als je een foutmelding krijgt dat de sleutel niet dezelfde is dan de opgeslagen sleutel is er een probleem. Ofwel heb je de server opnieuw geïnstalleerd, de sleutel verwijderd of een nieuwe aangemaakt. Of de server waarop je wilt in- loggen is niet dezelfde als de server die verbonden is aan 192.168.1.65 en dus onveilig.
Let er wel op dat het IP adres van de server niet veranderd, zo kun je bijv. in de router het MAC adres gebruiken om de server altijd het IP adres 192.168.1.65 te laten krijgen. Als je dynamische IP adressen en DHCP gebruikt kan het voorkomen dat een andere computer op het netwerk het IP van de server krijgt en omdat deze een andere sleutel heeft zal dit ook bovenstaande fout opleveren.
Nu we weten dat SSH correct werkt kunnen we beginnen met de extra beveiliging.
Een key en password gebruiken. Als kwaadwilligen jouw password in handen krijgen kunnen ze vanaf het internet (indien jouw server bereikbaar is) inloggen op de server. Een simpele extra beveiliging is het gebruiken van een SSH sleutel met password 3. Deze sleutel maak je als volgt aan:
Generating public/private rsa key pair.
Enter file in which to save the key (/home/patrick/.ssh/id_rsa)
Hier gebruiken we de standaard locatie
Geef nu een veilig wachtwoord in (let op Linux laat niks zien, ook geen sterretjes). Kies voor een ander password dan dit van de gebruiker op de server.
Your identification has been saved in /home/patrick/.ssh/id_rsa. Your public key has been saved in /home/pkox/.ssh/id_rsa.pub. The key fingerprint is: SHA256:DF0wQxDbmSST97IurFBJOzACe8HytJrsjN1X92RTlCU patrickLaptop The key's randomart image is: +---[RSA 2048]----+ | . ==*.. Eo.| |... .B.* ... | |=.o . oo=. . | |+O o . o. . o | |*.+ o So. o . | |=+ + ... + | |.oo .... . | | . .o . | | .. . | +----[SHA256]-----+
De sleutel is nu klaar voor gebruik.
Open het bestand ~/.ssh/id_rsa.pub: $ gedit ~/.ssh/id_rsa.pub en kopieer de inhoudt naar het klembord.
ssh-rsa AAAAB3NzaC1yc2EAAAADAQRBAAABAQDS7EN/v1V2Up-
eUAip+x0UzvsB0e6wSawMT+cKdvlu6Ykb11aUXGDP4jyzRJgbOl8kegX+y9BcX+TOR-
WOwSD7jwv+fRcfcbbL4teyPY7l5Pm3vwsJPd6Q2nG1TGISJHlPwgVUaoSKiZeO+Dox5YWF-
TAtqD1++TEKxCD1a2FCxtHAzihDsB4pz9uletQ7FP6qPrEbG2nIAzC/Xd0CNpOHbwMA-
ja+j2NGOL0vQ4gXsTn46xypJZp0GQ+/Hx7I16F6UFGmooc3BV4G5BFIXYrrpEvSBHcsGvhEqpJb78rcmWy-
ZY/X1xX0RFOQJWZ+6FsbHVS6G+EZXNKwsj6Hm9EqzuV27 patrick@Laptop
Log nu in op de server via ssh en het "gewone" wachtwoord van de account.
Maak op de server een bestand in ~/.ssh met als naam "authorized_keys" en geef daar de inhoud van de sleutel in:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQRBAAABAQDS7EN/v1V2Up-
eUAip+x0UzvsB0e6wSawMT+cKdvlu6Ykb11aUXGDP4jyzRJgbOl8kegX+y9BcX+TOR-
WOwSD7jwv+fRcfcbbL4teyPY7l5Pm3vwsJPd6Q2nG1TGISJHlPwgVUaoSKiZeO+Dox5YWF-
TAtqD1++TEKxCD1a2FCxtHAzihDsB4pz9uletQ7FP6qPrEbG2nIAzC/Xd0CNpOHbwMA-
ja+j2NGOL0vQ4gXsTn46xypJZp0GQ+/Hx7I16F6UFGmooc3BV4G5BFIXYrrpEvSBHcsGvhEqpJb78rcmWy-
ZY/X1xX0RFOQJWZ+6FsbHVS6G+EZXNKwsj6Hm9EqzuV27 patrick@Laptop
Log nu weer uit en probeer opnieuw in te loggen, dit moet lukken met het wachtwoord dat je hebt ingesteld voor de SSH sleutel.
- #port 22 -> port 4321 (of een ander poort nummer)
- PasswordAuthentication yes -> PasswordAuthentication no
- ChallengeResponseAuthentication yes -> ChallengeResponseAuthentication no
Bij mijn systeem staat ChallengeResponseAuthentication no reeds goed, maar mocht dit op yes staan moeten we dit veranderen in no
Sla het bestand nu op en sluit de tekstverwerker af. Herstart de server of start sshd opnieuw op om de wijzigingen van kracht te laten worden. $ sudo service ssh restart bij SysVinit of sudo systemctl restart sshd bij systemD.
De ssh verbinding zou nu verbroken moeten worden.
Als je nu wilt inloggen met het wachtwoord van de account krijg je een foutmelding: Permission denied (publickey). Maar inloggen met de sleutel en het wachtwoord voor deze sleutel werkt wel. Nu kun je enkel vanaf deze computer inloggen op de server.
Als je via meerdere computers via SSH verbinding wenst te maken moet je op al deze computers een SSH sleutel met wachtwoord aanmaken (wachtwoord moet niet, maar maakt het wel veiliger anders kan iedereen met fysieke toegang tot de client inloggen op de server) en deze wachtwoorden in ~./ssh/authorized_keys zetten. (dit moet je doen voor iedere gebruikers account die je toegang tot de server wilt geven).
Het is ook mogelijk om de id_rsa.pub en id_rsa bestanden te kopiýren naar een andere computer, maar dit raden we af. Het is gemakkelijker om indien een bepaald systeem gecompromitteerd is (verlies, diefstal, ...) enkel de sleutel van dat systeem te verwijderen uit het bestand authorized_keys en niet alle sleutels op alle clients.
Ga verder naar DEEL 2 : SSH Beveliging verhogen dmv een OpenPGP SmartCard of YubiKey