SSH per decrittografare LVM crittografato durante l'avvio del server senza testa?


60

Quando ho installato Ubuntu 10.04 e, ora, 10.10, mi è stata offerta la possibilità di abilitare "LVM crittografato" per il mio disco rigido. Dopo aver scelto quell'opzione, mi viene richiesta la password durante l'avvio per decrittografare LVM.

Ora, sto pensando di configurare un server senza testa che esegue Linux (non necessariamente Ubuntu), ma sono preoccupato che, poiché il server è senza testa, non sarò in grado di decrittografarlo durante l'avvio. Potrei accedere a SSH durante l'avvio per inserire la mia password per LVM crittografato? In tal caso, come posso impostarlo? O c'è un'altra soluzione? Ancora una volta questa domanda NON è specifica per Ubuntu. Grazie.


4
Vedi anche:zless /usr/share/doc/cryptsetup/README.remote.gz
0xC0000022L

Penso che la risposta di @Nate dovrebbe essere quella accettata: (essenzialmente, poiché è necessaria una modifica per riflettere le modifiche nel blog collegato) utilizza le chiavi pubbliche anziché quelle private .
Jonathan Y.

Risposte:


25

Per le versioni più recenti di Ubuntu, ad esempio 14.04, ho trovato molto utile una combinazione di @dragly e le risposte di questo blogposts . Per parafrasare:

  1. (Sul server) Installa Dropbear

    sudo apt-get install dropbear
    
  2. (Sul server) Copia e assegna le autorizzazioni per l'accesso alla chiave pubblica / privata root

    sudo cp /etc/initramfs-tools/root/.ssh/id_rsa ~/.
    sudo chown user:user ~/id_rsa
    

ricordati di cambiare l' utente con il tuo nome utente sul server

  1. (Sul client) Recupera chiave privata dal server

    scp user@remote.server:~/id_rsa ~/.ssh/id_rsa_dropbear
    
  2. (Sul client) Aggiungi una voce alla configurazione di ssh

    Host parkia
        Hostname 192.168.11.111
        User root
        UserKnownHostsFile ~/.ssh/know_hosts.initramfs
        IdentityFile ~/.ssh/id_rsa_dropbear
    Remember to change _parkia_ to whatever you'd like to type `ssh my-box` to be.
    
  3. (Sul server) Creare questo file in/etc/initramfs-tools/hooks/crypt_unlock.sh

  4. (Sul server) Rendi eseguibile quel file

    sudo chmod +x /etc/initramfs-tools/hooks/crypt_unlock.sh
    
  5. Aggiorna initramfs

    sudo update-initramfs -u
    
  6. Disabilita il servizio dropbear all'avvio in modo che openssh venga usato dopo la decodifica della partizione

    sudo update-rc.d dropbear disable
    

Hai finito. Provalo. Controlla il post sul blog collegato sopra per istruzioni su come configurare il server con un indirizzo IP statico se è qualcosa che dovresti fare.


Il blog collegato ha aggiunto un riferimento ad aggiungere la chiave pubblica di un client a quella del server /etc/initramfs-tools/root/.ssh/authorized_keys, anche se continua a copiare la chiave privata di Dropbear, che si può ignorare completamente. Seguire il resto delle istruzioni funziona per me, il che significa che questa dovrebbe essere la risposta accettata (una volta che riflette quel cambiamento), perché utilizza solo chiavi pubbliche.
Jonathan Y.

23

In questo post del blog viene mostrata una guida per eseguire tale configurazione con BusyBox e Dropbear . early-ssh non ha funzionato per me e apparentemente non è più necessario.

Ho riassunto ciò che devi fare di seguito. Per maggiori dettagli, dai un'occhiata al post sopra:

  1. Installa BusyBox e Dropbear sul tuo server

    sudo apt-get install dropbear busybox
    
  2. Aggiorna i tuoi initramfs sul server

    sudo update-initramfs -u
    
  3. Copia la chiave privata generata da dropbear sul tuo computer client. Potrebbe essere necessario copiarlo in una nuova directory e cambiare proprietà per farlo. Sul tuo server procedi come segue:

    sudo cp /etc/initramfs-tools/root/.ssh/id_rsa ~/.
    sudo chown user:user ~/id_rsa
    

    Ricorda di sostituire l'utente con il tuo nome utente. Gli accessi con password non sembrano funzionare.

  4. Ora puoi trasferire la chiave privata con scp chiamando il seguente sul tuo client :

    scp user@remote.server:~/id_rsa ~/.ssh/id_rsa_dropbear
    
  5. Imposta il file ~ / .ssh / config del tuo client per un facile accesso. Aprilo con un editor di testo e aggiungi quanto segue:

    Host myremoteserver
        HostName my.remote.server
        User root
        UserKnownHostsFile ~/.ssh/known_hosts.initramfs
        IdentityFile ~/.ssh/id_rsa_dropbear
    

    Cambia l'host come preferisci e HostName con il nome del tuo server. Lascia che l'utente sia root. Sembra essere l'unico utente accettato in Dropbear. Salva e chiudi il file.

  6. Riavvia il server e attendi il prompt della passphrase. Concedi a Dropbear qualche secondo per rilevare e configurare la sua connessione Internet. Connettiti al tuo server con il seguente comando sul tuo client :

    ssh myremoteserver # or any name you chose
    
  7. Una volta effettuato l'accesso, immettere il seguente comando sul server . Vedi il post sul blog per i dettagli:

    pid=`ps | grep "/scripts/local-top/cryptroot" | cut -d " " -f 3`
    kill -9 $pid
    sleep 35
    /scripts/local-top/cryptroot
    pid=`ps | grep "/bin/sh" | cut -d " " -f 3`
    kill -9 $pid;
    

    Ci vorrà del tempo (30 secondi) prima di riuscire a digitare la passphrase. Digita quando richiesto.

  8. Chiudi la connessione digitando

    exit
    
  9. Il server dovrebbe ora aver sbloccato il suo disco rigido crittografato e avviarsi normalmente.

(Un grande grazie all'autore originale del post sul blog!)


2
Non capisco bene il motivo per cui mi muovo con le chiavi private. Dovrebbe essere sufficiente copiare la chiave pubblica dell'utente sul computer client sul server come chiave autorizzata per il server principale, giusto?
gertvdijk,

Sono sicuro che è possibile creare la coppia di chiavi sul computer client e spostare solo la chiave pubblica da lì al server, ma se ricordo bene penso che ci siano stati dei problemi nel trovare un formato che BusyBox avrebbe accettato. Quindi riutilizzare le chiavi che erano già sul server è stata l'unica opzione che ho funzionato.
Dragly

1
Hai idea di cosa dovrei fare per farlo funzionare su Arch Linux?
Gerharddc,

1
@Gerhman Dai un'occhiata al pacchetto dropbear_initrd_encrypt nell'AUR per il supporto early-ssh su Archlinux.
Caleb,

1
@Gerhman archwiki page: lo sblocco remoto della radice o di altre partizioni non l'hanno ancora fatto, ma sembra interessante. Dovrà dare un'occhiata :)
hanetzer

18

Penso che early-ssh fornisca ciò che stai cercando:

Early-ssh is a simple initramfs hook, which installs Dropbear SSH server into  
your initramfs, and starts it at boottime, so you will be able to do a lot of  
things remotely over SSH, before your root partition gets mounted, for example:

* unlocking LUKS encrypted crypto devices - 
  even your root can be an encrypted filesystem
* assembling/altering RAID arrays (mdadm)
* checking the root filesystem in read-write mode, 
  taking action in case of errors
* and so on...

C'è già un pacchetto .deb disponibile, quindi probabilmente stai bene con Ubuntu.


Sembra che sia esattamente quello che sto cercando, grazie!
hpy,

3
Hai un link a un buon tutorial o howto? Sono bloccato con early-ssh sul mio debian squeeze box.

1
Sì, un tutorial sarebbe fantastico.
hpy


16

Dai un'occhiata al readme di cryptsetup per questo in /usr/share/doc/cryptsetup/README.remote.gz(pacchetto Ubuntu cryptsetup). Vi è una guida completa per raggiungere questo obiettivo. È simile alla risposta di Dragly , ma penso che sia un po 'più elegante. (Chiavi formattate Dropbear, passando la passphrase tramite un FIFO anziché uno script shell fragile, ecc.)

sbloccare rootfs tramite login ssh in initramfs

