Ubuntu
autopkgtest package

FFE: Provide ssh access to Qemu testbed for easier test debugging

Bug #1305135 reported by Martin Pitt
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
autopkgtest (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

I just uploaded autopkgtest 2.14.1 to Debian and I'd like to get it into trusty. Annotated changelog:

autopkgtest (2.14.1) unstable; urgency=medium

  * tools/adt-buildvm-ubuntu-cloud: Enable ssh login with passwords.

That's http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=commitdiff;h=3a424e7ac and really should be treated as a bug fix. cloud-init disables ssh password login by default, this enables it again. These are just local test VMs which are totally open for outside root access, so limiting ssh logins isn't any security issue. But it prevents easy ssh login for debugging test failures.

autopkgtest (2.14) unstable; urgency=medium

  * lxc: Greatly simplify bind mounting of shared tmp dir using the
    lxc-start -s option.

I originally had a rather complicated approach to do this with poking in LXC's directories directly: http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=commitdiff;h=5fbbe3f05 . In bug 1304309 Stéphane showed me how to do this properly, so this change simplifies and robustifies this a lot again:

  http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=commitdiff;h=70af21afa417f

This is covered by automatic tests.

  * adt-virt-qemu: Forward VM's ssh port 22 to the first free localhost port
    starting from 10022. When finding one, suggest connecting to the VM with
    an appropriate ssh command on --shell.

This is http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=commitdiff;h=9a193eb76 and a new feature. I tested this extensively, and IMHO it is low risk. Logging into the testbed with ssh is much more comfortable than with nc or even minicom, as the latters have relatively limited terminal capabilities (e. g. byobu doesn't work). Also, it's rare to find minicom on production machines that host autopkgtests, but ssh is available pretty much everywhere.

See original description
Martin Pitt (pitti)
description: updated
Revision history for this message
Martin Pitt (pitti) wrote :

I synced the package into unapproved. Feel free to reject if you think that it's unappropriate at this time.

Revision history for this message
Adam Conrad (adconrad) wrote :

Looks sane to me, accepting.

Martin Pitt (pitti)
Changed in autopkgtest (Ubuntu):
status: New → Fix Released
Revision history for this message
Dave Walker (davewalker) wrote :

Martin, how confident are you that this doesn't cause any exposure to users using the same process.. but potentially exposing the vm to a LAN or worse, public?

There seems to be no clear warning that not just the stock default username is ubuntu, but with adt the password is now the same.

I'm sure this is fine.. but as you can imagine, it would be wholly embarrasing if this did cause and exposure.. so can you confirm how this cannot happen?

Thanks.

Revision history for this message
Martin Pitt (pitti) wrote :

@Dave: I don't know what would expose the VMs to a public LAN; they don't use a veth or anything which would connect them to a real interface. You can configure qemu to do that, but adt-run doesn't as it is not necessary.

As for the VM itself, there is no security at all there. There is a root shell listening on the VM's tty1 which is used as the adt-run control channel from outside. Any more refined method to access the VM is just a matter of convenience (sensible terminal capabilities, pre-installed programs), not security. So yeah, don't run that on VMs which have anything secret in it :-)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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