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 Li- nux "headless" kan werken en Windows bijvoorbeeld niet. Dit houdt in dat je bij Linux de GUI (Grafische gebrui- kers 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 due alles, inclusief wacht- woorden, als "plain text" (gewone tekst) versturen). SSH daarentegen gebruikt altijd een versleutelde verbinding wat dus veel veiliger is.

Dat was de introductie, nu gaan we verder met het toevoegen van extra beveiligingen, maar even voor de duidelijk- heid:

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:

Voorbeeld 1. SSH verbinding maken met IP

$ ssh 192.168.1.65


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:

Voorbeeld 2. SSH verbinding maken met IP als andere gebruiker

$ ssh pkox@192.168.1.65


en indien ik het poort nummer heb aangepast (is aan te bevelen omdat er continu kraker zijn die poort 22 gebruiken om toegang te krijgen tot de PC van hun slachtoffers) naar bijv. 4321[24] is het commando:

Voorbeeld 3. SSH verbinding maken met IP als andere gebruiker op niet standaard poort

$ ssh -p 4321 pkox@192.168.1.65


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-allrouters
                

de 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 kelder
            

De server is nu bereikbaar als Kelder en kelder.

Voorbeeld SSH verbinding met server. SSH verbindig maken met servernaam

$ ssh -p 4321 pkox@Kelder


de eerste keer dat je inlogt (op dit probeerd) 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 client (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[25]. Deze sleutel maak je als volgt aan:


            
               $ ssh-keygen
           

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" wachtvoord 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:


                
                    $ gedit ~/.ssh/authorized_keys
                

                
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.

als dit werkt is de sleutel correct ingesteld en kunnen we het configuratiebestand van SSH aanpassen om "password login" uit te schakelen: $ sudo gedit /etc/ssh/sshd_config hier passen we 2 of 3 dingen aan :

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.



[24] Maar een beetje kraker zal eerst een portscan doen en dan ontdekken dat SSH op poort 4321 zit

[25] Het is ook mogelijk om een sleutel aan te maken zonder password, maar dit is EXTREEN ONVEILIG en dus niet aan te raden