Come aprire una porta all'inizio del processo di avvio per sbloccare LUKS tramite SSH


11

Ho un server completamente crittografato con Debian 7 e ho installato Dropbear e busybox per sbloccare il contenitore LUKS tramite SSH (come descritto in questo tutorial e in questa risposta U&L ).

Sfortunatamente, ogni volta che provo e SSH al server (tramite LAN) al riavvio, ricevo un errore "Connessione rifiutata". Ho provato telnete nmapalla porta predefinita (22) ed entrambi dicono che la porta è chiusa.

Il server ha una ufwregola per accettare tutto il traffico dalla LAN:

Anywhere         ALLOW       192.168.1.0/24

Ho provato a cambiare la porta che ascolti dropbear stradale di /etc/defaults/dropbearma sshe telnetstanno ancora rifiutato connessioni 1 .

Come posso assicurarmi che una porta sia aperta in quella fase del processo di avvio in modo da potermi connettere per sbloccare il contenitore LUKS?

Disabilitare il firewall non fa differenza: nmapmostra tutte le porte ancora chiuse.

Aggiornamento 2/14

Ho aggiunto break=premountalla riga del kernel e ho dato un'occhiata agli initramfs. dropbearè stato avviato, ma la rete non è attiva a quel punto. Dopo essere uscito, la rete si avvia e l'avvio continua fino a quando non viene richiesto di sbloccare il dispositivo LUKS.

A questo punto, la rete è attiva e all'host è stato assegnato l'indirizzo IP corretto, ma la porta 22 è ancora chiusa.

La linea IP in /etc/initramfs-tools/intiramfs.confuso è:

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

Coerentemente con le indicazioni in /usr/share/doc/cryptsetup/README.remote.gzho provato solo ad aggiungere l'opzione del dispositivo, ma ciò non è sufficiente per far salire la rete e ottenere un contratto di locazione di dhcp.

Aggiornamento dell'11 / 10/14

La risposta di Karl era ciò che era richiesto: l'installazione /etc/initramfs-tools/conf.d/cryptrootera la chiave:

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

Questa guida si è inoltre dimostrata più aggiornata e pertinente (e di successo).


1
WOW! Non sapevo assolutamente che potevi sbloccare da remoto un LUKS completamente bloccato. Ovviamente non posso rispondere alla tua domanda con certezza ma immagino che sshd non sia iniziato. Nella mia macchina, sshd inizia più avanti nel processo.
emory

1
Hai accesso alla console della macchina mentre è nell'ambiente busybox? Puoi verificare che Dropbear sia effettivamente in esecuzione (tramite ps) e in ascolto sulla porta che ti aspetti (tramite netstat)?
Larks

larsks - no, perché alla console il prompt è in attesa di inserire la passphrase e il passaggio a un altro TTY significa solo uno schermo vuoto (se ti ho capito correttamente).
Jasonwryan,

È possibile (temporaneamente) rimuovere la crittografia LUKS e verificare che l'orso di caduta sia effettivamente in esecuzione?
emory

1
Hai provato a utilizzare uno dei break=Xparametri di avvio per ottenere una initramfsshell iniziale ? Ogni volta che debug problemi di crittografia del filesystem, uso break=premount. È possibile verificare qual è la situazione, risolverla e continuare l'avvio.
Alessio,

Risposte:


3

Ho avuto lo stesso problema qualche settimana fa (Debian Wheezy 7.6) e dopo alcuni giorni di risoluzione dei problemi ho scoperto che mancava un file di configurazione che impediva il corretto funzionamento dello script cryptroot su init-top, quindi non si fermava chiedere la password via ssh, uccidendo il dropbear alla fine della sequenza (init-bottom).

Il file di configurazione è chiamato cryptroote dovrebbe essere sotto /etc/initramfs-tools/conf.d/ Se non sbaglio quel file di configurazione avrebbe dovuto essere creato automaticamente durante l'installazione (ho letto solo un tutorial parlando di quel file di configurazione) ma in qualche modo non lo ha fatto (testato in un server fisico e in una macchina virtuale, stesso sistema operativo e versioni)

Mi ci sono voluti un paio di tentativi per configurarlo correttamente, dato che non riuscivo a trovare la sintassi corretta in quel momento. Il mio file di configurazione cryptroot è il seguente:

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

Una volta creato il file di configurazione, aggiorna initramfs e riprova:

update-initramfs -u

Sei una leggenda! Grazie: ho lottato con questo per secoli e ho praticamente rinunciato alla speranza di risolverlo. La mia cryptrootsintassi è diversa dalla tua, ma la tua risposta è stata sufficiente per indicarmi la giusta direzione. Sono in debito con te.
Jasonwryan,

Sono contento che tu abbia finalmente funzionato. Ho visto la tua domanda mentre stavo indagando sul mio problema e ho pensato che avrei dovuto pubblicare come l'ho risolto una volta che l'ho messo in esecuzione.
Karl,

3

La riga dell'oggetto è errata. Il problema non è una porta chiusa, è una porta che non era vincolata. SSHd non è ancora iniziato; questa è la ragione per cui non riesci a connetterti.


@camh, ci sono delle regole al riguardo?
poige

Mi sono concentrato maggiormente sulla prima frase, che è editoriale. Il resto è piuttosto conciso per essere una buona risposta, ma immagino che sia ancora una risposta. Rimuoverò il mio commento.
Camh,

@camh, vedo ...
poige

Non sto usando sshd: come afferma la domanda, sto tentando di connettermi a un'istanza dropbear che gira di default sulla porta 22.
Jasonwryan,

@jasonwryan, non ha alcun ruolo esattamente quale servizio TCP stai cercando di usare, ciò che conta davvero è che non è stato avviato.
poige,

3

Il dropbear (server ssh) dovrebbe essere avviato molto presto durante la fase di avvio - prima della initsequenza (rcN.d) e degli script di inizializzazione del firewall; anche prima di / è montato (è anche crittografato, giusto?). Quindi initramfs, la zona pre / utente caricata per il kernel dal boot loader. L'immagine è (ri) generata da update-initramfs -ucontenuti di /etc/initramfs-tools/, inclusa la configurazione dropbear in /etc/initramfs-tools/etc/dropbear/. Per giocare con la configurazione dropbear, gioca con quello.

Pertanto, alcuni punti da verificare:

  • dropbear non si avvia: non è stato inserito correttamente nella sequenza initramfs;
  • il firewall predefinito nega tutto.

Grazie yarek: penso che tu abbia ragione - ho aggiornato la mia domanda con un bug debian (e una correzione che non funziona). Ho anche provato a disabilitare il firewall.
jasonwryan,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.