Puoi sbloccare i tuoi rootfs all'avvio da remoto, usando ssh per accedere al sistema di boot mentre è in esecuzione con initramfs montato.

Impostare

Affinché lo sblocco remoto funzioni, è necessario installare i seguenti pacchetti prima di creare initramfs: dropbear busybox

Il file /etc/initramfs-tools/initramfs.confcontiene le opzioni di configurazione utilizzate durante la creazione di initramfs. Dovrebbe contenere BUSYBOX=y (questo è impostato come predefinito quando è installato il pacchetto busybox) per avere busybox installato in initramfs e non dovrebbe contenere DROPBEAR=n, il che disabiliterebbe l'installazione di dropbear su initramfs. Se impostato su DROPBEAR=y, dropbear verrà installato in ogni caso; se DROPBEARnon è impostato affatto, dropbear verrà installato solo in caso di una configurazione di cryptroot esistente.

Le chiavi host utilizzate per initramfs sono dropbear_dss_host_keye dropbear_rsa_host_key, entrambe situate in /etc/initramfs-tools/etc/dropbear/. Se non esistono quando viene compilato initramfs, verranno creati automaticamente. Di seguito sono riportati i comandi per crearli manualmente:

dropbearkey -t dss -f /etc/initramfs-tools/etc/dropbear/dropbear_dss_host_key
dropbearkey -t rsa -f /etc/initramfs-tools/etc/dropbear/dropbear_rsa_host_key

Poiché initramfs non verrà crittografato, si presuppone l'autenticazione con chiave pubblica. Le chiavi utilizzate per questo verranno prese da /etc/initramfs-tools/root/.ssh/authorized_keys. Se questo file non esiste quando viene compilato initramfs, verrà creato e /etc/initramfs-tools/root/.ssh/id_rsa.pubvi verrà aggiunto. Se anche quest'ultimo file non esiste, verrà generato automaticamente - troverai la chiave privata corrispondente di cui dovrai successivamente accedere agli initramfs /etc/initramfs-tools/root/.ssh/id_rsa (o id_rsa.dropbearnel caso in cui tu ne abbia bisogno in formato dropbear). Di seguito sono riportati i comandi per eseguire manualmente i rispettivi passaggi:

Per creare una chiave (in formato dropbear):

dropbearkey -t rsa -f /etc/initramfs-tools/root/.ssh/id_rsa.dropbear

Per convertire la chiave dal formato dropbear al formato openssh:

/usr/lib/dropbear/dropbearconvert dropbear openssh \
    /etc/initramfs-tools/root/.ssh/id_rsa.dropbear \
    /etc/initramfs-tools/root/.ssh/id_rsa

Per estrarre la chiave pubblica:

dropbearkey -y -f /etc/initramfs-tools/root/.ssh/id_rsa.dropbear | \
    grep "^ssh-rsa " > /etc/initramfs-tools/root/.ssh/id_rsa.pub

Per aggiungere la chiave pubblica al file authorized_keys:

cat /etc/initramfs-tools/root/.ssh/id_rsa.pub >> /etc/initramfs-tools/root/.ssh/authorized_keys

Nel caso in cui si desidera un po 'di interfaccia per avere configurato tramite DHCP, impostare DEVICE=in /etc/initramfs-tools/initramfs.confdovrebbe essere sufficiente. Initramfs dovrebbe anche rispettare il ip=parametro kernel. Nel caso in cui usi grub, probabilmente ti consigliamo di impostarlo /boot/grub/menu.lst, nella # kopt=riga ' ' o aggiunto a una o più righe specifiche kernel. Il ip=parametro kernel è documentato Documentation/nfsroot.txtnella struttura dei sorgenti del kernel.

Problemi

Non dimenticare di correre update-initramfsquando hai cambiato la configurazione per renderlo efficace!

Raccogliere abbastanza entropia per il demone ssh a volte sembra essere un problema. L'avvio del demone ssh potrebbe essere ritardato fino a quando non è stata recuperata abbastanza entropia. Questo non è un blocco per il processo di avvio, quindi quando sei sulla console non dovrai aspettare che sshd completi il ​​suo avvio.

Procedura di sblocco

Per sbloccare da remoto, potresti fare qualcosa del genere:

