Gentoo Logo

Disclaimer : Dit document is niet juist en is niet meer onderhouden.


Gentoo Linux Keychain Gids

Inhoud:

1.  Achtergrond

Probleemstelling

Daar zit je dan met een heleboel leuke Gentoo machines die allen sshd draaien, het steeds moeten ingeven van allemaal die wachtwoorden is toch niet zo voor de hand liggend. Of misschien heb je een script of cron-taak die een eenvoudige manier nodig heeft om een ssh-connectie te gebruiken. Hoe je het ook draait of keert, er is een oplossing voor je probleem, en het begint met authentificatie met publieke sleutels.

Hoe werkt authentificatie met publieke sleutels?

Stel dat we een client hebben die wil connecteren naar sshd op een server. De client genereert eerst een sleutelpaar en geeft de publieke sleutel aan de server. Vervolgens, telkens wanneer de client een poging onderneemt om verbinding te maken, verzend de server een uitdaging die geëncrypteerd is met die bepaalde publieke sleutel. Enkel de houder van de corresponderende private slutel kan deze decrypteren. Zoals je reeds kan vermoeden leidt een correct antwoord tot een succesvolle authentificatie.

2.  Hoe gebruik je authentificatie met publieke sleutels

Het sleutelpaar genereren

De eerste stap bestaat eruit een sleutelpaar te creëren. Om dit te doen gebruiken we het ssh-keygen commando als volgt:

Codevoorbeeld 2.1: Het sleutelpaar genereren

$ ssh-keygen -t dsa
(Accepteer gewoon de standaard waarden, en voer een goed wachtwoord in)

Waarschuwing: Hou er rekening mee dat je best een goed wachtwoord kiest, zeker als deze sleutel gebruikt wordt voor root aanmeldingen!

Je zou nu een private sleutel in ~/.ssh/id_dsa moeten hebben, en een publieke sleutel in ~/.ssh/id_dsa.pub. We zijn klaar om de publieke sleutel naar de server op afstand te kopieren.

De server voorbereiden

We zullen het ~/.ssh/id_dsa.pub bestand kopiëren naar de server die sshd draait. We zullen het ook toevoegen aan het ~/.ssh/authorized_keys bestand dat de connecterende gebruiker op die server toebehoort. Hier is een voorbeeld dat laat zien hoe je dit doet als je reeds ssh toegang hebt op de server.

Codevoorbeeld 2.2: De publieke sleutel naar de server kopiëren

$ scp ~/.ssh/id_dsa.pub gebruiker@server:~/myhost.pub
$ ssh server_user@server "cat ~/myhost.pub >> ~/.ssh/authorized_keys"
$ ssh server_user@server "cat ~/.ssh/authorized_keys"

De uitvoer van de laatste lijn zou je de inhoud van het ~/.ssh/authorized_keys bestand moeten laten zien. Controleer of dit er correct uit ziet.

De opstelling testen

Theorethisch gezien, als alles goed ging, en de ssh daemon op de server laat het toe, zouden we nu in staat moeten zijn om, zonder wachtwoord, ssh toegang te verkrijgen op de server. We zullen nog steeds de private sleutel op de client moeten decrypteren met het wachtwoord dat we eerder gebruikten, maar dit mag niet verward worden met het wachtwoord van de gebruikersaccount op de server.

Codevoorbeeld 2.3: De sleutels testen

$ ssh server_user@server

Hopelijk vroeg de server naar jouw wachtwoord voor id_dsa en kon je ssh toegang verkrijgen als server_user op de server. Indien dit niet het geval is, meld je dan aan op de server als server_user en verifieer de inhoud van ~/.ssh/authorized_keys om er zeker van te zijn dat elk gegeven op een aparte regel staat. Je zou ook de sshd configuratie kunnen controleren om er zeker van te zijn dat het authorisatie met publieke sleutels verkiest wanneer dit beschikbaar is.

Op dit moment denk je waarschijnlijk: "Geweldig (zucht), ik heb net een wachtwoord vervangen door een ander!". Rustig, de volgende paragraaf legt je uit hoe je dit kan gebruiken om kostbare tijd te besparen.

3.  Authentificatie met publieke sleutels eenvoudig maken

