cannot login via ssh when using dropbear in initramfs

Bug #834174 reported by Christoph Gritschenberger on 2011-08-25
82
This bug affects 14 people
Affects Status Importance Assigned to Milestone
dropbear (Debian)
Fix Released
Unknown
dropbear (Ubuntu)
Undecided
Unassigned
Precise
Undecided
Unassigned
Quantal
Undecided
Unassigned

Bug Description

Impact:
Multiarch installations of dropbear end up with broken initramfs images (without libnss*), to which users can't connect as expected.

Detailed Description
The current dropbear is broken when trying to connect to a computer with encrypted harddrive from a remote computer, to input the decrypt password, as explained, for example, here:
http://blog.nguyenvq.com/2011/09/13/remote-unlocking-luks-encrypted-lvm-using-dropbear-ssh-in-ubuntu/

Test case:
After installing dropbear in a multiarch system, it should be possible to generate a new initramfs image, for example by running update-initramfs -u, without issuing any errors.

Regression potential:
The patch supplied looks for the correct directory where the files are located, if there was a problem with this search, it might end up not copying the files, as it happens now in multiarch. So, worst case scenario: it still doesn't work, no extra harm done.

----

Original description:

I did a fresh install.
I use system encryption with LUKS (LVM-container inside encrypted parition).

I installed dropbear.
copied the ssh-key from /etc/initramfs-tools
When booting, the process stops to prompt for the password.
dropbear starts correctly, but when trying to connect I get prompted for a password.

I also modified the initrd, so that dropbear would display some debug-output (-E -F)
There I could see
[...] login attempt for nonexistent user from [...]
everytime I tried to login.

I tried this on ubuntu-11.04-server and ubuntu 10.04-server (both amd64).
It worked perfectly on 10.04

Lapin (fred-lacombe) wrote :

