Navigatie overslaan.
Start

SSH zonder wachtwoord

SSH is onmisbaar om een Linux systeem vanop afstand te installeren of te beheren.

Meestal is SSH echter zo geconfigureerd dat de server een wachtwoord vraagt. Dit kan natuurlijk veiliger, maar ook handiger omdat je nu voor iedere nieuwe verbinding je wachtwoord opnieuw moet ingeven.
Dat laaste zorgt er dan weer voor dat mensen een makkelijk en snel te typen wachtwoord kiezen...

Natuurlijk bestaat er een oplossing, namelijk publickey authenticatie.

Hier is hoe:


Stap 1: Genereer een keypaar

Een keypaar bestaat uit een public en een private key. Deze zijn mathematisch aan elkaar verwant.
De private key is private en blijft op jouw PC, de public key wordt gekopieerd naar alle servers waarop je kan en wil inloggen.

De authenticatie bestaat erin dat de server jouw toegang verleent als jij de private key hebt die bij de public key hoort die op de server staat, i.p.v. toegang te verlenen als jij het wachtwoord kent dat op de server ingevoerd is.

Je private key is erg belangrijk is, en dus ook geëncrypteerd opgeslagen.
Je hebt daarom nog steeds een wachtwoord nodig voor de encryptie van de private key, maar je hoeft dit niet steeds in te geven... (Lees verder)
Als je je private key op een USB stick zet, heb je deze steeds bij de hand.

Het is af te raden om een private key op te slaan zonder wachtwoord.

Een keypaar genereren doe je zo:

|#ssh-keygen -b 4096 -t rsa -C Key_Johan
|
|Generating public/private rsa key pair.
|Enter file in which to save the key (/home/johan/.ssh/id_rsa):
|Enter passphrase (empty for no passphrase):
|Enter same passphrase again:
|Your identification has been saved in /home/johan/.ssh/id_rsa.
|Your public key has been saved in /home/johan/.ssh/id_rsa.pub.
|The key fingerprint is:
|88:df:2c:a9:9f:a6:b7:cd:f5:44:44:bd:35:97:90:e4 Key_Johan

-b 4096 wil zeggen dat er een key van 4096 bits gegenereerd wordt,
-t rsa zorgt ervoor dat er een rsa keypaar gegenereerd wordt, en met
-C Key_Johan kun je een comment geven aan de key. Handig voor later...

Stap 2: Distribueer public keys

Waarom iedere handleiding steeds weer manueel keys wil distribueren is mij een raadsel.
Vooral omdat daar een commando voor bestaat: ssh-copy-id

|# ssh-copy-id -i .ssh/id_rsa.pub <USER>@<SERVER>
|
|Password:
|Now try logging into the machine, with "ssh '<USER>@<SERVER>'", and check in:
|
|  .ssh/authorized_keys
|
|to make sure we haven't added extra keys that you weren't expecting.
|# ssh <USER>@<SERVER>
|
|Enter passphrase for key '/home/johan/.ssh/id_rsa':

-i .ssh/id_rsa.pub is de key die we net gegenereerd hebben,
<USER>@<SERVER> zijn de username en server die je normaal gebruikt om in te loggen met een wachtwoord.

Bij het uitvoeren van dit commando, zal de server voor de laatste maal naar je wachtwoord vragen.

Zoals je kan zien, vraagt hij bij het testen niet gewoon naar een wachtwoord, maar specifiek naar het wachtwoord van de private key.
ssh-copy-id, zorgt er ook automatisch voor dat de permissies van alle nodige files goed gezet worden.

Als je ingelogd bent, kan je met "cat .ssh/authorized_keys" kijken welke keys allemaal geautoriseerd zijn om in te loggen.

|# cat .ssh/authorized_keys
|
|ssh-rsa AAAAB3NQy ...<knip>... BnU1xwS+ryk= Key_Johan

Zie je het nut van de comment?

