We beschrijven de procedure voor noodtoegang tot hosts via SSH met hardware-sleutels

In dit bericht zullen we een procedure ontwikkelen voor noodtoegang tot SSH-hosts, met behulp van hardwarebeveiligingssleutels offline. Dit is slechts een van de benaderingen, en u kunt deze naar wens aanpassen. We zullen het SSH-certificeringscentrum voor onze hosts op een hardwarebeveiligingssleutel opslaan. Dit schema werkt praktisch op elke OpenSSH, inclusief SSH met Single Sign-On.

Waarom dit allemaal? Nou, dit is een noodoptie. Het is een backdoor die u toegang geeft tot uw server in het geval dat niets anders meer helpt.

Waarom certificaten gebruiken in plaats van open/gesloten sleutels voor noodtoegang?

• In tegenstelling tot open sleutels kan de geldigheidsduur van certificaten heel kort zijn. U kunt een certificaat genereren dat slechts 1 minuut of zelfs 5 seconden geldig is. Na deze periode is het certificaat niet meer bruikbaar voor nieuwe verbindingen. Dit is perfect voor noodtoegang.
• U kunt een certificaat aanmaken voor elk account op uw hosts en indien nodig dergelijke 'eenmalige' certificaten naar collega's verzenden.

Wat u nodig heeft

• Hardwarebeveiligingssleutels die residentiële sleutels ondersteunen.
  Residentiële sleutels zijn cryptografische sleutels die volledig binnen de beveiligingssleutel worden opgeslagen. Soms zijn ze beschermd door een alfanumerieke PIN-code. Het openbare deel van de residentiële sleutel kan, indien nodig, uit de beveiligingssleutel worden geëxporteerd, samen met de descriptor van de privésleutel. Ondersteuning voor residentiële sleutels hebben bijvoorbeeld USB-sleutels van de Yubikey 5-serie. Het is wenselijk dat ze alleen voor noodtoegang tot de host zijn bedoeld. Voor dit bericht gebruik ik slechts één sleutel, maar u moet er een extra voor back-up hebben.
• Veilige plek voor het opslaan van deze sleutels.
• OpenSSH versie 8.2 of hoger op uw lokale computer en op de servers waartoe u noodtoegang wilt krijgen. Ubuntu 20.04 wordt geleverd met OpenSSH 8.2.
• (optioneel, maar aanbevolen) CLI-tool voor certificaatcontrole.

Voorbereiding

Om te beginnen moet er een certificeringscentrum worden aangemaakt, dat zich op de hardwarebeveiligingssleutel bevindt. Steek de sleutel in en voer het volgende uit:

$ ssh-keygen -t ecdsa-sk -f sk-user-ca -O resident -C [security key ID]

Als opmerking (-C) heb ik yubikey-9-512-742@smallstep.com aangegeven, zodat ik niet vergeet bij welke beveiligingssleutel dit certificeringscentrum hoort.

Naast het toevoegen van de sleutel aan Yubikey, worden er lokaal twee bestanden gegenereerd:

1. sk-user-ca, een sleuteldescriptor die verwijst naar de privésleutel die is opgeslagen in de beveiligingssleutel,
2. sk-user-ca.pub, dat de publieke sleutel zal zijn voor uw certificeringscentrum.

Maak u echter geen zorgen, er is nog een andere privésleutel op de Yubikey die niet kan worden geëxtraheerd. Daarom is alles hier veilig.

Op hosts onder de gebruikersnaam root, voeg (als het nog niet is toegevoegd) de volgende regel toe aan de configuratie van uw SSHD (/etc/ssh/sshd_config):

TrustedUserCAKeys /etc/ssh/ca.pub

Voeg vervolgens de publieke sleutel (sk-user-ca.pub) toe aan /etc/ssh/ca.pub op de host

Herstart de daemon:

# /etc/init.d/ssh restart

Nu kunnen we proberen toegang te krijgen tot de host. Maar eerst hebben we een certificaat nodig. Maak een sleutelpaar aan dat verband houdt met het certificaat:

$ ssh-keygen -t ecdsa -f emergency

Certificaten en SSH-paren
Soms is er de neiging om een certificaat te gebruiken als vervanging voor een paar publieke / privé sleutels. Maar voor gebruikersauthenticatie is één certificaat niet genoeg. Elk certificaat heeft ook een bijbehorende privésleutel. Daarom moeten we dit paar 'nood'-sleutels genereren voordat we ons certificaat uitgeven. Belangrijk is dat we het ondertekende certificaat aan de server tonen, met de vermelding van het sleutelpaar waarvoor we de privésleutel hebben.