Same issue for me.
Reason: missing /lib/x86_64-linux-gnu/libnss-files* in ramdisk (i'm on a 64bits system)
Adding correct cp in /usr/share/initramfs-tools/scripts/init-premount/dropbear is a work-around
Dropbear scripts and docs not up to date, many other files are missing (/etc/shadow, /etc/nsswitch.conf, /etc/group...)

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in dropbear (Ubuntu):
status: New → Confirmed
Shane O'Connell (shaneoc) wrote :

The issue seems to be in /usr/share/initramfs-tools/hooks/dropbear, which contains this line:

cp /lib/libnss_* "${DESTDIR}/lib/"

The path to libnss_files seems to have changed, I think due to multiarch. If you change the line to (assuming you are using a 64-bit ubuntu):

cp /lib/x86_64-linux-gnu/libnss_* "${DESTDIR}/lib/"

Then you should be able to log into dropbear in the initramfs again. This doesn't make remote unlocking work perfectly however, as apparently there's some interaction between plymouth and the script that takes the passphrase on the console that breaks things. There's a workaround for that particular problem at:

http://blog.nguyenvq.com/2011/09/12/remote-unlocking-luks-encrypted-lvm-using-dropbear-ssh-in-ubuntu/

tags: added: multiarch
TobiasHunger (tobias-hunger) wrote :

The debian bug contains a workaround that can be dropped into /etc/initramfs-tools/hooks and does not require changing the files in /usr.

Changed in dropbear (Debian):
status: Unknown → New
Changed in dropbear (Debian):
status: New → Fix Released
Andreas Oberritter (obi++) wrote :

This issue was fixed in dropbear 2012.55-1.2 (Debian). Please update the version in Ubuntu!

Changed in dropbear (Debian):
status: Fix Released → New
Margarita Manterola (marga-9) wrote :

Hi, after some re-opening of the Debian bug, this has been fixed in Debian again.

I'm attaching here a debdiff of the fixed package. Please apply to precise as well as quantal.

The attachment "Applied fix" of this bug report has been identified as being a patch in the form of a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
Luke Yelavich (themuso) wrote :

Please have a read of https://wiki.ubuntu.com/StableReleaseUpdates for the procedure on how to get this fix into quantal-updates and precise-updates.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package dropbear - 2012.55-1.3ubuntu1

---------------
dropbear (2012.55-1.3ubuntu1) raring-proposed; urgency=low

  * Merge from Debian unstable. Remaining changes: (LP: #834174)
    - Update config.guess,sub for aarch634
    - If /dev/pts is already mounted, don't re-mount.

dropbear (2012.55-1.3) unstable; urgency=medium

  * Non-maintainer upload.
  * Fix initramfs hook when multiple variant of libc are installed.
    All credits due to Helmut Grohne for the report and the solution.
    (Closes: #682964)

dropbear (2012.55-1.2) unstable; urgency=low

  * Non-maintainer upload.
  * Unbreak initramfs hook when upgrading from Squeeze.

dropbear (2012.55-1.1) unstable; urgency=low

  * Non-maintainer upload.
  * Adjust initramfs hook to work with multi-arch. Initial patch by
    Michael Stapelberg. (Closes: #630581)
 -- Luke Yelavich <email address hidden> Wed, 14 Nov 2012 11:47:41 +1100

Changed in dropbear (Ubuntu):
status: Confirmed → Fix Released
Margarita Manterola (marga-9) wrote :

Hi,

I'm updating the debdiff to include precise-proposed as the upload distribution. I think I've followed the SRU guidelines now. Please target this for precise, thanks.

description: updated
Changed in dropbear (Debian):
status: New → Fix Released
Benjamin Drung (bdrung) wrote :

Margarita, one thing is missing. We need to make sure to not run into an regression when upgrading. The package is fixed in raring. If we fix the package in precise, user will run into a regression when upgrading from precise to quantal. So please also provide a fix for quantal-proposed.

Margarita Manterola (marga-9) wrote :

Hi,

I'm attaching the patch for quantal's version. It's basically the same patch, the changed part is the changelog version number and distribution.

Benjamin Drung (bdrung) wrote :

Thanks. I have uploaded your fix to precise-proposed and quantal-proposed.

Clint Byrum (clint-fewbar) wrote :

The patch contains two changes in behavior:

- cp /lib/libnss_* "${DESTDIR}/lib/"
+ LIBC_DIR=$(ldd /usr/sbin/dropbear | sed -n -e 's,.* => \(/lib.*\)/libc\.so\..*,\1,p')
+ for so in $(find "${LIBC_DIR}" -name 'libnss_compat*'); do
+ copy_exec "${so}"
+ done
+ echo 'passwd: compat' > "${DESTDIR}/etc/nsswitch.conf"

The first one, doing the copy_exec, looks good.

But that last line, echo passwd: compat to nsswitch.conf, looks like a totally unrelated and undocumented change.

Margarita, can you explain how this is related to the current bug? If its not truly related, either a new bug report needs to be opened documenting the fix's SRU worthiness, or the change needs to be removed. Either way, its likely this will need to be uploaded again.

Margarita Manterola (marga-9) wrote :

I can't explain since I didn't create the patch. I just ported it from Debian. This is the patch that was applied in Debian, and the discussion is in the Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630581

I have re-read the bug log and the only reference that I could find that was slightly related to this part was:
" It only hit me after the first [upload] that I had not verified upgrades from Squeeze, and indeed, they were broken. "

So, it looks like it was something needed for the upgrade from Squeeze to Wheezy in Debian. I'm not sure if this also affects Ubuntu in any way, it's possible that it doesn't.

Do you want me to prepare an upload without this line?

Clint Byrum (clint-fewbar) wrote :

I really think we need to understand the impact of that patch before accepting the current upload. Please explain in the bug description above (under regression potential) what this flag does and how users can test that it did not introduce a regression. Thanks!

Margarita Manterola (marga-9) wrote :

So, I asked the Debian Developer that did the original patch, he explained that given that there were no other authentication methods, the only method that makes sense is the 'compat' one.

I tried the results with and without that line, and it made no difference. As I said, I'm happy to prepare new packages without that line, it's basically a no-op.

Regarding the impact, the current dropbear doesn't work in initramfs images in the described user case (trying to connect from a remote machine to decrypt the disk), and this patch touches only the initramfs hook, so I don't think it can get more broken than that. The worse that could happen is that it still doesn't work.

description: updated
Steve Langasek (vorlon) wrote :

+ LIBC_DIR=$(ldd /usr/sbin/dropbear | sed -n -e 's,.* => \(/lib.*\)/libc\.so\..*,\1,p')
+ for so in $(find "${LIBC_DIR}" -name 'libnss_compat*'); do
+ copy_exec "${so}"
+ done
+ echo 'passwd: compat' > "${DESTDIR}/etc/nsswitch.conf"

FWIW, this looks unnecessarily indirect; the libnss_compat should always be found in the same directory as libc itself, since they are both part of glibc, so the 'find' is a needless traversal of the /lib/* directory. But as this is the solution implemented already in Debian and raring, it's not a blocker for the SRU.

Steve Langasek (vorlon) wrote :

Actually, it's not clear to me why we would want to set passwd to 'compat', which differs from 'files' only in NIS handling which would seem to be irrelevant in the initramfs environment. Both plymouth and mountall already have initramfs hooks in Ubuntu which set up /etc/nsswitch.conf to use 'passwd: files'; and the 'compat' nss module only works if the 'files' nss module is already present, which this initramfs hook doesn't guarantee to be the case at all.

The only reason this would *happen* to work is because cryptsetup on the system triggers plymouth's initramfs hook, which pulls in this nss configuration with nss_files. So I think the updated dropbear hook is actually broken and not appropriate for SRU as is. This needs to be made to work like the plymouth initramfs hook, using nss_files instead for consistency.

Margarita Manterola (marga-9) wrote :

I was about to upload a new diff, but before that I wanted to do some complete testing of the thing to make sure that it really worked.

What I found out is that this patch isn't really needed that badly anymore, because both mountall and plymouth include the hooks that copy the correct libnss files. Without this patch, when you regenerate the initramfs image, you get an error message (libnss files are not found), but that error message is pretty harmless, since the files are being copied from the right location anyway.

The original report was from 2011 and I'm guessing that back then neither plymouth nor mountall included the snippet that copies the correct files. At some point in the middle this was fixed, and only the error message of the files not being found in the dropbear hook remained.

Having found this, I consider this bug just a cosmetic issue that is not worth an SRU, and thus should be closed as "Won't fix" for precise and quantal.

Sorry to have wasted your and my time in this, I should have tested better in the first place.

Steve Langasek (vorlon) wrote :

plymouth definitely included the code to copy nss files at that time. However, plymouth is an /optional/ component of the initramfs; this code may not always be triggered.

dropbear still has a bug here.

Margarita Manterola (marga-9) wrote :

Alright, this is a fixed patch, changing compat to files. Feel free to ignore it anyway, I think this is such a corner case that nobody will really be affected.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in dropbear (Ubuntu Precise):
status: New → Confirmed
Changed in dropbear (Ubuntu Quantal):
status: New → Confirmed
James Michael Fultz (croooow) wrote :

I'm running Precise with a setup similar to that in the original bug report and seem to be experiencing the same problem. Namely, I am prompted for a password when connecting but should not be as I've configured for public key authentication. I've also tried Margarita's patch and behaviour appears to be the same.

Rolf Leggewie (r0lf) wrote :

quantal has seen the end of its life and is no longer receiving any updates. Marking the quantal task for this ticket as "Won't Fix".

Changed in dropbear (Ubuntu Quantal):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.