Jak otworzyć port na wczesnym etapie procesu uruchamiania, aby odblokować LUKS przez SSH

Mam w pełni zaszyfrowany serwer z systemem Debian 7 i skonfigurowałem dropbear i busybox, aby odblokować kontener LUKS przez SSH (jak opisano w tym samouczku i w tej odpowiedzi U&L ).

Niestety, za każdym razem, gdy próbuję i SSH do serwera (przez sieć LAN) przy ponownym uruchomieniu, pojawia się błąd „Odmowa połączenia”. Próbowałem telneti nmapdomyślny port (22) i oba mówią, że port jest zamknięty.

Serwer ma ufwregułę akceptowania całego ruchu z sieci LAN:

Anywhere         ALLOW       192.168.1.0/24

Próbowałem zmienić port dropbear Słuchacze on w /etc/defaults/dropbearale sshi telnetnadal odmówił połączenia ¹ .

Jak mogę się upewnić, że port jest otwarty na tym etapie procesu rozruchu, aby móc się połączyć w celu odblokowania kontenera LUKS?

Wyłączenie zapory nie ma znaczenia: nmappokazuje wszystkie porty nadal zamknięte.

Zaktualizuj 2/14

Dodałem break=premountdo linii jądra i miałem kłopoty w initramfs. dropbearzaczął się, ale sieć nie jest w tym momencie uruchomiona. Po wyjściu pojawia się sieć i uruchamianie trwa do momentu wyświetlenia monitu o odblokowanie urządzenia LUKS.

W tym momencie sieć jest uruchomiona, a hostowi przypisano poprawny adres IP, ale port 22 jest nadal zamknięty.

Używana linia IP /etc/initramfs-tools/intiramfs.confto:

export IP=192.168.1.200::192.168.1.1:255.255.255.0::eth0:off

Zgodnie ze wskazówkami zawartymi w tym rozdziale /usr/share/doc/cryptsetup/README.remote.gzpróbowałem po prostu dodać opcję urządzenia, ale to nie wystarczy, aby uruchomić sieć i uzyskać dzierżawę dhcp.

Aktualizacja 11/10/14

Wymagana była odpowiedź Karla/etc/initramfs-tools/conf.d/cryptroot : kluczem było skonfigurowanie :

target=md1_crypt,source=UUID=8570d12k-ccha-4985-s09f-e43dhed9fa2a

Przewodnik okazał się również bardziej aktualny i odpowiedni (i udany).

ssh networking luks

— jasonwryan
źródło

ŁAŁ! Zupełnie nie wiedziałem, że możesz zdalnie odblokować całkowicie zablokowany LUKS. Oczywiście nie mogę odpowiedzieć na twoje pytanie z pewnością, ale zgaduję, że sshd się nie zaczął. Na moim komputerze sshd zaczyna się później.

— emory

Czy masz dostęp do konsoli na maszynie, gdy jest ona w środowisku busybox? Czy możesz sprawdzić, czy dropbear faktycznie działa (przez ps) i nasłuchuje na porcie, którego oczekujesz (przez netstat)?

— larsks

larsks - nie, ponieważ w konsoli monit czeka na wprowadzenie hasła, a przejście na inny TTY oznacza po prostu pusty ekran (jeśli dobrze cię zrozumiałem).

— jasonwryan

Czy możesz (tymczasowo) usunąć szyfrowanie LUKS i sprawdzić, czy Drop Bear rzeczywiście działa?

— emory

Czy próbowałeś użyć jednego z break=Xparametrów rozruchowych, aby uzyskać wczesną initramfspowłokę? Za każdym razem, gdy debuguję szyfrowanie systemu plików, używam break=premount. Możesz sprawdzić, jaka jest sytuacja, rozwiązać ją i kontynuować uruchamianie.

— Alexios

Odpowiedzi:

Ten sam problem dostałem kilka tygodni temu (Debian Wheezy 7.6) i po kilku dniach rozwiązywania problemów dowiedziałem się, że brakuje pliku konfiguracyjnego, który uniemożliwiał poprawne działanie skryptu cryptroot na init-top, dlatego nie zatrzymywał się aby zapytać o hasło za pomocą ssh, zabijanie dropbear na końcu sekwencji (init-bottom).

Plik konfiguracyjny jest wywoływany cryptrooti powinien znajdować się w obszarze /etc/initramfs-tools/conf.d/ Jeśli się nie mylę, plik konfiguracyjny powinien zostać utworzony automatycznie podczas instalacji (przeczytałem tylko jeden samouczek mówiący o tym pliku konfiguracyjnym), ale jakoś tak nie było (przetestowane na serwerze fizycznym i w maszyna wirtualna, ten sam system operacyjny i wersje)

Parę prób zajęło mi prawidłowe skonfigurowanie, ponieważ nie mogłem wtedy znaleźć właściwej składni. Mój plik konfiguracyjny cryptroot wygląda następująco:

target=crypt-root,source=/dev/vg0/root,lvm=root

Po utworzeniu pliku konfiguracyjnego wystarczy zaktualizować initramfs i spróbować ponownie:

update-initramfs -u

— Karl
źródło

Jesteś legendą! Dziękuję: walczyłem z tym od wieków i prawie zrezygnowałem z nadziei na rozwiązanie tego. Moja cryptrootskładnia jest inna niż twoja, ale twoja odpowiedź wystarczyła, aby wskazać mi właściwy kierunek. Jestem ci wdzięczny.

— jasonwryan

Cieszę się, że w końcu udało ci się. Widziałem twoje pytanie podczas badania mojego problemu i pomyślałem, że powinienem opublikować, w jaki sposób je rozwiązałem, gdy już działa.

— Karl

Temat jest nieprawidłowy. Problemem nie jest zamknięty port, to port, który nie był związany. SSHd jeszcze się nie rozpoczął; dlatego nie możesz się z nim połączyć.

— poige
źródło

@camh, czy istnieją jakieś zasady dotyczące tego?

— poige

Bardziej skupiałem się na pierwszym zdaniu, które jest redakcyjne. Reszta jest raczej zwięzła, aby być dobrą odpowiedzią, ale myślę, że nadal jest odpowiedzią. Usunę mój komentarz.

— camh

@camh, widzę ...

— poige

Nie używam sshd: jak mówi pytanie, próbuję połączyć się z instancją dropbear, która domyślnie działa na porcie 22.

— jasonwryan

@ jasonwryan, nie odgrywa żadnej roli, jakiej dokładnie usługi TCP próbujesz użyć, ważne jest to, że nie została uruchomiona.

— poige

Dropbear (serwer ssh) powinien zostać uruchomiony bardzo wcześnie podczas fazy rozruchu - wcześniej niż initsekwencja (rcN.d) i skrypty inicjujące zaporę ogniową; nawet wcześniej niż / jest zamontowany (jest również szyfrowany, prawda?). Tak więc chodzi o initramfspreland / userland załadowany dla jądra przez boot loader. Obraz jest (ponownie) generowany na update-initramfs -upodstawie zawartości /etc/initramfs-tools/, w tym konfiguracji dropbear w /etc/initramfs-tools/etc/dropbear/. Aby zagrać w konfigurację dropbear, zagraj z tym.

Zatem kilka punktów do sprawdzenia:

dropbear nie uruchamia się: nie został dobrze podłączony do sekwencji initramfs;
domyślna zapora sieciowa zaprzecza wszystkim.

— szarpać
źródło

Dzięki Yarek: Myślę, że masz rację - zaktualizowałem swoje pytanie o błąd debiana (i poprawkę, która nie działa). Próbowałem także wyłączyć zaporę.

— jasonwryan