Uruchamiasz nasz skrypt jako root. Sprawdź, że to naprawdę nasz

Uruchamiasz skrypt agenta jako root na każdym serwerze. To oznacza, że kod ma szerokie uprawnienia na maszynie, na której działa. Jeśli ktoś przejmie miejsce, z którego pobierasz ten plik, może podmienić go przed uruchomieniem. Przy większej flocie pojedynczy błąd w zaufaniu do źródła może dotyczyć wielu hostów.

Dotąd suma SHA256 pomagała sprawdzić, czy plik dotarł w całości. Nie odpowiada jednak na pytanie, kto go wydał, jeśli plik i suma pochodzą z tego samego serwera. Napastnik, który może podmienić oba, może przygotować również nową sumę. Od wersji 1.4.3 Secvalis publikuje podpis skryptu, który możesz sprawdzić samodzielnie na swojej stacji.

Co się zmieniło od wersji 1.4.3

Każde wydanie jest podpisane kluczem ed25519-sk przechowywanym na kluczu sprzętowym YubiKey. Utworzenie podpisu wymaga PIN-u oraz fizycznego dotknięcia klucza. Klucz prywatny nie jest zwykłym plikiem na serwerze CI, więc samo zdalne uruchomienie procesu CI nie wystarcza do podpisania wydania.

Są dwa klucze: codzienny i zapasowy. Weryfikator zna oba klucze publiczne. Ich odciski to:

• codzienny: SHA256:DQVo2XI/gJ6cBSV3AdiLgSrLnSJkcYWyJlJfZ9Qsim0
• zapasowy: SHA256:nYvBQ9GeKOglNKXjn/nDpzQ1pH/cZgXL+Yx/ybM0sfU

Skrypt i podpis każdej wersji są także w publicznym repozytorium GitHub pod tagiem v<wersja>. Tag jest źródłem wersji do weryfikacji, a nie adresem aktualizowanym przy każdym wydaniu. Weryfikację wykonujesz na własnej stacji, korzystając z kluczy, które przypiąłeś i porównałeś z niezależnymi publikacjami.

Ważny podpis mówi, że zawartość odpowiada podpisanemu wydaniu. Daje administratorowi punkt odniesienia niezależny od miejsca, z którego pobiera sam plik. Nie zastępuje jednak decyzji o tym, czy konkretną wersję wolno wdrożyć w danym środowisku. Nie mówi też, czy dana wersja została później wycofana. Plik REVOKED na gałęzi main jest osobną listą wersji, których nie należy używać. Jeśli po wydaniu wykryjemy problem, podpis pozostaje prawidłowy, ale wersję trzeba odrzucić na podstawie tej listy. Dlatego kontrola REVOKED jest obowiązkowa, nawet gdy poprzednie polecenie zakończyło się komunikatem Good. Nie traktuj sprawdzenia kryptograficznego jako jedynej decyzji przed wdrożeniem.

CI ma dwa związane z tym zadaniem sprawdzenia. agent-signature sprawdza, że skrypt w repozytorium ma ważny podpis zgodny z przypiętymi kluczami. agent-github-match porównuje bajty skryptu i podpisu w repozytorium z plikami w tagu GitHuba. Kontrola podpisu uruchamia się w każdym pipeline budującym produkcję, a porównanie z GitHubem przy zmianie skryptu lub podpisu. Błąd każdej z nich blokuje wdrożenie. To kontrole procesu wydania, nie weryfikacja wykonywana przez panel lub instalator.

Pięć kroków weryfikacji

Pełne polecenia są na stronie weryfikacji skryptu. Nie przepisuj ich z artykułu, bo tamta strona zawiera aktualny zestaw kluczy i dokładną procedurę. W skrócie:

1. Zapisz klucze publiczne w allowed_signers i porównaj wyświetlone odciski z tymi powyżej oraz z publikacjami poza serwerem Secvalis.
2. Ustal wersję przez tagi publicznego repozytorium, a następnie pobierz z tagu skrypt i plik podpisu. Nie pobieraj wersji wskazanej przez panel jako źródła zaufania.
3. Uruchom ssh-keygen -Y verify z tożsamością [email protected] i namespace secvalis-agent.
4. Sprawdź, czy wersja zapisana w skrypcie zgadza się z tagiem i nie jest starsza od ostatniej wersji zatwierdzonej przez Ciebie.
5. Pobierz REVOKED z main i upewnij się, że wersja nie jest na liście.

Weryfikację wykonaj przed przekazaniem pliku do narzędzia wdrożeniowego. Wtedy dokładnie wiesz, które bajty sprawdziłeś, i możesz przekazać tę samą kopię dalej. Jeśli pobierasz plik ponownie na inną stację albo zmieniasz go podczas przygotowania wdrożenia, sprawdź ponownie konkretną kopię, która trafi na hosty. Nie zakładaj, że nazwa pliku oznacza tę samą zawartość. Zachowaj numer zatwierdzonego wydania i sam zweryfikowany plik zgodnie z własną procedurą zmian. Dzięki temu po czasie można ustalić, jakie bajty zatwierdzono do wdrożenia.

Przykładowa udana weryfikacja kończy się linią:

Good "secvalis-agent" signature for [email protected] with ED25519-SK key SHA256:DQVo2XI/gJ6cBSV3AdiLgSrLnSJkcYWyJlJfZ9Qsim0

Pomiar z 7 listopada 2026 roku w czystych kontenerach potwierdził działanie na Ubuntu 20.04 z OpenSSH 8.2, Debianie 11 z 8.4 i RHEL 9 z 9.9, a osobno na macOS z systemowym OpenSSH 10.3. Dopisanie jednego znaku do secvalis.sh powoduje błąd weryfikacji. To pokazuje, że podpis wiąże się z konkretną zawartością pliku. Wynik testu dotyczy tych środowisk i tej procedury, nie każdej możliwej dystrybucji ani konfiguracji OpenSSH. Gdy polecenie nie działa, odróżnij brak obsługiwanej opcji od wyniku odrzucenia podpisu. W pierwszej sytuacji przenieś weryfikację na wspieraną stację, zamiast pomijać krok.

Wersję pobierasz z tagów GitHuba, a nie z panelu. Ma to znaczenie, bo przejęty serwer mógłby podsunąć starszą wersję z prawidłowym podpisem. Porównanie z ostatnią zatwierdzoną wersją pomaga wykryć próbę cofnięcia. Samo sprawdzenie podpisu nie rozstrzyga, czy wersja jest aktualna. Przy pierwszej weryfikacji pole zatwierdzonej wersji pozostaje puste. Po zaakceptowaniu wydania zapisz jego numer w swoim procesie operacyjnym. Przy kolejnych wdrożeniach porównuj z nim numer znaleziony w pliku. Ta pamięć lokalna jest ważna, bo podpisy starszych wersji nie znikają tylko dlatego, że wydano nowszą.

Gdzie wykonać weryfikację

Potrzebujesz OpenSSH 8.2 lub nowszego. Pomiary potwierdziły polecenia na Ubuntu 20.04, Debianie 11, RHEL 9 i macOS. RHEL 8 ma OpenSSH 8.0 i nie obsługuje ssh-keygen -Y verify. W takim przypadku użyj innej stacji administracyjnej. Do sprawdzenia podpisu nie potrzebujesz własnego klucza sprzętowego. YubiKey służy do podpisania wydania, a nie do jego weryfikacji. Możesz więc przygotować stanowisko weryfikacyjne bez dostępu do sprzętu wydawcy. Istotne jest, abyś miał zaufaną kopię kluczy publicznych i potrafił porównać odciski z publikacjami w niezależnych miejscach. Jeśli nie możesz tego porównania wykonać, nie traktuj samego pliku allowed_signers pobranego razem ze skryptem jako niezależnego potwierdzenia.

Co ta kontrola daje, a czego nie

Weryfikacja ma sens tylko wtedy, gdy wykonujesz ją po swojej stronie przed wdrożeniem. Panel i instalator nie sprawdzają podpisu za administratora. Pobranie skryptu z panelu nie zastępuje sprawdzenia pliku i podpisu z publicznego tagu. Po weryfikacji możesz porównać bajty pliku z pobranym z panelu, ale to osobne porównanie. Taki krok odpowiada na pytanie, czy plik oferowany przez panel jest identyczny z kopią sprawdzoną wcześniej. Nie przenosi jednak weryfikacji podpisu do panelu i nie zmienia źródła wersji, z którego rozpocząłeś kontrolę.

Podpis potwierdza pochodzenie od wydawcy, który kontroluje pasujący klucz. Nie dowodzi, że skrypt nie ma błędów ani że jego działanie będzie właściwe w Twoim środowisku. Dlatego obejrzyj różnice względem ostatniej zatwierdzonej wersji i przeczytaj zmiany. Następnie sprawdź zatwierdzone bajty na jednym hoście z --dry-run, zanim rozprowadzisz je dalej.

Odciski porównuj w kilku miejscach: na stronie zaufania, w repozytorium GitHub i w poście na LinkedIn z 10 listopada 2026, który publikuje je poza naszą infrastrukturą. Jedno źródło nie daje niezależnego porównania. Jeśli odciski różnią się choćby jednym znakiem albo któryś z wymaganych kroków kończy się błędem, zatrzymaj wdrożenie i wyjaśnij rozbieżność. Nie poprawiaj ręcznie klucza, nie wyłączaj kontroli i nie uznawaj błędu sieci przy pobieraniu listy za wynik pozytywny. W procedurze wyraźnie rozróżniono komunikat OK od STOP; do dalszego kroku przechodź wyłącznie po pierwszym.

Instrukcję z komendami i pełną kolejnością znajdziesz na stronie weryfikacji skryptu.

Potrzebujesz wsparcia przy wdrożeniu? Napisz do mnie: https://sysdevops.eu/kontakt. Zakres, poufność i formalności ustalimy indywidualnie.