ssh -o "UserKnownHostsFile=~/.ssh/known_hosts.initramfs" \
    -i "~/id_rsa.initramfs" root@initramfshost.example.com \
    "echo -ne \"secret\" >/lib/cryptsetup/passfifo"

Questo esempio presuppone che tu abbia un known_hostsfile " ~/.ssh/known_hosts.initramfs" che contiene la chiave host del sistema cryptroot, che hai un file " ~/id_rsa.initramfs" che contiene la chiave autorizzata per il sistema cryptroot, che il nome del sistema cryptroot è " initramfshost.example.com" e che il la passphrase di cryptroot è " secret"

- < debian@x.ray.net>, mer 30 set 2009

Grazie a jap per avermelo segnalato su un altro canale.


1
Questa sembra un'idea molto migliore (descritta nei documenti ufficiali e tutto il resto) che hackerare ps-grepping. Come nota a margine sulla procedura di sblocco fornita, tuttavia, si potrebbe voler essere cauti nel digitare la passphrase direttamente sulla riga di comando poiché molto probabilmente finirà in un file di cronologia della shell da qualche parte. Una possibile soluzione è la creazione di un minuscolo script wrapper che richiede la passphrase mediante read -s -p.
Joelpet,

1
nota che ci sono problemi con questo approccio nelle recenti versioni di Ubuntu, ad esempio bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/595648
Frederick Nord

6

Se vuoi essere in grado di eseguire l'avvio incustodito e da remoto, dovresti anche guardare Mandos (che io e altri abbiamo scritto):

Mandos è un sistema che consente ai server con file system root crittografati di riavviarsi incustoditi e / o in remoto. Vedere il file della pagina del manuale di introduzione per ulteriori informazioni, incluso un elenco di domande frequenti.

In breve, il server di avvio ottiene la password sulla rete, in modo sicuro. Vedi il README per i dettagli.


Grazie per i tuoi contributi, ma tieni presente che il 100% dei tuoi post menzioni quasi identiche del tuo prodotto è un comportamento borderline e corri il rischio di essere considerato spam (avrei segnalato i tuoi post se Mandos non fosse un software libero o non avevi una cronologia di post non Mandos su altri siti).
Gilles 'SO- smetti di essere malvagio' il

@Gilles: Fatto adesso.
Teddy,

2

Server senza testa? Se ha una porta seriale, usala.

GRUB può essere configurato per funzionare tramite la porta seriale. Il tuo kernel può anche essere configurato utilizzando la porta seriale per inviare i messaggi di avvio iniziali, inserire la password per sbloccare le unità e accedere. (Se il tuo server supporta il BIOS seriale, abilita anche quello. Quindi non dovrai mai connetterti un monitor alla macchina).

Sempre una buona idea avere un modo "non di rete" per entrare in un server senza testa.


Ottimo punto! Tuttavia, i modi " non di rete " per entrare in un server senza testa sono per lo più ( solo ) rilevanti se la vicinanza fisica tra client / server è vicina; a meno che non stia trascurando altre possibilità / funzionalità di una connessione seriale.
ILMostro_7,


2

Sfortunatamente, nessuna delle risposte sopra ha funzionato per me. Inoltre, copiare una chiave privata dal server sembra paradossale.

Ad ogni modo, le seguenti istruzioni hanno funzionato:

Avviare il SERVER collegando e sbloccando la partizione crittografata tramite CLIENT

Installa pacchetti obbligatori (su SERVER)

apt-get install dropbear initramfs-tools busybox

Aggiungi le tue chiavi pubbliche desiderate al file authorized_keys del SERVER

Basta copiare e incollare le chiavi pubbliche in /etc/dropbear-initramfs/authorized_keysSERVER

Crea lo script di sblocco

Crea il seguente script in /etc/initramfs-tools/hooks/crypt_unlock.sh

#!/bin/sh

PREREQ="dropbear"

prereqs() {
  echo "$PREREQ"
}

case "$1" in
  prereqs)
    prereqs
    exit 0
  ;;
esac

. "${CONFDIR}/initramfs.conf"
. /usr/share/initramfs-tools/hook-functions