Op zich ben je nu natuurlijk nog geen stap verder, want bij het inloggen vraagt men nog steeds naar een wachtwoord.
Daarom is er nog een stap 3.

Opmerking:
Alhoewel je een wachtwoord moet kennen om de private key te kunnen decrypteren, is dit GEEN two-factor authenticatie.
Het wachtwoord dient enkel om aan de key te kunnen. Dit zorgt natuurlijk wel voor een beetje extra beveiliging.

Men kan enkel van two-factor authentication spreken als je 2 manieren nodig hebt om je te authenticeren met de server, hier is er slechts 1, namelijk de private key. Wat je allemaal moet doen om aan die key te geraken heeft er niets mee te maken.

Een analoog voorbeeld is het volgende:
Als ik een cijfercombinatie en een sleutel nodig heb om een kluis te openen dan is het two-facor authenticatie.
Als ik enkel een sleutel nodig heb niet.
Als ik nu de sleutel van de kluis in een bureaulade leg die gesloten is met een cijfercombinatie, zorgt dat natuurlijk voor een extra beveiliging, maar het zorgt er niet voor dat mijn kluis nu beveiligd is met two-factor authenticatie, enkel dat de sleutel van de kluis beter beveiligd is.
(Serie beveiliging vs. parallel beveiliging.)

Stap 3: ssh-agent

"ssh-agent" is een programma dat dat jouw keys gaat beheren. In feite voeg je je private key toe aan de ssh agent, (hiervoor moet je het wachtwoord van de key invoeren), en daarna zal de ssh agent met de ssh server de keys uitwisselen.
Om op een server in te loggen, nadat je je keys geladen hebt, hoef je dus geen wachtwoord meer in te geven.

Er zijn letterlijk honderden manieren om dit te doen, aangezien ssh agent enorm flexibel is opgezet.

Als je steeds X-Windows gebruikt, is het het makkelijkst om X-Windows op te starten vanuit een ssh-agent.
Pas daarom het opstartscript aan: Als je bijvoorbeeld "kdm" gebruikt, wordt het "ssh-agent kdm".

Als je enkel met shells werkt, is het het makkelijkst is om de ssh agent te starten als de PC gestart wordt.
Voeg daarom het volgende toe in je crontab:

@reboot ssh-agent -s | grep -v echo > $HOME/.ssh-agent

Vervolgens kan je vanuit je "werkshell" ". ~/.ssh-agent" uitvoeren om de juiste variabelen te setten.
Natuurlijk kan je dit ook automatiseren door de startup scripts bij het opstarten van een nieuwe shell aan te passen.

Eens ssh-agent draait, kan je keys toevoegen met "ssh-add". Er zal dan naar het wachtwoord gevraagd worden.
Je kan zien welke keys er geladen zijn met "ssh-add -L".

Voor extra security, kan je een tijd instellen voor hoelang keys geladen blijven door de ssh agent d.m.v. de "-t" optie van ssh-agent.

Voordelen:

  • Je hoeft je wachtwoord maar eenmalig in te geven, dus het kan een erg goed wachtwoord zijn.
  • Je kan dezelfde key gebruiken om op meerdere systemen in te loggen.
  • Je kan dezelfde key gebruiken om op dezelfde server onder verschillende users in te loggen.
  • Man-in-the-middle attacks zijn uitgesloten.
  • Je hoeft geen wachtwoorden meer te "verbergen" in automatische scripts.
  • Sneller inloggen.
  • Minder information leakage. (Het aantal karakters van een SSH wachtwoord kan bepaald worden door te sniffen.)
  • Met een keylogger kan wel het wachtwoord achterhaald worden, maar niet de key zelf.
  • ...

Vergeet niet:

  • Inloggen met wachtwoorden uit te schakelen in de ssh daemon, of tenminste users die met keys werken een "ongeldig" wachtwoord te geven.
  • Een backup te maken van je keys.
  • Je keys te beveiligen.