Przypisujemy procedurę awaryjnego dostępu do hostów SSH z kluczami sprzętowymi

W tym wpisie opracujemy procedurę awaryjnego dostępu do hostów SSH, wykorzystując offline'owe klucze sprzętowe. To tylko jedno z podejść i możesz je dostosować do swoich potrzeb. Będziemy przechowywać centrum certyfikacji SSH dla naszych hostów na kluczu sprzętowym. Schemat ten będzie działać praktycznie na każdej wersji OpenSSH, w tym na SSH z jednolitym logowaniem.

Po co to wszystko? Cóż, to rozwiązanie na wypadek kryzysu. To backdoor, który pozwoli Ci uzyskać dostęp do swojego serwera, gdy z jakiegoś powodu nic innego nie pomoże.

Dlaczego warto używać certyfikatów zamiast kluczy publicznych / prywatnych do awaryjnego dostępu?

• W przeciwieństwie do kluczy publicznych, certyfikaty mogą mieć bardzo krótki okres ważności. Możesz wygenerować certyfikat, który będzie ważny przez 1 minutę lub nawet 5 sekund. Po upływie tego czasu certyfikat stanie się nieważny dla nowych połączeń. Jest to idealne rozwiązanie do awaryjnego dostępu.
• Możesz stworzyć certyfikat dla dowolnego konta na swoich hostach i w razie potrzeby przesyłać takie "jednorazowe" certyfikaty swoim współpracownikom.

Co będzie potrzebne

• Sprzętowe klucze zabezpieczające, które wspierają klucze rezydencyjne.
  Klucze rezydencyjne to klucze kryptograficzne, które są przechowywane całkowicie wewnątrz klucza zabezpieczającego. Czasami są one chronione alfanumerycznym kodem PIN. Publiczna część klucza rezydencyjnego może być eksportowana z klucza zabezpieczającego, w razie potrzeby wraz z identyfikatorem klucza prywatnego. Wsparcie dla kluczy rezydencyjnych oferują na przykład klucze USB serii Yubikey 5. Preferowane jest, aby były one przeznaczone tylko do awaryjnego dostępu do hosta. W tej publikacji użyję tylko jednego klucza, ale powinieneś mieć dodatkowy jako kopię zapasową.
• Bezpieczne miejsce do przechowywania tych kluczy.
• OpenSSH w wersji 8.2 lub wyższej na Twoim lokalnym komputerze i na serwerach, do których chcesz uzyskać awaryjny dostęp. Ubuntu 20.04 dostarczane jest z OpenSSH 8.2.
• (opcjonalnie, ale zalecane) Narzędzie CLI do weryfikacji certyfikatów.

Przygotowanie

Na początek musisz utworzyć centrum certyfikacji, które będzie znajdować się na kluczu zabezpieczającym. Włóż klucz i uruchom:

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

Jako komentarz (-C) podałem yubikey-9-512-742@smallstep.com, aby nie zapomnieć, do którego klucza bezpieczeństwa odnosi się ten urząd certyfikacji.

Oprócz dodania klucza do Yubikey, lokalnie zostaną wygenerowane dwa pliki:

1. sk-user-ca, opis klucza, który odnosi się do prywatnego klucza przechowywanego w kluczu bezpieczeństwa,
2. sk-user-ca.pub, który będzie kluczem publicznym dla twojego urządzenia certyfikacji.

Ale nie martw się, na Yubikey przechowywany jest jeszcze jeden prywatny klucz, którego nie można wydobyć. Dlatego wszystko jest bezpieczne.

Na hostach jako użytkownik root dodaj (jeśli jeszcze nie dodałeś) do konfiguracji twojego SSHD (/etc/ssh/sshd_config) następujące:

TrustedUserCAKeys /etc/ssh/ca.pub

Następnie na hoście dodaj klucz publiczny (sk-user-ca.pub) do /etc/ssh/ca.pub

Uruchom ponownie demon:

# /etc/init.d/ssh restart

Teraz możemy spróbować uzyskać dostęp do hosta. Ale najpierw potrzebujemy certyfikatu. Stwórz parę kluczy powiązaną z certyfikatem:

$ ssh-keygen -t ecdsa -f emergency

