dropbear icon indicating copy to clipboard operation
dropbear copied to clipboard

Make dropbear scp -o behave correctly

Open koitsu opened this issue 8 years ago • 3 comments

This bug has existed since at least 2012. I sent mkj an Email on 2013/02/24 that contained the fix. Below is that Email in full (with an added reference to the thread in question):

I found this while helping a Tomato/TomatoUSB user today: http://www.linksysinfo.org/index.php?threads/scp-wont-run-in-startup-script.68197/#post-223474

scp's -o flag is supposed to pass the optarg (and only that) on to ssh. However presently it treats it the same as -c, -i, or -F, which is incorrect.

The test case I found: "scp -oy" gets turned into "ssh -oy" when it should get turned into "ssh -y".

Below is a patch. I don't know if there are any security implications by doing this.

An alternate workaround would be to add a -y flag to scp.c (i.e. treated the same as the existing -[1246C] flags in scp.c).

Also, I must say something because this really frustrated me when trying to find usage syntaxes and so on (particularly that there is no scp.1 man page or equivalent):

The scp.c usage() function should really be rewritten to look more like printhelp(). Furthermore, there are options in scp.c which aren't documented (such as -d, -f, and -t, which are passed on to a server command as arguments when calling ssh).

If you agree but don't have the time let me know and I'll gladly provide a patch for both printhelp() (to clean up formatting/make it look prettier) and for usage().

I'd also suggest changing the -o description from "ssh_option" to "ssh_flag"; when I saw "ssh_option" I assumed that it took the same kind of long option names as OpenSSH (e.g. -oStrictHostKeyChecking=no). If I ended up cleaning up usage() I would simply add a line at the bottom that explain that -o just passes on whatever flag you give it to the ssh client.

Thank you!

koitsu avatar Jan 12 '17 01:01 koitsu

Sorry for taking so long to get to this.

I don't think "scp -oy" is meant to pass -y to ssh, at least according to its docs. It would instead run "ssh -o y", which isn't what you want.

I guess the right way to fix the problem from that thread is to add a "-o acceptallhostkeys=yes" or similar to dbclient.

mkj avatar Jan 25 '18 16:01 mkj

@mkj With the latest Dropbear code (2018.76), do you happen to know if this is effectively fixed, i.e. does scp -y work properly? I see dbclient has a -y flag, but I haven't checked to see if that now functions properly with scp.

koitsu avatar Mar 05 '18 02:03 koitsu

No, this didn't get fixed. I think what is needed is for dbclient to implement -o StrictHostKeyChecking=accept-new as a synonym for -y, then you'd pass that -o option to scp. I'll need to check that Dropbear's behaviour is the same as described in ssh_config though.

mkj avatar Mar 05 '18 05:03 mkj