Zalecamy procedurę awaryjnego dostępu do hostów SSH za pomocą kluczy sprzętowych

W tym poście opracujemy procedurę awaryjnego dostępu do hostów SSH przy użyciu sprzętowych kluczy bezpieczeństwa w trybie offline. To tylko jedno podejście, które możesz dostosować do swoich potrzeb. Będziemy przechowywać urząd certyfikacji SSH dla naszych hostów w sprzętowym kluczu bezpieczeństwa. Ten schemat będzie działał na prawie każdym OpenSSH, w tym na SSH z pojedynczym logowaniem.

Po co to wszystko? Cóż, jest to opcja ostateczna. Jest to backdoor, który pozwoli Ci uzyskać dostęp do Twojego serwera, gdy z jakiegoś powodu nic innego nie będzie działać.

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

• W przeciwieństwie do kluczy publicznych, certyfikaty mogą mieć bardzo krótki okres ważności. Możesz wygenerować certyfikat ważny przez 1 minutę lub nawet 5 sekund. Po tym okresie certyfikat stanie się bezużyteczny dla nowych połączeń. Jest to idealne rozwiązanie w przypadku dostępu awaryjnego.
• Możesz utworzyć certyfikat dla dowolnego konta na swoich hostach i w razie potrzeby wysłać takie „jednorazowe” certyfikaty współpracownikom.

Czego potrzebujesz

• Sprzętowe klucze bezpieczeństwa obsługujące klucze rezydentne.
  Klucze rezydentne to klucze kryptograficzne przechowywane w całości w kluczu bezpieczeństwa. Czasami są one chronione alfanumerycznym kodem PIN. Publiczną część klucza rezydentnego można wyeksportować z klucza bezpieczeństwa, opcjonalnie wraz z uchwytem klucza prywatnego. Na przykład klucze USB Yubikey serii 5 obsługują klucze rezydentne. Wskazane jest, aby były one przeznaczone wyłącznie do awaryjnego dostępu do hosta. W tym poście użyję tylko jednego klucza, ale powinieneś mieć dodatkowy na kopię zapasową.
• Bezpieczne miejsce do przechowywania kluczy.
• OpenSSH w wersji 8.2 lub wyższej na komputerze lokalnym i na serwerach, do których chcesz mieć dostęp awaryjny. Ubuntu 20.04 jest dostarczany z OpenSSH 8.2.
• (opcjonalne, ale zalecane) Narzędzie CLI do sprawdzania certyfikatów.

Szkolenie

Najpierw musisz utworzyć urząd certyfikacji, który będzie zlokalizowany na sprzętowym kluczu bezpieczeństwa. Włóż klucz i uruchom:

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

Jako komentarz (-C) wskazałem [email chroniony]abyś nie zapomniał, do jakiego klucza bezpieczeństwa należy ten urząd certyfikacji.

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

1. sk-user-ca, uchwyt klucza odnoszący się do klucza prywatnego przechowywanego w kluczu bezpieczeństwa,
2. sk-user-ca.pub, który będzie kluczem publicznym Twojego urzędu certyfikacji.

Ale nie martw się, Yubikey przechowuje inny klucz prywatny, którego nie można odzyskać. Dlatego tutaj wszystko jest niezawodne.

Na hostach jako root dodaj (jeśli jeszcze tego nie zrobiłeś) następujące elementy do konfiguracji SSHD (/etc/ssh/sshd_config):

TrustedUserCAKeys /etc/ssh/ca.pub

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

Uruchom ponownie demona:

# /etc/init.d/ssh restart

Teraz możemy spróbować uzyskać dostęp do hosta. Ale najpierw potrzebujemy certyfikatu. Utwórz parę kluczy, która będzie powiązana z certyfikatem:

$ ssh-keygen -t ecdsa -f emergency

Certyfikaty i pary SSH
Czasami kuszące jest użycie certyfikatu jako zamiennika pary kluczy publiczny/prywatny. Jednak sam certyfikat nie wystarczy do uwierzytelnienia użytkownika. Z każdym certyfikatem jest również powiązany klucz prywatny. Dlatego właśnie musimy wygenerować tę „awaryjną” parę kluczy, zanim wystawimy sobie certyfikat. Ważne jest to, że podpisany certyfikat pokazujemy serwerowi, wskazując parę kluczy, dla której posiadamy klucz prywatny.

