ssh-copy-id and Dropbear Server

Thank you for taking the time to file a bug report.

I don't know if I fully understand the issue here. I installed dropbear inside a container, started it, and then ran ssh-copy-id on the host in order to copy my public key to the dropbear server. It got copied successfully and I was able to login via SSH without issues later.

Could you please provide reproduction steps here? Also, from your description, it doesn't seem like this is an openssh bug. But first we need to verify whether this is really an issue or not.

Since there is not enough information in your report to begin triage or to
differentiate between a local configuration problem and a bug in Ubuntu, I
am marking this bug as "Incomplete". We would be grateful if you would:
provide a more complete description of the problem, explain why you
believe this is a bug in Ubuntu rather than a problem specific to your
system, and then change the bug status back to "New".

For local configuration issues, you can find assistance here:
http://www.ubuntu.com/support/community

the problem is in this file https://github.com/openssh/openssh-portable/blob/master/contrib/ssh-
copy-id

in line 335

dropbear*)
    populate_new_ids 0
    [ "$DRY_RUN" ] || printf '%s\n' "$NEW_IDS" | \
      $SSH "$@" "$(installkeys_sh /etc/dropbear/authorized_keys)" \
      || exit 1
    ADDED=$(printf '%s\n' "$NEW_IDS" | wc -l)
    ;;

dropbear only uses the file /etc/dropbear/authorized_keys if it was patched
in the upstream version of dropbear the patch is not included

im working with some embedded systems where the file /etc/dropbear/authorized_keys is not writeable

with older ubuntu systems ssh-copy-id was working
but since that change in ssh-copy-id can't install the ssh key anymore

I don't know much about dropbear but from your explanation it does indeed sound like this is an upstream OpenSSH bug that should be reported at https://bugzilla.mindrot.org/.

I found a (somehow stale) upstream PR that addresses this:

  https://github.com/openssh/openssh-portable/pull/250

We could include this as an Ubuntu patch, but it would be better to first see it merged upstream. It may be worth pinging there.

Just to add a voice to this: we see the same things migrating from 18.04 to 22.04 while controlling some embedded ARM/Debian devices running dropbear. The key are indeed appearing in the wrong place as stated above and the log in does not proceed as expected. We can work around this for production systems, but the behaviour is confusing (and obviously not consistent between 18.04 and 22.04).

Thanks for the further clarification.

We don't carry delta for openssh in Ubuntu, and since this is a low priority bug it should really be reported against the Debian openssh package. Could you please file a bug there and post its link here?

Thanks.

This bug was fixed in the package openssh - 1:9.4p1-1ubuntu1

---------------
openssh (1:9.4p1-1ubuntu1) noble; urgency=medium

  * Merge with Debian unstable. Remaining changes:
    - debian/rules: modify dh_installsystemd invocations for
      socket-activated sshd
    - debian/openssh-server.postinst: handle migration of sshd_config options
      to systemd socket options on upgrade.
    - debian/README.Debian: document systemd socket activation.
    - debian/patches/socket-activation-documentation.patch: Document in
      sshd_config(5) that ListenAddress and Port no longer work.
    - debian/openssh-server.templates: include debconf prompt explaining
      when migration cannot happen due to multiple ListenAddress values
    - debian/.gitignore: drop file
    - debian/openssh-server.postrm: remove systemd drop-ins for
      socket-activated sshd on purge
    - debian/openssh-server.ucf-md5sum: update for Ubuntu delta
    - debian/openssh-server.tmpfile,debian/systemd/ssh.service: Move
      /run/sshd creation out of the systemd unit to a tmpfile config so
      that sshd can be run manually if necessary without having to create
      this directory by hand.
    - debian/patches/systemd-socket-activation.patch: Fix sshd
      re-execution behavior when socket activation is used
    - debian/tests/systemd-socket-activation: Add autopkgtest for systemd socket
      activation functionality.
    - d/p/test-set-UsePAM-no-on-some-tests.patch: set UsePAM=no for some tests
  * Dropped changes, fixed upstream:
    - d/p/fix-authorized-principals-command.patch: Fix the situation where
      sshd ignores AuthorizedPrincipalsCommand if AuthorizedKeysCommand
      is also set by checking if the value pointed to by the pointer
      'charptr' is NULL.
    - debian/patches/CVE-2023-38408-1.patch: terminate process if requested
      to load a PKCS#11 provider that isn't a PKCS#11 provider in
      ssh-pkcs11.c.
    - debian/patches/CVE-2023-38408-2.patch: disallow remote addition of
      FIDO/PKCS11 provider in ssh-agent.1, ssh-agent.c.
    - debian/patches/CVE-2023-38408-3.patch: ensure FIDO/PKCS11 libraries
      contain expected symbols in misc.c, misc.h, ssh-pkcs11.c, ssh-sk.c.
  * Dropped changes, affected package versions not published in supported
    releases:
    - debian/openssh-server.postint: do not try to restart systemd units,
      and instead indicate that a reboot is required
    - debian/tests/systemd-socket-activation: Reboot the testbed before starting the test
    - debian/rules: Do not stop ssh.socket on upgrade

openssh (1:9.4p1-1) unstable; urgency=medium

  * New upstream release (https://www.openssh.com/releasenotes.html#9.4p1):
    - ssh-agent(1): PKCS#11 modules must now be specified by their full
      paths. Previously dlopen(3) could search for them in system library
      directories.
    - ssh(1): allow forwarding Unix Domain sockets via ssh -W.
    - ssh(1): add support for configuration tags to ssh(1). This adds a
      ssh_config(5) "Tag" directive and corresponding "Match tag" predicate
      that may be used to select blocks of configuration similar to the
      pf.conf(5) keywords of the same name.
    - ssh(1): ...