Dropbear pubkey regression

[Joel Johnson]

(Posted as an unsubscribed user but didn't get moderated through, 
reposting after subscribing, I apologize for potential duplicates).

I'm using dropbear via OpenWrt and have recently updated from version 
0.52 to version 0.53.1. I'm having an issue where previously my 
authorized_keys via SSH worked fine issuing a command, but under the 
newer versions it doesn't. I took a quick glance at the diff between the 
tags for 0.52 and 0.53.1, and don't see any thing that stands out 
(mainly looked at svr-chansession.c and svr-authpubkeyoptions.c).

The behavior I'm seeing is when using an authorized_keys entry with any 
of the no-port-forwarding,no-pty,no-X11-forwarding,no-agent-forwarding 
options set, a command specified by the SSH client is not executed, but 
blocks indefinitely. The SSH_ORIGINAL_COMMAND is correctly set, and in 
fact can be used as a workaround (by setting 
command="$SSH_ORIGINAL_COMMAND" in the auth_keys entry), but the command 
requested by the client is never executed in 0.53.1 whether using 
ptycommand() or noptycommand(), when it was correctly executed in 0.52.

Is direct invocation of commands known to be broken, intentionally 
disabled (should at least return and provide an error message)?

This was tested with 0.53.1 and not with 2011.54, but nothing seems to 
stand out that this has been fixed since 0.53.1.

As a point of reference with the full details, the OpenWrt ticket I 
opened is https://dev.openwrt.org/ticket/10676.

Thanks,
Joel