DietPi-Software | Dropbear: ssh-copy-id copies authorized_keys to wrong location

mwip commented 3 years ago

Required Information

DietPi version

G_DIETPI_VERSION_CORE=7
G_DIETPI_VERSION_SUB=1
G_DIETPI_VERSION_RC=2
G_GITBRANCH='master'
G_GITOWNER='MichaIng'

Distro version
```
buster
```

Kernel version

Linux DietPi 5.10.17-v8+ #1414 SMP PREEMPT Fri Apr 30 13:23:25 BST 2021 aarch64 GNU/Linux

SBC model
```
RPi 3 Model B (aarch64)
```
Power supply used 5V 1.5A RAVpower
SDcard used SanDisk of some sort

Additional Information (if applicable)

Software title | dropbear
Was the software title installed freshly or updated/migrated? Yes, default from the image
Can this issue be replicated on a fresh installation of DietPi? It's a fresh install

Steps to reproduce

create a ssh-rsa key on some machine using ssh-keygen
copy the ssh-key to your dietpi using ssh-copy-id root@your-dietpi-hostname-or-ip
enter the password for the root user
try to log in using ssh root@your-dietpi-hostname-or-ip

Expected behaviour

I would expect, NOT being prompted for a password.

Actual behaviour

I am being prompted for the root password

How I solved it

The authorized key is placed in /etc/dropbear/authorized_keys
However, it seems, for the root user at least, this file is not respected for key-based authorization.
I could login sucessfully after copying /etc/dropbear/authorized_keys to /root/.ssh/authorized_keys

Note: Full disclosure, I'm no expert on either dropbear or (ssh-)security. So unless this is verified, checked or even solved I do not encourage future visitors of this issue to reproduce the above solution. It is just meant to demonstrate one possible solution.

Ideas for a solution

either add /etc/dropbear/authorized_keys to the list of files checked for authorized keys,
or put the keys authorized by ssh-copy-id in correct file.

MichaIng commented 3 years ago

Many thanks for your report.

Where is the info from that /etc/dropbear/authorized_keys is the correct place? That AFAIK never was correct and it does not make sense either. You login with a specific user, hence the key must be located in a directory which is only accessible for this one user, which is its home directory, not a system world-readable directory like in /etc. ~/.ssh/authorized_keys is used by OpenSSH as well, and it's reasonable that Dropbear and every other SSH server follow that standard.

Or do you mean that ssh-copy-id is copying the local key automatically to that wrong location? It would be an external bug in the openssh-client package then, installed on the client system. In either way, we have no control over where Dropbear is reading the keys from, nor where ssh-copy-id is putting them.

Little research: It seems like OpenWRT has a Dropbear build that requires the file at /etc/dropbear/authorized_keys. But that is no Dropbear default, but likely a custom build option used by OpenWRT, as the router is meant to be a single root user system anyway (not saying that it's good to break standards only for that reason). It would be damn wrong if ssh-copy-id would have adapted to that OpenWRT build now 😄.

mwip commented 3 years ago

Indeed, ssh-copy-id put the keys in the wrong location. I don't know where this location is defined or even standardized and totally agree, that the key should be in any reference to the user it was authorized for. I found some mentions over at StackExchange (to be taken with a grain of salt, o/c) but was not able to find any documentaion on dropbear (aside from dropbear --help resulting in an error and spitting out some options)

MichaIng commented 3 years ago

Lol, the same StackExchange I was just reading 😄. That is about OpenWRT indeed (see my edit above).

The man page clearly states ~/.ssh/authorized_keys: https://manpages.debian.org/dropbear

What is your client system? DietPi or Debian as well? Which version, Stretch or Buster?

mwip commented 3 years ago

Sorry for missing the debian man page... man dropbear was non-existant so I figured there might be no man page whatsoever... Maybe this would be indicative of that dietpi is using some minimal build of dropbear, that even strips out the man page?

I am using Arch on my clients with OpenSSH I tried it with.

uname -a
Linux bifrost 5.10.35-1-lts #1 SMP Fri, 07 May 2021 11:37:18 +0000 x86_64 GNU/Linux

ssh -V
OpenSSH_8.6p1, OpenSSL 1.1.1k  25 Mar 2021

mwip commented 3 years ago

If you'd need the test, I'd have a Debian VM at the ready... just LMK

MichaIng commented 3 years ago

Not the man page is missing, but the tool to view man pages from the command line: apt install man-db The Dropbear build is the default package from Debian/Raspbian (non-RPi/RPi).

I am using Arch on my clients

Then I'd open a bug report on the Arch "openssh" package bug tracker first, so that they check whether this is a build option their side or an upstream bug. Not sure how reactive Arch package maintainers are. Probably I find time to test it on Debian. It the issue is the same there, then we can be relatively sure that it's an upstream bug and can forward/report the issue to OpenSSH devs directly.

mwip commented 3 years ago

Indeed. It seems to point to an arch issue. I just tried from a raspberrypi running stock RaspberrypiOS. This one works fine and puts the key to ~/.ssh/authorized_keys.

I will report on the Arch side, link the issues and close when solved. If you like to close this issue earlier, feel free to do so.

mwip commented 3 years ago

Here you can find the related issue: https://bugs.archlinux.org/task/70901

MichaIng commented 3 years ago

Great. I'll leave the issue open since I like that method of applying keys for key authentication. I want to have that in our docs as step to enhance security and convenience both, key authentication in general, and to be true I didn't know that ssh-copy-id command from OpenSSH (client) before, which makes adding the key simple and safe from a GNU/Linux system 👍. That serves as reminder.

mwip commented 3 years ago

Not to get sidetracked too far, but maybe it would be a neat option to have an entry in dietpi.txt where you can pre-insert ssh keys for the root user? Or even a switch to fully disable password-based authentication alltogether? We should probably track that in a different issue, though...

MichaIng commented 3 years ago

Good idea, I like that. Jep let's do that in a new feature request.

Scimmia22 commented 3 years ago

There are no build options that affect this, ssh-copy-id is a simple, static script. Testing from Debian doesn't mean much, either, as even Sid is a few months out of date, and they patch the hell out of openssh.

MichaIng commented 3 years ago

Then the Debian patches are quite reasonable it seems. And Arch does not apply any patches? Then its an upstream issue. I'll have a look into the source code, when its a hardcoded path based on the identified SSH server then it should be easy to fix and the reason is trivial. It would break applying the key to OpenWRT in a single step, but following a single single-purpose distribution which does not follow common defaults is hopefully not seen reasonable after all 😉.

Scimmia22 commented 3 years ago

Arch, as a general rule, patches as little as possible. Currently there's a single patch applied, and it's a fix for building sandbox-seccomp-filter.c with newer glibc. May be able to be dropped, though, it's old enough, I'll have to look into that.

Anyway, take a look at line 335 of the upstream script. https://github.com/openssh/openssh-portable/blob/master/contrib/ssh-copy-id#L335

MichaIng commented 3 years ago

PR up: https://github.com/openssh/openssh-portable/pull/250 I also found the OpenWRT patch, so the case is pretty clear now.

MichaIng / DietPi