Zo blijft het uitwisselen van publieke sleutels nog steeds levend en wel. Dit werkt zelfs met certificaten. Certificaten ontheffen de server van de noodzaak om publieke sleutels op te slaan.

Maak nu het certificaat zelf aan. Ik heb autorisatie van de gebruiker ubuntu nodig binnen een interval van 10 minuten. U kunt het op uw eigen manier doen.

$ ssh-keygen -s sk-user-ca -I test-key -n ubuntu -V -5m:+5m emergency

U krijgt de mogelijkheid om het certificaat te ondertekenen met een vingerafdruk. U kunt extra gebruikersnamen toevoegen, gescheiden door komma's, zoals -n ubuntu,carl,ec2-user

Dat is het, nu heeft u een certificaat! Vervolgens moeten de juiste rechten worden opgegeven:

$ chmod 600 emergency-cert.pub

Daarna kunt u de inhoud van uw certificaat bekijken:

$ step ssh inspect emergency-cert.pub

Zo ziet mijn certificaat eruit:

emergency-cert.pub
        Type: ecdsa-sha2-nistp256-cert-v01@openssh.com gebruikerscertificaat
        Publieke sleutel: ECDSA-CERT SHA256:EJSfzfQv1UK44/LOKhBbuh5oRMqxXGBSr+UAzA7cork
        Onderteken CA: SK-ECDSA SHA256:kLJ7xfTTPQN0G/IF2cq5TB3EitaV4k3XczcBZcLPQ0E
        Sleutel ID: "test-key"
        Serienummer: 0
        Geldig: van 2020-06-24T16:53:03 tot 2020-06-24T17:03:03
        Principals:
                ubuntu
        Kritieke opties: (geen)
        Uitbreidingen:
                permit-X11-forwarding
                permit-agent-forwarding
                permit-port-forwarding
                permit-pty
                permit-user-rc

Hier is de openbare sleutel — dit is de door ons gemaakte emergency sleutel, en deze is gekoppeld aan de certificeringsautoriteit sk-user-ca.

We zijn eindelijk klaar om het SSH-commando uit te voeren:

$ ssh -i emergency ubuntu@my-hostname
ubuntu@my-hostname:~$

1. Nu kunt u certificaten maken voor elke gebruiker op de host die uw certificeringsautoriteit vertrouwt.
2. U kunt emergency verwijderen. U kunt sk-user-ca behouden, maar dat is niet nodig, aangezien deze ook op de beveiligingssleutel staat. Misschien wilt u ook de oorspronkelijke openbare PEM-sleutel van uw hosts verwijderen (bijvoorbeeld in ~/.ssh/authorized_keys voor gebruiker ubuntu), als u deze voor noodtoegang hebt gebruikt.

Noodtoegang: actiestappen

Steek de beveiligingssleutel in en voer het commando uit:

$ ssh-add -K

Zo voegt u de openbare sleutel van de certificeringsautoriteit en een sleuteldescriptor toe aan de SSH-agent.

Exporteer nu de openbare sleutel om een certificaat te maken:

$ ssh-add -L | tail -1 > sk-user-ca.pub

Maak een certificaat met een vervaldatum van bijvoorbeeld maximaal een uur:

$ ssh-keygen -t ecdsa -f emergency
$ ssh-keygen -Us sk-user-ca.pub -I test-key -n [username] -V -5m:+60m emergency
$ chmod 600 emergency-cert.pub

En nu opnieuw SSH:

$ ssh -i emergency username@host

Als uw .ssh/config bestand problemen veroorzaakt bij de verbinding, kunt u ssh starten met de parameter -F none om zonder het bestand te werken. Als u het certificaat naar een collega moet sturen, is de eenvoudigste en veiligste optie Magic Wormhole. Hiervoor zijn slechts twee bestanden nodig — in ons geval zijn dat emergency en emergency-cert.pub.

Wat ik leuk vind aan deze benadering, is de hardwareondersteuning. U kunt beveiligingssleutels in een kluis bewaren, en ze zullen nergens heen gaan.

Adverteervermelding

Epische servers is goedkope VPS met krachtige AMD-processors, CPU-kernfrequentie tot 3.4 GHz. De maximale configuratie kan vrijwel elke taak aan — 128 CPU-kernen, 512 GB RAM, 4000 GB NVMe. Doe mee!

Bron: habr.com