Typisch sleutelbeheer met ssh-agent

Als je goed gevolgd hebt ben je waarschijnlijk aan het bedenken dat het leuk zou zijn als we op een of andere manier onze private sleutel eenmalig zouden kunnen decrypteren, om vervolgens in alle vrijheid te kunnen ssh'en zonder enig wachtwoord. Heb jij even geluk, want dit is exact waar het programma ssh-agent voor dient.

Het programma ssh-agent wordt meestal gestart aan het begin van je X sessie, of vanuit een shell opstart script zoals ~/.bash_profile. Het werkt door een unix-socket te creëren, en de gewenste omgevingsvariabelen te registreren zodat alle daaropvolgende applicaties gebruik kunnen maken van de dienst door te connecteren op die socket. Het is wel duidelijk dat het enkel nuttig is deze te starten in het moederproces van je X sessie, zodat je de verzameling gedecrypteerde private sleutels in alle daaropvolgende applicaties kan gebruiken.

Codevoorbeeld 3.1: Voorbereiden van ssh-agent

$ ssh-agent

Nota: Deze ssh-agent houdt de sleutels gedecrypteerd tot je de ssh-agent killt. Als je een levensduur wil zetten voor de sleutels, gebruik dan het -t argument zoals omschreven in man ssh-agent.

Wanneer je ssh-agent start zou het je de PID van de draaiende ssh-agent moeten meedelen en enkele omgevingsvariabelen moeten instellen, namelijk SSH_AUTH_SOCK en SSH_AGENT_PID. Het zou ook automatisch aan zijn collectie moeten toevoegen en je vragen naar het bijhorende wachtwoord. Als je andere private sleutels wil toevoegen aan de reeds draaiende ssh-agent kan je het ssh-ad commando als volgt gebruiken:

Codevoorbeeld 3.2: Meer sleutels toevoegen aan ssh-agent

$ ssh-add somekeyfile

En dan nu het magische gedeelte. Omdat je nu reeds je gedecrypteerde private sleutel klaar hebt, zou je in staat moeten zijn om in de server te ssh'en zonder enig wachtwoord in te voeren.

Codevoorbeeld 3.3: Ssh zonder wachtwoord

$ ssh server

Het zou leuk zijn om te weten hoe we de ssh-agent afsluiten in het geval dat dit nodig is, niet?

Codevoorbeeld 3.4: De ssh-agent afsluiten

$ ssh-agent -k

Nota: Als je problemen had om ssh-agent aan de praat te krijgen, zou het nog steeds draaiende kunnen zijn. Je kan het killen zoals elk ander proces door killall ssh-agent uit te voeren.

Als je nog meer gebruiksvriendelijkheid wil met ssh-agent, ga dan verder naar de volgende paragraaf over het gebruik van keychain. Zorg wel dat de draaiende ssh-agent afgesloten wordt zoals in het bovenstaande voorbeeld indien je dit wenst te doen.

Het laatste zuchtje gebruiksvriendelijkheid uit ssh-agent persen

Keychain staat je toe een ssh-agent te hergebruiken tussen de aanmeldingen, en kan, indien gewenst, vragen naar de wachtwoorden telkens de gebruiker aanmeldt. Vooraleer we onszelf voorbijlopen zullen we keychain eerst emergen.

Codevoorbeeld 3.5: Keychain installeren

# emerge keychain

In de veronderstelling dat dit alles vlekkeloos verloopt kunnen we nu in alle vrijheid gebruik maken van keychain. Voeg hetvolgende toe aan je ~/.bash_profile om het in te schakelen:

Codevoorbeeld 3.6: Keychain inschakelen in .bash_profile

keychain ~/.ssh/id_dsa
. ~/.keychain/$HOSTNAME-sh

Nota: Je kan, indien gewenst, meerdere private sleutels toevoegen aan de commandoregel. Daarenboven, als je wil dat er steeds om wachtwoorden gevraagd word wanneer je een shell opent, voeg dan de --clear optie toe.

Nota: Als je geen gebruik maakt van bash, bekijk dan even het EXAMPLES gedeelte van man keychain voor gebruiksvoorbeelden met betrekking tot andere shells. De bedoeling is om die commando's uit te voeren, telkens wanneer je een shell gebruikt.

