Can't enable encryption (LUKS/FDE) when installing via VNC

[smaccona]

When installing to a Raspberry Pi Model B+ with vncinstall enabled, encrypting the disk doesn't work (presumably because it tries to switch you to a secure text console to have you enter your password and there's no way to display that console when connected via VNC). On the VNC client, I see it pausing for a while at "Formatting data partition (ext4 nodiscard)" and then presumably the console request for the password times out and I see "Error Formatting data partition (ext4 nodiscard)".

Is there any workaround for this? I have serial console access to the Pi if that helps.

[maxnet]

No, we do not support entering passwords over VNC for security reasons.

[maxnet]

Regarding serial console, that probably works if you change the calls to openvt

https://github.com/maxnet/berryboot/blob/berryboot2.0/BerrybootGUI2.0/driveformatthread.cpp#L295 https://github.com/maxnet/berryboot/blob/berryboot2.0/BerrybootGUI2.0/driveformatthread.cpp#L305 https://github.com/maxnet/berryboot/blob/berryboot2.0/BerrybootGUI2.0/bootmenudialog.cpp#L679

to something else that can tie the program to a serial console (getty?) But it is not something supported out-of-the-box.

[smaccona]

Thanks for the repo links.

To others with this problem: the easiest workaround (apart from, obviously, connecting a screen & keyboard to the Pi and not using vncinstall) may be to install non-encrypted, then move the SD card to another computer which supports LUKS, clone the unencrypted partition, create an encrypted partition on the SD card, mount it and dd your cloned copy of the original partition back onto it.

There may be some juggling to do to get it to mount properly and present a password prompt for unlocking the encrypted partition on boot, but it was always my intention to have initrd kick off a limited dropbear ssh daemon to allow for unlocking the partition over the network so I would have needed to jump through some extra hoops anyway. Once I try this out, I will post here in case others need this solution.

[maxnet]

the easiest workaround (apart from, obviously, connecting a screen & keyboard to the Pi and not using vncinstall) may be to install non-encrypted, then move the SD card to another computer which supports LUKS, clone the unencrypted partition, create an encrypted partition on the SD card, mount it and dd your cloned copy of the original partition back onto it.

Sounds like a lot of work, just to avoid plugging in a keyboard...

There may be some juggling to do to get it to mount properly and present a password prompt for unlocking the encrypted partition on boot, but it was always my intention to have initrd kick off a limited dropbear ssh daemon to allow for unlocking the partition over the network

Just added support for unlocking through SSH in b7c87deada91e0ab80ece39c937b87171b4df708 You still need the keyboard during installation, don't see that as a priority to fix.

[tristan-k]

@maxnet Can you explain further how to setup the ssh access. Is it possible to define a fixed ip-address?

[maxnet]

@tristan-k Add to cmdline.txt:

ipv4=192.168.88.88/255.255.255.0/192.168.88.1 ssh_authorized_key="your ssh pulic key"

[tristan-k]

Thanks! I did that but I'm getting a error:

$ ssh -v tristank@192.168.1.17
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 102: Applying options for *
debug1: Connecting to 192.168.1.17 [192.168.1.17] port 22.
debug1: Connection established.
debug1: identity file /Users/tristank/.ssh/id_rsa type 1
debug1: identity file /Users/tristank/.ssh/id_rsa-cert type -1
debug1: identity file /Users/tristank/.ssh/id_dsa type -1
debug1: identity file /Users/tristank/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version dropbear_2014.65
debug1: no match: dropbear_2014.65
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: RSA f0:d4:a6:32:3c:f9:04:1c:4f:87:b3:3b:20:d5:7b:91
debug1: Host '192.168.1.17' is known and matches the RSA host key.
debug1: Found key in /Users/tristank/.ssh/known_hosts:6
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/tristank/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/tristank/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).

This is how my cmdline.txt looks like: https://0b.tristank.de/?facb2bc210c2839b#16cTwC1mmFNbYzYI5Y0jrPslcUFVLefV+z89M9vwMk8=

Any suggestions? How to check if the ssh-key is added?

[maxnet]

Boot an OS manually. cat /proc/cmdline

Verify the line is not truncated, which can happen if your cmdline.txt gets too long.

[tristan-k]

No it isn't truncated. I checked. Anything else? Could be related to the quotation marks? Which user should I login with?

[maxnet]

Which user should I login with?

root

$ ssh -v tristank@192.168.1.17

which might indeed be your problem... Try: ssh root@192.168.1.17

[tristan-k]

Now it works, of course I have to use root :-/ Also a reminder for people editing the cmdline.txt on mac os x: don't use textedit.app, because it messes up the quotation marks. Thanks for your patience. One more question: "192.168.88.1" is the gateway address - right? Are there detailed instructions available for the network config of the cmdline.txt? http://elinux.org/RPiconfig doesnt go into that.

ipv4=192.168.88.88/255.255.255.0/192.168.88.1

[maxnet]

Yes, last parameter is gateway. Options are handled by Berryboot. It is not a standard Linux parameter.

http://www.berryterminal.com/doku.php/berryboot/headless_installation

Or use the GUI:

Hidden under "Add OS" -> "Network settings"

[tristan-k]

Thank you for your support!