Opened 6 years ago

Last modified 4 years ago

#10676 new defect

dropbear authorized_keys regression from 0.52 to 0.53.1

Reported by: Joel Johnson <mrjoel@…> Owned by: developers
Priority: normal Milestone: Barrier Breaker 14.07
Component: base system Version: 10.03.1
Keywords: Cc:


I updated to the 10.03.1 final release, and it appears that there is a regression in dropbear. I have an /etc/dropbear/authorized_keys file which is the same that I was using in the previous release as follows:

no-port-forwarding,no-pty,no-X11-forwarding,no-agent-forwarding ssh-rsa AAAA...== root@host

I use the key for remote backups with rsync, so it uses a direct command invocation instead of an interactive shell. The auth_keys entry seems for work for an interactive shell (getting PTY allocation request failure with no-pty, and shell when no-pty is removed), however is not working for remote commands.

It doesn't seem to matter what combinations of the four restrictions are listed, as long as at least one of them is listed, then the connection will just hang indefinitely. If I have the entry without any no-* restrictions then it works fine.

To test this, from a remote machine, run something like

ssh -v root@<> ls

My OpenSSH client log shows:

debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending command: ls

And then just hangs until I kill the session from the client. Watching from the OpenWrt side, I see the dropbear session connect, and a /bin/ash process is created as a child of the session, but the command is never executed, nor any error displayed.

From a backup of my old OpenWrt load on this router, I copied dropbear 0.52 to /usr/sbin/dropbear-0.52 and moved the 0.53.1 version to /usr/sbin/dropbear-0.53.1, and symlink the one I test to /usr/sbin/dropbear. When replacing with the old 0.52 one, everything works as expected.

Adding the 'command="blah",' snippet to the auth_keys entry correctly runs the specified command on connect, however since rsync provides a session id on each command I'd rather not tighten that down. I'm aware of rsync wrapper scripts that can be used for rsync logins but that seems overkill and usecase-specific.

In looking at the changesets of packaging for 0.52 and 0.53.1, there doesn't seem to be anything that would change this behavior, so I'll ask on the upstream mailing list as well since it would seem to be an issue with the source.

Attachments (0)

Change History (2)

comment:1 Changed 6 years ago by Joel Johnson <mrjoel@…>

For others who may be interested in the workaround mentioned specifically for rsync, here is one way to do it. The hostname command requires the net-tools-hostname package, or just set it statically or remove it.


HOSTNAME=`hostname -f`

*\&* | *\(* | *\{* | *\;* | *\<* | *\`* | *\|*)

echo "Requested command contains forbidden patterns (on $HOSTNAME)"

rsync\ --server*)

    echo "Requested command not allowed on $HOSTNAME"

Then in the /etc/dropbear/authorized_keys file, edit the entry to force that command, like the following

command="/root/validate-rsync",no-port-forwarding,no-pty,no-X11-forwarding,no-agent-forwarding ssh-rsa AAAA...== root@host

This could be generalize to run anything by setting the command to be the following, but that's really working around the issue


comment:2 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

as new .

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.