SSH public key authentication: wrong default directory

[Grandma-Betty]

When setting up passwordless SSH authentication for Batocera, from a remote client, you would do it like this: Create a key first: ssh-keygen Then copy the key over to batocera: ssh-copy-id root@<batocera>

But this does not work. Somehow the key is being copied to... /userdata/system/ssh/authorized_keys ...instead of: /userdata/system/.ssh/authorized_keys Which obviously does not work as the wrong default folder is being taken. I don't understand why the /userdata/system/ssh path does even exists.

To make it work after copying over the SSH key, as a workaround you can execute this on the Batocera command line: cat /userdata/system/ssh/authorized_keys >> /userdata/system/.ssh/authorized_keys But this is only a workaround. Could you please change the default SSH directory to /userdata/system/.ssh? And maybe remove the /userdata/system/ssh directory completely if it's not necessary?

Thank you!

[liberodark]

That strange why we use /userdata/system/ssh and not /userdata/system/.ssh

@lbrpdx you have any idea ?

[Hew-ux]

/userdata/system/ssh is used by Dropbear, it is required on architectures that use it. But maybe it would be possible to remove it on architectures that do not use Dropbear.

[n2qz]

/userdata/system/ssh is the location for the system keys, and /userdata/system/.ssh is the location for the root user keys. Maintaining this separation has value in not violating the "principle of least astonishment" for end users, so I'd prefer to keep both.

The "ssh-copy-id" script contains this snippet:

  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)
    ;;

On Batocera, /etc/dropbear is a symlink to /userdata/system/ssh, so the ssh-copy-id snippet (which is not under our control) causes the authorized_keys file to land in /userdata/system/ssh/authorized_keys, which is the incorrect behavior described in this issue.

Creating a symlink allows the authorized_keys file to end up in the /userdata/system/.ssh directory instead:

ln -s ../.ssh/authorized_keys /userdata/system/ssh/authorized_keys

It should be straightforward to create this symlink on freshly installed systems. A postupgrade script (if Batocera supports such a script) could be used to fix up existing systems on the next upgrade.

[n2qz]

I think the symlink creation can go in S12populateshare and that will cover both new installs and upgrades.