Dodawanie autoryzowanych kluczy SSH w systemach ZimaOS tylko do odczytu

Domyślna ścieżka katalogu domowego nie była zapisywalna

Oryginalne pytanie dotyczące ZimaOS, opublikowane w grudniu 2024 roku, dotyczyło standardowego sposobu użycia pliku ~/.ssh/authorized_keys. Tylko do odczytu układ systemu uniemożliwiał autorowi normalne utworzenie tego pliku. Wstępne eksperymenty opisane w tym wątku nie doprowadziły do potwierdzenia trwałego obejścia, dlatego nie należy przedstawiać ich jako gotowego rozwiązania.

Późniejszy raport dotyczący ZimaOS 1.7 wykorzystywał plik kluczy w /etc

W sierpniu 2026 roku inny członek społeczności opisał działające podejście w ZimaOS 1.7. Umieścił klucze publiczne w pliku /etc/ssh/authorized_keys i wskazał ten plik demonowi SSH. Niezbędna konfiguracja wyglądała następująco:

AuthorizedKeysFile /etc/ssh/authorized_keys

Utwórz plik z uprawnieniami administratora, dodaj po jednym pełnym kluczu publicznym w każdym wierszu i ustaw uprawnienia uniemożliwiające jego modyfikowanie przez innych użytkowników. Następnie zaktualizuj konfigurację serwera SSH i uruchom ponownie demona SSH. Ponieważ jest to rezultat uzyskany przez społeczność, a nie oficjalne oświadczenie dotyczące zgodności, przed wprowadzeniem zmian sprawdź rzeczywisty plik konfiguracyjny i nazwę usługi w zainstalowanej wersji ZimaOS.

Przetestuj logowanie za pomocą klucza przed wyłączeniem uwierzytelniania hasłem

Podczas testów pozostaw otwartą bieżącą sesję SSH i zachowaj dostęp do terminala internetowego ZimaOS. Otwórz drugi terminal i potwierdź, że klucz publiczny umożliwia pomyślne utworzenie nowej sesji. Dopiero po tym teście rozważ opcjonalne ustawienia zwiększające bezpieczeństwo.

PasswordAuthentication no
KbdInteractiveAuthentication no
UsePAM no
PermitRootLogin no
PermitEmptyPasswords no

Te ustawienia mają szersze skutki niż sama zmiana ścieżki kluczy. Zastosowanie ich przed pomyślnym przetestowaniem logowania za pomocą klucza może zablokować zdalny dostęp administracyjny. Mogą również nie pasować do każdego wdrożenia, zwłaszcza jeśli system celowo korzysta z PAM lub kontrolowanego procesu logowania jako root.

Traktuj tę procedurę jako zależną od wersji

Opis dyskusji obejmuje niemal dwa lata, a potwierdzony raport dotyczy konkretnie ZimaOS 1.7. Nie dowodzi on, że te same pliki przetrwają aktualizacje ani że będą działać identycznie we wcześniejszych wydaniach. Zapisz wprowadzone zmiany i ponownie przetestuj dostęp SSH po aktualizacji systemu operacyjnego.

Najczęściej zadawane pytania

Dlaczego nie mogę utworzyć pliku ~/.ssh/authorized_keys w ZimaOS?

W pierwotnym przypadku ta część systemu plików była tylko do odczytu. Późniejsze obejście zmieniało lokalizację kluczy używaną przez demona, zamiast próbować wymusić możliwość zapisu w standardowej ścieżce katalogu domowego.

Gdzie metoda działająca w ZimaOS 1.7 przechowywała klucze publiczne?

Wykorzystywała plik /etc/ssh/authorized_keys i konfigurowała parametr AuthorizedKeysFile, aby wskazywał tę lokalizację.

Czy należy natychmiast wyłączyć uwierzytelnianie hasłem?

Nie. Najpierw zachowaj dostępną sesję awaryjną i zweryfikuj nowe logowanie uwierzytelniane za pomocą klucza. Inne metody uwierzytelniania wyłącz dopiero po tym teście i tylko wtedy, gdy odpowiadają zasadom dostępu obowiązującym w systemie.