ssh sleutel
Je logt in op een server en er staat geen wachtwoordprompt. Alleen een sleutel die past of niet past.
Dat is het hele idee achter SSH-sleutels, en het is meteen ook waarom ze zo diep in het systeembeheer zitten. Je vervangt een geheim dat je telkens opnieuw over het netwerk stuurt door een paar waarvan de ene helft nooit van jouw schijf komt. De server bewaart alleen het stuk dat niets verraadt.
Een SSH-sleutelpaar bestaat uit twee delen. De privésleutel blijft bij jou, de publieke sleutel kopieer je naar de server, meestal in `~/.ssh/authorized_keys` van de gebruiker in kwestie. Bij het verbinden bewijst je client dat hij de privésleutel bezit, zonder die ooit te tonen. De server controleert dat bewijs tegen de publieke sleutel die hij heeft. Klopt het, dan mag je binnen.
Wat dat kost, is meteen ook het nadeel. Een wachtwoord kun je vergeten en opnieuw instellen. Een privésleutel die je kwijtspeelt, is weg. Geen herstelknop, geen helpdesk die je er weer in loodst. Je maakt een nieuwe sleutel en zet de oude uit op elke server waar hij stond.
De keuze begint bij het algoritme. `ssh-keygen` laat je kiezen uit RSA, ECDSA en Ed25519. RSA is het oudste en het breedst ondersteund, maar je hebt sleutels van 3072 of 4096 bits nodig om vandaag nog comfortabel te zijn. Ed25519 is korter, sneller en standaard veilig, en het werkt op alles wat de laatste tien jaar is uitgekomen. Kies je voor een oud toestel of een vergeten embedded systeem, dan is RSA de veilige uitwijk. Voor al de rest is Ed25519 de logische keuze.
Daar hangt een kost aan vast. Ed25519 vraagt een SSH-implementatie die niet ouder is dan OpenSSH 6.5, uit 2014. Werk je nog met een systeem dat daar niet aan raakt, dan blijf je bij RSA. Dat is geen drama, alleen meer bits om te versturen en te verwerken.
De privésleutel zelf krijgt een passphrase. Dat is een extra laag: zelfs als iemand het bestand kopieert, kan hij er zonder die passphrase niets mee. Het is ook het punt waar de meeste mensen afhaken, want dan moet je bij elke verbinding iets intikken. Daarvoor bestaat `ssh-agent`, dat de sleutel één keer ontgrendelt en daarna in het geheugen houdt voor de duur van je sessie. Gemak en veiligheid zijn hier geen tegenpolen, je moet alleen de agent opzetten.
Zonder passphrase werkt alles ook. Alleen: een privésleutel zonder passphrase is een wachtwoord dat je nooit meer verandert en dat op je schijf staat. Wie het bestand heeft, is binnen. Dat is een bewuste afweging voor geautomatiseerde systemen, niet iets wat je per ongeluk laat gebeuren.
Over de geschiedenis is één ding relevant voor je keuze. SSH-1, de eerste versie uit 1995, had zwakke plekken in de cryptografie. SSH-2 is sinds 2006 de IETF-standaard en vandaag de enige verstandige optie. Kom je een server tegen die nog SSH-1 aanbiedt, dan is dat een reden om die server aan te pakken, niet om je client terug te schroeven.
De OpenSSH-suite die je op zowat elke Linux-distributie vindt, is de implementatie die je waarschijnlijk al gebruikt. `ssh-keygen`, `ssh`, `sshd` — ze komen allemaal van daar. Je hoeft zelden iets anders te installeren.
Het beheer wordt een ander verhaal zodra je met meer dan een paar servers werkt. Dan wil je niet telkens het juiste IP-adres en de juiste gebruikersnaam intikken. Een `~/.ssh/config`-bestand lost dat op: per host een blok met HostName, User en IdentityFile. Dat is platte tekst, geen extra software, en het werkt met alles wat SSH spreekt.
Wil je een grafische laag, dan zijn er tools. Keymaker genereert, bekijkt en installeert sleutels zonder commandoregel, en ruimt oud materiaal op. Seahorse, ook bekend als Passwords and Keys, beheert naast SSH-sleutels ook PGP-sleutels en wachtwoorden, en cachet je passphrase zodat je ze niet telkens opnieuw intikt. Voor wie met veel verbindingen tegelijk werkt, zijn er SSH Pilot en Projectpad: de ene met tabbladen, ingebouwde terminal en SFTP, de andere meer gericht op serverinformatie en het uitvoeren van commando's op meerdere machines.
De kost van die tools is dat je een extra programma in je keten zet. Dat programma moet dezelfde sleutels lezen, dezelfde agent gebruiken en dezelfde config respecteren. Doet het dat niet, dan zoek je op een dag waarom een verbinding werkt in de terminal en niet in de tool. Voor wie twee servers beheert, is dat de moeite niet. Voor wie er twintig beheert, weegt het op.
Aan de andere kant van de lijn staan de tools die je hoopt nooit nodig te hebben. SSH-MITM doet zich voor als server en onderschept authenticatie, om te testen of jouw opstelling door de mand valt. John the Ripper kan een privésleutel kraken als de passphrase zwak is. Dat is geen argument tegen sleutels, het is een argument voor een deftige passphrase en voor het opruimen van sleutels die je niet meer gebruikt. Een sleutel die je twee jaar geleden voor een test hebt gemaakt en nooit hebt verwijderd, staat nog steeds in iemands `authorized_keys`.
Beveiliging is hier geen instelling die je één keer goed zet. Het is een gewoonte: sleutels genereren met een reden, ze een passphrase geven, ze opruimen als het project stopt.
Of je nu Ed25519 neemt of RSA, een agent opzet of je passphrase elke keer intikt, grafische tools gebruikt of bij de commandoregel blijft — het hangt af van hoeveel servers je beheert, hoe vaak je verbinding maakt en hoeveel gemak je veiligheid mag kosten. Er is geen opstelling die voor iedereen klopt. Er is alleen de jouwe, en de vraag of je ze nog zou aanraden aan iemand anders.