Laten we testen. Eerst en vooral controleren we of de ssh-agent van de vorige paragraaf hebben afgesloten. Daarna starten we een nieuwe shell, meestal door gewoon in te loggen of een nieuwe terminal te openen. Het zou je moeten vragen naar de wachtwoorden voor elke sleutel die je in de commandoregel hebt gespecifieerd. Alle shells die later worden geopend zouden de ssh-agent moeten hergebruiken Dit laat je toe om steeds opnieuw een wachtwoordloze ssh connectie te maken.

Keychain gebruiken met KDE

Als je een KDE gebruiker bent, kan je KDE de ssh-agent laten besturen in plaats van gebruik te maken van ~/.bash_profile. Om dit te doen, moet je volgende bestanden bewerken. /usr/kde/${KDE_VERSION}/env/agent-startup.sh, welke gelezen wordt tijdens het opstarten van KDE, en /usr/kde/${KDE_VERSION}/shutdown/agent-shutdown.sh, welke uitgevoerd wordt tijdens het afsluiten van KDE. ${KDE_VERSION} moet gelijk zijn aan de eerste twee versiecomponenten van jouw kDE installatie. Bijvoorbeeld, als je KDE 3.5.1 gebruikt kan je de bestanden als volgt bewerken.

Codevoorbeeld 3.7: /usr/kde/3.5/env/agent-startup.sh bewerken

if [ -x /usr/bin/ssh-agent ]; then
  eval "$(/usr/bin/ssh-agent -s)"
fi

Codevoorbeeld 3.8: /usr/kde/3.5/shutdown/agent-shutdown.sh bewerken

if [ -n "${SSH_AGENT_PID}" ]; then
  eval "$(ssh-agent -k)"
fi

Alles wat je nu nog moet doen is een terminal naar keuze starten, bijvoorbeeld Konsole, en de sleutels laden die je zou willen gebruiken. Bijvoorbeeld:

Codevoorbeeld 3.9: Ssh sleutel laden

keychain ~/.ssh/id_dsa
(Geef jouw sleutelwachtwoord in)

Je sleutels zullen worden onthouden tot je je KDE sessie beëindigd of de ssh-agent manueel killt.

4.  Besluitende opmerkingen

Veiligheidsoverwegingen

Het gebruik van ssh-agent voegt ongetwijfeld een beetje onveiligheid aan je systeem toe. Als een andere gebruiker jouw shell gebruikt wanneer jij naar het toilet bent, kan hij aanmelden bij elke server zonder wachtwoord. Als gevolg is dit een risico voor de servers waarnaar je connecteerd en is het noodzakelijk om het lokale veiligheidsbeleid even te consulteren. Als je ssh-agent gebruikt, neem dan voorzorgsmaatregelen om de veiligheid van je sessies te garanderen.

Probleemoplossing

Het meeste zou probleemloos moeten werken, maar moest je toch problemen tegenkomen wil je vast en zeker een paar nuttige dingen weten.

  • Als het onmogelijk is om te connecteren, overweeg dan om ssh te gebruiken met de argumenten -vvv om uit te zoeken wat er mis gaat. Soms is de server niet geconfigureerd om authentificatie met publieke sleutels te gebruiken, soms is deze geconfigureerd om toch de lokale wachtwoorden te vragen. In dat geval zou je de -o optie bij ssh kunnen gebruiken, of de sshd_config van de server aanpassen.
  • Als je problemen hebt met ssh-agent of keychain, zou het kunnen dat je een shell gebruikt die de door ssh-agent of keychain gebruikte commando's niet begrijpt. Lees de man pagina's voor ssh-agent en keychain als je details wil omtrent het werken met andere shells.


Print

Upgedate op 5 februari 2006

De originele versie van dit document wordt niet meer onderhouden

Korte inhoud: Dit document omschrijft hoe je gedeelde ssh sleutels gebruikt in samenwerking met het keychain programma. Een basiskennis van cryptografie met publieke sleutels wordt verondersteld.

Eric Brown
Auteur

Marcelo Góes
Redacteur

Jonas Drieghe
Vertaler

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.