if [ "${DROPBEAR}" != "n" ] && [ -r "/etc/crypttab" ] ; then
cat > "${DESTDIR}/bin/unlock" << EOF
#!/bin/sh
if PATH=/lib/unlock:/bin:/sbin /scripts/local-top/cryptroot; then
kill \`ps | grep cryptroot | grep -v "grep" | awk '{print \$1}'\`
# following line kill the remote shell right after the passphrase has
# been entered.
kill -9 \`ps | grep "\-sh" | grep -v "grep" | awk '{print \$1}'\`
exit 0
fi
exit 1
EOF

  chmod 755 "${DESTDIR}/bin/unlock"

  mkdir -p "${DESTDIR}/lib/unlock"
cat > "${DESTDIR}/lib/unlock/plymouth" << EOF
#!/bin/sh
[ "\$1" == "--ping" ] && exit 1
/bin/plymouth "\$@"
EOF

  chmod 755 "${DESTDIR}/lib/unlock/plymouth"

  echo To unlock root-partition run "unlock" >> ${DESTDIR}/etc/motd

fi

Renderlo eseguibile:

chmod +x /etc/initramfs-tools/hooks/crypt_unlock.sh

Crea un IP statico (o salta questo passaggio per usare DHCP)

Modifica /etc/initramfs-tools/initramfs.confper aggiungere (o modificare) la riga:

#format [host ip]::[gateway ip]:[netmask]:[hostname]:[device]:[autoconf]
#([hostname] can be omitted)
IP=192.168.1.254::192.168.1.1:255.255.255.0::eth0:off

Aggiorna initialramfs

update-initramfs -u

Disabilita il servizio dropbear all'avvio in modo che openssh venga usato dopo la decodifica della partizione

sudo update-rc.d dropbear disable

analisi

  • Riavvia il tuo server
  • Connettiti al tuo server tramite ssh root@192.168.1.254 [-i ~/.ssh/id_rsa]

2

Su debian 9 (stabile), questa soluzione era obsoleta. Durante l'installazione, ricevo un avviso dropbear: WARNING: Invalid authorized_keys file, remote unlocking of cryptroot via SSH won't work!e non sono riuscito a trovare le chiavi necessarie. Questo metodo è davvero molto semplice, e mi è stato spiegato sul grande canale #debian (grazie ancora):

Prima di tutto assicuratevi che busybox, dropbeare dropbear-initramfssono installati

sudo apt install busybox dropbear*

quindi aggiungi la tua chiave pubblica (la maggior parte delle volte ~/.ssh/id_rsa.pub) nel file /etc/dropbear-initramfs/authorized_keys.

Aggiorna quindi initramfsper tenere conto delle modifiche:: update-initramfs -u

È tutto!

Nota, se vuoi evitare di avere uno scontro tra le chiavi tra dropbeare openssh(condividono lo stesso IP, ma usano una chiave diversa), potresti voler inserire nel tuo client ~/.ssh/configqualcosa del genere:

Host myserver_luks_unlock
     User root
     Hostname <myserver>
     # The next line is useful to avoid ssh conflict with IP
     HostKeyAlias <myserver>_luks_unlock
     Port 22
     PreferredAuthentications publickey
     IdentityFile ~/.ssh/id_rsa

Quindi, ti connetti semplicemente usando:

ssh myserver_luks_unlock

e una volta ricevuto un prompt, digitare come suggerito dal prompt busybox:

cryptroot-unlock

e digita la tua password.

Godere!



0

Sto usando la tecnica spiegata da altri in questa pagina (SSH negli initramfs con un IPparametro del kernel per configurare la rete) da diversi anni ormai per sbloccare in remoto server Ubuntu Linux senza testa (12.02, 14.04, 16.04 e 18.04).

Sono persino arrivato al punto di sviluppare un programma Python ( sblocco-sistema remoto ) che fa lo sblocco effettivo per me, perché il processo di farlo manualmente mi è sembrato un po 'fragile e ho iniziato a temere di riavviare i miei server, quindi nello spirito di "se fa male vale la pena automatizzare" Ho codificato le mie conoscenze in Python 😇 (e questo è stato effettivamente reso molto più facile fare riavvii regolari per applicare gli aggiornamenti di sicurezza).

Da allora ho deciso di condividere anche le mie note personali sulla crittografia del disco di root remoto con il mondo. La pagina collegata contiene alcuni dettagli sulla procedura (anche alcuni suggerimenti che non sono menzionati qui) e intendo tenerlo aggiornato.

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.