(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
- Dropbear pubkey regression Joel Johnson
-
