Разблокировка через SSH полностью зашифрованного ubuntu-server 12.04 Сравнение версий

Различия

Здесь показаны различия между двумя версиями данной страницы.

Ссылка на это сравнение

Предыдущая версия справа и слева Предыдущая версия
Следующая версия
Предыдущая версия
wiki:unlock_luks_ssh [2013/11/27 22:02]
[Обход бага аутентификации #834174]
wiki:unlock_luks_ssh [2019/01/04 01:55] (текущий)
[Ссылки]
Строка 1: Строка 1:
 ====== Разблокировка через SSH полностью зашифрованного ubuntu-server 12.04====== ====== Разблокировка через SSH полностью зашифрованного ubuntu-server 12.04======
-За основу взят ​перевод ​статьи [[http://​hacksr.blogspot.ru/​2012/​05/​ssh-unlock-with-fully-encrypted-ubuntu.html|SSH unlock with fully encrypted ubuntu 12.04 server]] by Christoph Gritschenberger (HacksR), с последующими испытаниями,​ некоторыми изменениями и дополнениями,​ поскольку в оригинальном виде заработало не всё.+{{:​wiki:​hdd_crypt.png?​250 |}}За основу взята статья [[http://​hacksr.blogspot.ru/​2012/​05/​ssh-unlock-with-fully-encrypted-ubuntu.html|SSH unlock with fully encrypted ubuntu 12.04 server]] by Christoph Gritschenberger (HacksR), с последующими испытаниями,​ некоторыми изменениями и дополнениями,​ поскольку в оригинальном виде заработало не всё.
  
 При работе на сервере с полностью зашифрованной системой зачастую нежелательно вводить пароль с локальной клавиатуры. Однако,​ настройка разблокировки через SSH не проста,​ так как есть несколько проблем которые необходимо обойти,​ прежде чем это заработает. Здесь собрано полное руководство как всё настроить. При работе на сервере с полностью зашифрованной системой зачастую нежелательно вводить пароль с локальной клавиатуры. Однако,​ настройка разблокировки через SSH не проста,​ так как есть несколько проблем которые необходимо обойти,​ прежде чем это заработает. Здесь собрано полное руководство как всё настроить.
  
 Все действия производились на <<​Ubuntu-Server 12.04.3 LTS "​Precise Pangolin"​ - Release i386>>​ установленном на носитель виртуальной машины KVM размеченный по методу <<​Авто - использовать весь диск с шифрованным LVM>>​. Все действия производились на <<​Ubuntu-Server 12.04.3 LTS "​Precise Pangolin"​ - Release i386>>​ установленном на носитель виртуальной машины KVM размеченный по методу <<​Авто - использовать весь диск с шифрованным LVM>>​.
 +
 +Всё описанное ниже, оказалось справедливо также для Ubuntu 15.04 с загрузкой UEFI и таблицей разделов GPT.
  
 Разблокировка корневого раздела выполняется в <<​initial ramdisk>>​ который загружается с незашифрованного раздела <</​boot>>​. Для того что бы получить доступ через ssh, необходимо иметь ssh-сервер в этом начальном RAM диске. Это будет легковесный сервер **dropbear**. Устанавливаем его, а также openssh-server для последующего подключения к расшифрованной системе:​ Разблокировка корневого раздела выполняется в <<​initial ramdisk>>​ который загружается с незашифрованного раздела <</​boot>>​. Для того что бы получить доступ через ssh, необходимо иметь ssh-сервер в этом начальном RAM диске. Это будет легковесный сервер **dropbear**. Устанавливаем его, а также openssh-server для последующего подключения к расшифрованной системе:​
 ======Установка и настройка ssh-сервера====== ======Установка и настройка ssh-сервера======
 <code bash>​sudo apt-get install openssh-server dropbear</​code>​ <code bash>​sudo apt-get install openssh-server dropbear</​code>​
-Установщик dropbear автоматически использует ключи RSA и DSA предоставляемые OpenSSH. Он также автоматически интегрируется в initrd. При этом, он генерирует отдельную пару ключей для начального рамдиска,​ что может быть нежелательно,​ поскольку при подключении каждый раз будет выдавать ошибки <<​WARNING:​ REMOTE HOST IDENTIFICATION HAS CHANGED!>>​ Поэтому автор предлагает для начального рамдиска ​ использовать системную пару ключей:​+Установщик dropbear автоматически использует ключи RSA и DSA предоставляемые OpenSSH. Он также автоматически интегрируется в initrd. При этом, он генерирует отдельную пару ключей для начального рамдиска,​ что может быть нежелательно,​ поскольку при подключении каждый раз будет выдавать ошибки <<​WARNING:​ REMOTE HOST IDENTIFICATION HAS CHANGED!>>​ Поэтому ​[[http://​www.blogger.com/​profile/​00040086117502106907|автор]] предлагает для начального рамдиска ​ использовать системную пару ключей:​
 <code bash>​sudo cp /​etc/​dropbear/​dropbear_* /​etc/​initramfs-tools/​etc/​dropbear/</​code>​ <code bash>​sudo cp /​etc/​dropbear/​dropbear_* /​etc/​initramfs-tools/​etc/​dropbear/</​code>​
 На практике этого оказалось недостаточно. Что бы избежать необходимости всякий раз чистить файл <<​known_hosts>>,​ был использован конвертор dropbearconvert,​ которым хостовый ключ ssh_host_rsa_key был преобразован в формат dropbear и использован в initrd: На практике этого оказалось недостаточно. Что бы избежать необходимости всякий раз чистить файл <<​known_hosts>>,​ был использован конвертор dropbearconvert,​ которым хостовый ключ ssh_host_rsa_key был преобразован в формат dropbear и использован в initrd:
Строка 16: Строка 18:
 Так как initrd будет содержать только пользователя root, последний должен быть активирован:​ Так как initrd будет содержать только пользователя root, последний должен быть активирован:​
 <code bash>​sudo passwd root</​code>​ <code bash>​sudo passwd root</​code>​
-При желании,​ после обновления initramfsпользователя root можно будет отключить.+При желании,​ после обновления initramfs пользователя root можно будет отключить.
 ======Настройка сетевых параметров для initrd====== ======Настройка сетевых параметров для initrd======
 Если сервер получает IP-адрес автоматически (DHCP), пропускаем этот шаг, в противном случае мы должны указать IP конфигурацию в строке загрузки ядра. Для этого отредактируем в файле <</​etc/​default/​grub>>​ строку:​ Если сервер получает IP-адрес автоматически (DHCP), пропускаем этот шаг, в противном случае мы должны указать IP конфигурацию в строке загрузки ядра. Для этого отредактируем в файле <</​etc/​default/​grub>>​ строку:​
Строка 26: Строка 28:
 <​code>​GRUB_CMDLINE_LINUX="​ip=192.168.122.192::​192.168.122.1:​255.255.255.0::​eth0:​none"</​code>​ <​code>​GRUB_CMDLINE_LINUX="​ip=192.168.122.192::​192.168.122.1:​255.255.255.0::​eth0:​none"</​code>​
 Обновим конфигурацию grub: Обновим конфигурацию grub:
-<​code>​update-grub</​code>​+<​code ​bash>sudo update-grub</​code
 +<note tip>​При работе с десктопом выяснилось,​ что сетевые параметры всё же лучше указывать явно в виде <​code>​ip=<​client-ip>:<​server-ip>:<​gw-ip>:<​netmask>:<​hostname>:<​device>:<​autoconf>:<​dns0-ip>:<​dns1-ip></​code>​иначе настройки,​ полученные по dhcp, каким то образом передаются в NetworkManager и создают новое соединение "​настроенное вручную"​ не вполне корректно (без указания DNS сервера) </note>
 ======Настройка авторизации по открытому ключу====== ======Настройка авторизации по открытому ключу======
 Если мы захотим проходить аутентификацию [[/​wiki/​ssh=#​аутентификация_на_основе_ssh2_rsa-ключей|с помощью открытого ключа]],​ то должны сделать что бы рамдиск принимал его: Если мы захотим проходить аутентификацию [[/​wiki/​ssh=#​аутентификация_на_основе_ssh2_rsa-ключей|с помощью открытого ключа]],​ то должны сделать что бы рамдиск принимал его:
-<code bash>​sudo ~/​.ssh/​authorized_keys /​etc/​initramfs-tools/​root/​.ssh/​autorized_keys</​code>​+<code bash>​sudo ​cp ~/​.ssh/​authorized_keys /​etc/​initramfs-tools/​root/​.ssh/​authorized_keys</​code>​
 ======Обход бага аутентификации #​834174====== ======Обход бага аутентификации #​834174======
 Из-за [[https://​bugs.launchpad.net/​ubuntu/​+source/​dropbear/​+bug/​834174|бага ubuntu]] аутентификация всегда будет терпеть неудачу при попытке логина в систему начального рамдиска. Обход бага предоставлен Alex Roper: Из-за [[https://​bugs.launchpad.net/​ubuntu/​+source/​dropbear/​+bug/​834174|бага ubuntu]] аутентификация всегда будет терпеть неудачу при попытке логина в систему начального рамдиска. Обход бага предоставлен Alex Roper:
Строка 56: Строка 59:
 Сохраняем файл и делаем его исполняемым:​ Сохраняем файл и делаем его исполняемым:​
 <code bash>​sudo chmod +x /​etc/​initramfs-tools/​hooks/​fix-login.sh</​code>​ <code bash>​sudo chmod +x /​etc/​initramfs-tools/​hooks/​fix-login.sh</​code>​
-После обновления initramfs, вы можете перезагрузиться и убедиться что логин через SSH работает:<​note>​Вот именно этого ​мне ​добиться не удалось. Поэтому пришлось использовать аутентификацию по открытому ключу. Но и она без этого файла не работала </​note>​ +После обновления initramfs, вы можете перезагрузиться и убедиться что логин через SSH работает:<​note>​Вот именно этого добиться не удалось. Поэтому пришлось использовать аутентификацию по открытому ключу, которая без этого файла ​также ​не работала </​note>​ 
-<code bash>​sudo update-initramfs -u</​code>​+<code bash>​sudo update-initramfs -u</code><​note>​для i386 здесь будет ошибка <<​cannot stat '/​lib/​libnss_*':​ No such file or directory>>​. Возможно она ни на что не влияет,​ но что бы её устранить поменяем строку в файле <</​usr/​share/​initramfs-tools/​hooks/​dropbear>>​ <​code>​cp /​lib/​libnss_* "​${DESTDIR}/​lib/"</​code>​ 
 +на 
 +<​code>​cp /​lib/​i386-linux-gnu/​libnss_* "​${DESTDIR}/​lib/"</​code>​ </note>
 <code bash>​sudo reboot</​code>​ <code bash>​sudo reboot</​code>​
 Однако,​ ввод пароля для зашифрованного тома работать не будет, так как [[https://​bugs.launchpad.net/​ubuntu/​+source/​cryptsetup/​+bug/​595648|баг плимута]] блокирует ввод пароля другими способами. Таким образом,​ требуется обходной путь: Однако,​ ввод пароля для зашифрованного тома работать не будет, так как [[https://​bugs.launchpad.net/​ubuntu/​+source/​cryptsetup/​+bug/​595648|баг плимута]] блокирует ввод пароля другими способами. Таким образом,​ требуется обходной путь:
Строка 108: Строка 113:
 fi</​code>​ fi</​code>​
 Сохраняем файл и делаем исполняемым:​ Сохраняем файл и делаем исполняемым:​
-<code bash>​sudo chmod +x /​etc/​initramfs-tools/​hooks/​crypt_unlock</​code>​+<code bash>​sudo chmod +x /​etc/​initramfs-tools/​hooks/​crypt_unlock.sh</​code>​
 Обновим initramfs и перезагрузимся:​ Обновим initramfs и перезагрузимся:​
-<code bash>​sudo update-initramfs-u;​sudo reboot</​code>​+<code bash>​sudo update-initramfs -u; sudo reboot</​code>​
 ======Использование====== ======Использование======
 Теперь,​ когда загрузится наш начальный рамдиск,​ мы можем подключиться к серверу ssh: Теперь,​ когда загрузится наш начальный рамдиск,​ мы можем подключиться к серверу ssh:
 <code bash>ssh root@ip-my-server</​code>​ <code bash>ssh root@ip-my-server</​code>​
 увидеть приглашение:​ <<To unlock root-partition run unlock>>​ увидеть приглашение:​ <<To unlock root-partition run unlock>>​
-ввести команду<​code bash>​unlock</​code>​+и ввести команду<​code bash>​unlock</​code>​
 и разблокировать зашифрованный том: и разблокировать зашифрованный том:
 <​code>​Unlocking the disk /​dev/​disk/​by-uuid/​bc4fc639-3361-4fca-9b70-e18bab14b93f (sda5_crypt) <​code>​Unlocking the disk /​dev/​disk/​by-uuid/​bc4fc639-3361-4fca-9b70-e18bab14b93f (sda5_crypt)
Строка 131: Строка 136:
   * [[http://​forum.ubuntu.ru/​index.php?​topic=232173.0|Обсуждение статьи на форуме]]   * [[http://​forum.ubuntu.ru/​index.php?​topic=232173.0|Обсуждение статьи на форуме]]
   * [[http://​hacksr.blogspot.ru/​2012/​05/​ssh-unlock-with-fully-encrypted-ubuntu.html|SSH unlock with fully encrypted ubuntu 12.04 server ]]   * [[http://​hacksr.blogspot.ru/​2012/​05/​ssh-unlock-with-fully-encrypted-ubuntu.html|SSH unlock with fully encrypted ubuntu 12.04 server ]]
 +  * [[http://​blog.neutrino.es/​2011/​unlocking-a-luks-encrypted-root-partition-remotely-via-ssh/​|Unlocking a LUKS encrypted root partition remotely via SSH]]
 +  * [[https://​help.ubuntu.ru/​wiki/​remote_unlock_ssh|Удаленная разблокировка зашифрованного корневого раздела ubuntu-server 18.04 через SSH]]
   * [[FIXME]]   * [[FIXME]]
  
-{{tag>unlock_luks_ssh}}+ 
 +{{tag>unlock luks ssh безопасность шифрование}}