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.

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.

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

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

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.

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.

$ 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.

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.

$ 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.

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.

$ 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:

$ 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.

$ ssh server

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

$ ssh-agent -k

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.

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.

# 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:

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

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.

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.

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

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:

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.

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.

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.