[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: howto remote unlock encrypted root fs



On Fri, 15 Jun 2012, Richard Ray wrote:

On Fri, 15 Jun 2012, Nebojša Ćosić wrote:


On Fri, 15 Jun 2012, Bj?rn Wetterbom wrote:

Have you executed "update-initramfs -u" after adding the key to
authorized_keys?


Yes and to be sure I opened the new ramdisk to make sure.



On Fri, Jun 15, 2012 at 12:33 PM, kqt4at5v@gmail.com <kqt4at5v@gmail.com>wrote:

I have a Gurplug running Wheezy from a usb harddrive with an encrypted
root fs. No problems there. I am trying to get remote unlocking set up as
described in /usr/share/doc/cryptsetup/**README.remote.gz. Everything
seems to be working as described except dropbear will not accept publickey
authentication and ask for a password. The authorized_keys file contains
public keys that I know work. I read a bug report that plymouth was a
culpret causing this problem but I have no plymouth nor can I find it.
Maybe that is the problem. Here is the attempted login transcript

]$ ssh -v  root@192.168.1.113
OpenSSH_5.3p1 Debian-3ubuntu7, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /home/rray/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.1.113 [192.168.1.113] port 22.
debug1: Connection established.
debug1: identity file /home/rray/.ssh/identity type -1
debug1: identity file /home/rray/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-**2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/rray/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version
dropbear_2012.55
debug1: no match: dropbear_2012.55
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu7
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: Host '192.168.1.113' is known and matches the RSA host key.
debug1: Found key in /home/rray/.ssh/known_hosts:78
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/rray/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/rray/.ssh/identity
debug1: Trying private key: /home/rray/.ssh/id_dsa
debug1: Next authentication method: password
root@192.168.1.113's password:


Richard


--
To UNSUBSCRIBE, email to debian-arm-REQUEST@lists.**debian.org<debian-arm-REQUEST@lists.debian.org>
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
Archive: http://lists.debian.org/**alpine.DEB.2.00.1206150521350.**
3036@tehzcl2.tehzcl-arg<[🔎] alpine.DEB.2.00.1206150521350.3036@tehzcl2.tehzcl-arg">http://lists.debian.org/[🔎] alpine.DEB.2.00.1206150521350.3036@tehzcl2.tehzcl-arg>





You have to double check access rights and ownership for both .ssh/
(0700) and authorized_keys (0600), or dropbear will just silently
ignore keys


A little more info. I changed line 35 in /usr/share/initramfs-tools/scripts/init-premount/dropbear
from /sbin/dropbear to /sbin/dropbear -E and got a little more info.

[   21.588301] sd 1:0:0:0: [sda] No Caching mode page present
[   21.593814] sd 1:0:0:0: [sda] Assuming drive cache: write through
[   21.599952] sd 1:0:0:0: [sda] Attached SCSI disk
done.
Unlocking the disk /dev/disk/by-uuid/c34f5d53-8365-469a-aeb0-eb840ac0cc56 (sda2_crypt) Enter passphrase: [149] Jun 15 13:37:35 Child connection from 192.168.1.101:43054 [149] Jun 15 13:37:35 Login attempt for nonexistent user from 192.168.1.101:43054


And I am trying to login using

ssh -v  root@192.168.1.113

Where to look now?


Got it. Changed line 30 in file /usr/share/initramfs-tools/hooks/dropbear from
cp /lib/libnss_* "${DESTDIR}/lib/"
to
cp /lib/arm-linux-gnueabi/libnss_* "${DESTDIR}/lib/"
I can login and unlock the fs remotely. Now, I have a third encrypted fs with user data and the request for the passphrase gets deferred until after dropbear has terminated. What might be good way to fix this.

Richard

Reply to: