Haal meer uit de 1Password integratie met SSH

Veilige en moderne SSH-communicatie steunt op public/private key-encryptietechnologie. Hierbij maak je een sleutelpaar aan: een publieke en een private sleutel. Je geeft de server of service waar je wilt inloggen het publieke deel, en houdt het private deel geheim. Standaard wordt de private sleutel als een bestand op je computer opgeslagen, bij voorkeur nog eens extra beveiligd met een wachtwoord.

De opkomst van SSH Key Agents

Gaandeweg zijn er hulpmiddelen ontwikkeld om het gebruik van SSH-sleutels te vereenvoudigen. Een belangrijke hiervan is de SSH Key Agent, die toelaat om de private sleutels in het geheugen te laden en meerdere keren te gebruiken zonder telkens opnieuw het wachtwoord in te geven. Oorspronkelijk werden SSH-sleutels enkel gebruikt om op een server interactief in te loggen (SSH staat dan ook voor “Secure Shell”), maar ook het populaire versiebeheerssysteem Git gebruikt SSH-versleuteling. Dit is niet alleen om code-aanpassingen naar een centrale plek te uploaden of downloaden, maar ook om aanpassingen te tekenen zodat je zeker bent dat de aanpassing van Mieke ook écht door Mieke is gedaan.

Het gebruik van meerdere sleutelparen

Waar je vroeger meestal met één sleutelpaar werkte, is het de laatste jaren eenvoudiger geworden om meerdere sleutelparen te hebben. Dit biedt meer veiligheid en flexibiliteit, maar kan ook tot complicaties leiden.

1Password als oplossing voor sleutelbeheer

Omdat je private sleutel een sleutel is tot je systemen, bewaar je die het best in een wachtwoordmanager. Al meer dan 15 jaar gebruik ik, zowel persoonlijk als in mijn bedrijven, 1Password. Sinds kort heeft 1Password twee functies toegevoegd die het gebruik en beheer van SSH-sleutels nog eenvoudiger maken:

1. Automatische sleutelgeneratie via de browserplugin: De browserplugin van 1Password herkent pagina’s van grote Git-hostingservices (GitHub, GitLab, AWS CodeCommit, enz.) en hostingproviders (DigitalOcean, Vultr, enz.). Als zo’n pagina je vraagt om een nieuwe publieke SSH-sleutel te uploaden, zal 1Password voorstellen om de sleutel rechtstreeks aan te maken. Geen gedoe meer met ssh-keygen en command line-commando’s. Dit maakt het proces veel gebruiksvriendelijker.
2. Vervanging van de SSH Agent: 1Password kan op je desktop de SSH Agent vervangen. Zo blijven je SSH-sleutels veilig opgeslagen in je 1Password-kluis, en haalt de agent ze daar vandaan wanneer dat nodig is. De sleutels komen dus nooit meer op je disk terecht. Een prachtig systeem!

Het nadeel van te veel sleutels

Er is echter ook een nadeel. Het wordt op deze manier bijzonder makkelijk om voor elke service een afzonderlijke sleutel aan te maken. Op zich is dat niet slecht, zeker niet voor veelgebruikte diensten zoals GitHub of een cloudprovider die je regelmatig gebruikt. Er zijn ook diensten waar de sleutel helaas voor jou wordt gemaakt en je niet kan kiezen. Dit is eigenlijk een design-fout in die systemen, maar bon, we maken niet alles zelf 😄

Het probleem is dat SSH niet weet welke sleutel het precies voor welke service moet gebruiken. SSH lost dat op door ze gewoon allemaal te proberen. Het probeert eerst eentje, daarna de tweede als de eerste geweigerd wordt, dan de derde, enzovoort. Als je meerdere sleutels hebt, bestaat de kans dat na een aantal pogingen de server aan de andere kant er genoeg van heeft. Standaard staat dit op zes pogingen, maar serverbeheerders kunnen dat uiteraard zelf aanpassen.

Als je dan meer dan zes sleutels hebt, kan het zijn dat de juiste nooit geprobeerd wordt en je dus niet kan inloggen.

De oplossingen die 1Password biedt

1Password biedt twee manieren om dit probleem aan te pakken:

1. De volgorde bepalen: Je kunt de volgorde waarin sleutels worden geprobeerd bepalen in je 1Password SSH-agentconfiguratiebestand (een .toml-bestand). Dit is bijzonder handig als je, zoals ik, elke paar jaar je sleutels vernieuwt. Je kunt dan de oude sleutels als laatste laten proberen, voor die ene server waar je bijna nooit op inlogt en die je nog niet hebt aangepast aan je nieuwe sleutelpaar.
2. Specifieke sleutels per service instellen: Dit lost het probleem echter niet op wanneer je per service een andere sleutel gebruikt. Als je op de klassieke manier je SSH-sleutels op schijf bewaart, kun je hiervoor gebruikmaken van de IdentityFile-parameter in je SSH-configuratie. Je wijst dan naar je private sleutel voor die service en geeft zo aan dat SSH die sleutel moet gebruiken. Alleen wil ik mijn private sleutels niet op mijn schijf bewaren, zelfs niet versleuteld. Ik wil dat ze in de digitale kluis blijven zitten.

De oplossing met publieke sleutels

In de documentatie van 1Password vond ik een halve oplossing hiervoor. Het beste zou zijn als je kon opgeven welke sleutel de 1Password-agent moet gebruiken. Alleen maakt SSH de selectie van de sleutels, niet 1Password. Tenzij 1Password dus hun eigen ssh-variant zou leveren die de standaard vervangt, helpt dit niet. Bovendien zou ik ernstige bedenkingen hebben bij die oplossing.

De oplossing zit hem erin dat de IdentityFile-parameter ook naar het (niet-geheime) publieke deel van de sleutel kan wijzen. Door je publieke sleutel te exporteren uit 1Password en op schijf te bewaren, en je IdentityFile naar deze publieke sleutel te laten wijzen, werkt het zoals ik wil. De 1Password SSH-agent zal zelf de juiste private sleutel zoeken in de kluis.

Mijn configuratie voor GitHub en Azure DevOps

Mijn configuratie voor GitHub en Azure DevOps ziet er dan bijvoorbeeld als volgt uit:

Host ssh.dev.azure.com
  IdentitiesOnly yes
  IdentityFile ~/.ssh/1pkeys/azure.pub

Host github.com
  IdentitiesOnly yes
  IdentityFile ~/.ssh/1pkeys/github.pub

# Standaardinstellingen
Host *
  ServerAliveInterval 60
  IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock"

  # Versnelde herverbindingen
  ControlPath ~/.ssh/control_%C
  ControlMaster auto
  ControlPersist 1h

Met deze configuratie wijs ik per host naar de specifieke publieke sleutel. SSH gebruikt deze informatie om de juiste sleutel te selecteren, en de 1Password SSH-agent zorgt ervoor dat de bijbehorende private sleutel uit de kluis wordt gehaald wanneer dat nodig is. Zo combineer je de veiligheid van het opslaan van je sleutels in 1Password met de flexibiliteit van het gebruik van meerdere sleutels voor verschillende services, zonder dat je private sleutels op je schijf hoeft te bewaren.

Conclusie

De integratie van SSH in 1Password maakt het beheer van SSH-sleutels eenvoudiger en veiliger. Door gebruik te maken van deze nieuwe functies kun je efficiënter werken en tegelijkertijd de beveiliging van je systemen verhogen. Hoewel het even kan duren om je configuratie aan te passen, wegen de voordelen hier ruimschoots tegenop.

Heb je vragen of wil je je eigen ervaringen delen? Laat het me weten in de reacties!