Zatem wymiana kluczy publicznych nadal ma się dobrze. Działa to nawet z certyfikatami. Certyfikaty po prostu eliminują potrzebę przechowywania kluczy publicznych przez serwer.

Następnie utwórz sam certyfikat. Potrzebuję autoryzacji użytkownika Ubuntu w odstępie 10 minut. Możesz to zrobić na swój sposób.

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

Zostaniesz poproszony o podpisanie certyfikatu za pomocą odcisku palca. Możesz dodać dodatkowe nazwy użytkowników oddzielone przecinkami, na przykład -n ubuntu,carl,ec2-user

To wszystko, teraz masz certyfikat! Następnie musisz określić prawidłowe uprawnienia:

$ chmod 600 emergency-cert.pub

Następnie możesz wyświetlić zawartość swojego certyfikatu:

$ step ssh inspect emergency-cert.pub

Tak wygląda mój:

emergency-cert.pub
        Type: [email protected] user certificate
        Public key: ECDSA-CERT SHA256:EJSfzfQv1UK44/LOKhBbuh5oRMqxXGBSr+UAzA7cork
        Signing CA: SK-ECDSA SHA256:kLJ7xfTTPQN0G/IF2cq5TB3EitaV4k3XczcBZcLPQ0E
        Key ID: "test-key"
        Serial: 0
        Valid: from 2020-06-24T16:53:03 to 2020-06-24T17:03:03
        Principals:
                ubuntu
        Critical Options: (none)
        Extensions:
                permit-X11-forwarding
                permit-agent-forwarding
                permit-port-forwarding
                permit-pty
                permit-user-rc

Tutaj klucz publiczny jest kluczem awaryjnym, który utworzyliśmy, a sk-user-ca jest powiązany z urzędem certyfikacji.

Wreszcie jesteśmy gotowi do uruchomienia polecenia SSH:

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

1. Możesz teraz tworzyć certyfikaty dla dowolnego użytkownika na hoście, który ufa Twojemu urzędowi certyfikacji.
2. Możesz usunąć stan awaryjny. Możesz zapisać sk-user-ca, ale nie musisz tego robić, ponieważ znajduje się on również na kluczu bezpieczeństwa. Możesz także usunąć oryginalny klucz publiczny PEM ze swoich hostów (na przykład w ~/.ssh/authorized_keys dla użytkownika Ubuntu), jeśli użyłeś go do dostępu awaryjnego.

Dostęp awaryjny: plan działania

Wklej klucz bezpieczeństwa i uruchom polecenie:

$ ssh-add -K

Spowoduje to dodanie klucza publicznego i deskryptora klucza urzędu certyfikacji do agenta SSH.

Teraz wyeksportuj klucz publiczny, aby utworzyć certyfikat:

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

Utwórz certyfikat z datą ważności nie dłuższą niż godzina:

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

$ ssh -i emergency username@host

Jeśli plik .ssh/config powoduje problemy podczas łączenia, możesz uruchomić ssh z opcją -F none, aby go ominąć. Jeśli chcesz wysłać certyfikat współpracownikowi, jest to najłatwiejsza i najbezpieczniejsza opcja Magiczny tunel czasoprzestrzenny. Aby to zrobić, potrzebujesz tylko dwóch plików - w naszym przypadku Emergency i Emergency-cert.pub.

To, co podoba mi się w tym podejściu, to obsługa sprzętu. Możesz umieścić swoje klucze bezpieczeństwa w sejfie i nigdzie nie znikną.

O prawach reklamy

Epickie serwery - jest tani VPS z wydajnymi procesorami AMD, częstotliwość rdzenia procesora do 3.4 GHz. Maksymalna konfiguracja pozwala rozwiązać niemal każdy problem - 128 rdzeni procesora, 512 GB RAM, 4000 GB NVMe. Dołącz do nas!

Źródło: www.habr.com