Certyfikaty i pary SSH
Czasami ma się ochotę używać certyfikatu jako zamiennika pary kluczy publiczny / prywatny. Ale do uwierzytelnienia użytkownika jeden certyfikat nie wystarczy. Każdy certyfikat ma również związany z nim prywatny klucz. Dlatego musimy wygenerować tę parę "awaryjnych" kluczy, zanim wydamy sobie certyfikat. Ważne jest, że podpisany certyfikat pokazujemy serwerowi, wskazując parę kluczy, dla których posiadamy prywatny klucz.

W ten sposób wymiana kluczy publicznych wciąż jest żywa i zdrowa. To działa nawet z certyfikatami. Certyfikaty po prostu zwalniają serwer z konieczności przechowywania kluczy publicznych.

Następnie utwórz sam certyfikat. Potrzebuję uwierzytelnienia użytkownika ubuntu w 10-minutowym interwale. Możesz to zrobić po swojemu.

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

Zostaniesz poproszony o podpisanie certyfikatu odciskiem palca. Możesz dodać dodatkowe nazwy użytkowników, oddzielając je przecinkami, na przykład -n ubuntu,carl,ec2-user

I to wszystko, teraz masz certyfikat! Teraz musisz ustawić odpowiednie uprawnienia:

$ chmod 600 emergency-cert.pub

Po tym możesz zapoznać się z zawartością swojego certyfikatu:

$ step ssh inspect emergency-cert.pub

Oto jak wygląda mój:

emergency-cert.pub
        Typ: ecdsa-sha2-nistp256-cert-v01@openssh.com certyfikat użytkownika
        Klucz publiczny: ECDSA-CERT SHA256:EJSfzfQv1UK44/LOKhBbuh5oRMqxXGBSr+UAzA7cork
        CA podpisujący: SK-ECDSA SHA256:kLJ7xfTTPQN0G/IF2cq5TB3EitaV4k3XczcBZcLPQ0E
        ID klucza: "test-key"
        Numer seryjny: 0
        Ważność: od 2020-06-24T16:53:03 do 2020-06-24T17:03:03
        Osoby uprawnione:
                ubuntu
        Opcje krytyczne: (brak)
        Rozszerzenia:
                permit-X11-forwarding
                permit-agent-forwarding
                permit-port-forwarding
                permit-pty
                permit-user-rc

Tutaj klucz publiczny to stworzony przez nas klucz emergency, a z centrum certyfikacji związany jest sk-user-ca.

W końcu jesteśmy gotowi uruchomić polecenie SSH:

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

1. Teraz możesz tworzyć certyfikaty dla dowolnego użytkownika na hoście, który ufa Twojemu centrum certyfikacji.
2. Możesz usunąć emergency. Możesz zachować sk-user-ca, ale nie musisz, ponieważ również znajduje się na kluczu bezpieczeństwa. Możliwe, że zechcesz usunąć oryginalny klucz publiczny PEM z swoich hostów (na przykład w ~/ .ssh/authorized_keys dla użytkownika ubuntu), jeśli używałeś go do dostępu awaryjnego.

Dostęp awaryjny: plan działania

Włóż klucz bezpieczeństwa i uruchom polecenie:

$ ssh-add -K

W ten sposób dodasz klucz publiczny centrum certyfikacji i uchwyt klucza do agenta SSH.

Teraz wyeksportuj klucz publiczny, aby stworzyć certyfikat:

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

Utwórz certyfikat z czasem ważności, na przykład nieprzekraczającym jednej godziny:

$ 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

A teraz ponownie SSH:

$ ssh -i emergency username@host

Jeśli Twój plik .ssh/config powoduje jakieś problemy z połączeniem, możesz uruchomić ssh z parametrem -F none, aby obejść go. Jeśli musisz wysłać certyfikat koledze, najprostszym i najbezpieczniejszym rozwiązaniem jest Magic Wormhole. Będziesz potrzebować tylko dwóch plików — w naszym przypadku to emergency i emergency-cert.pub.

Co mi się podoba w tym podejściu, to wsparcie sprzętowe. Możesz umieścić klucze bezpieczeństwa w sejfie i nie znikną nigdzie.

Reklama

Epickie serwery — to tanie VPS z potężnymi procesorami od AMD, częstotliwość rdzenia CPU do 3.4 GHz. Maksymalna konfiguracja pozwala na rozwiązanie praktycznie wszelkich zadań — 128 rdzeni CPU, 512 GB RAM, 4000 GB NVMe. Dołącz!

Źródło: habr.com