Make dropbear scp -o behave correctly #41
Conversation
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!
|
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 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. |
|
No, this didn't get fixed. I think what is needed is for dbclient to implement |
|
|
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!