Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#1814 - Dropbear breaks the connection prematurely on large output #8509

Closed
openwrt-bot opened this issue Aug 25, 2018 · 6 comments
Closed
Labels

Comments

@openwrt-bot
Copy link

psliwka:

Hi everyone!

After upgrading to 18.06 (from 17.01), I've noticed that some of my management scripts stopped working. After investigation, I've found that Dropbear seems to break the connection prematurely if a remote command produces large output (more than 14kB), truncating remaining data. The problem appears only when pseudo-tty allocation is used.

====Steps to reproduce====

  • Create a file bigger than 14kB on your device. I've used vi to write a file containing 20,000 'x' characters and a newline (I'm attaching it to the ticket for convenience). Final result:
    $ ssh my.router wc /tmp/bigfile
    1 1 20001 /tmp/bigfile
  • Try to print full file contents over SSH, everything is fine:
    $ ssh my.router cat /tmp/bigfile | wc
    1 1 20001
* Try to do the same over SSH with pseudo-tty allocation: $ ssh -t my.router cat /tmp/bigfile | wc Connection to my.router closed. 0 1 14335

====Expected result====
Whole command output is sent from the router, both with and without pseudo-tty.

====Actual result====
With pseudo-tty, output is truncated at 14kB.

====Affected devices====
I was able to reproduce the issue on Netgear WNDR3700 v2 and TP-Link TL-WR1043ND v3.

====Workaround====
Replace Dropbear with OpenSSH.

@openwrt-bot
Copy link
Author

gekmihesg:

This issue still exists in 18.06.2:
$ ssh -t root@192.168.1.1 'yes | tr -cd y | head -c 20000 > /tmp/bigfile; cat /tmp/bigfile' | wc -c
Connection to 192.168.1.1 closed.
14335

Seems to be fixed in 18.06.2:

$ ssh root@192.168.1.1 'yes | tr -cd y | head -c 20000' | wc -c 20000 $ ssh -t root@192.168.1.1 'yes | tr -cd y | head -c 20000' | wc -c Connection to 192.168.1.1 closed. 20000

@openwrt-bot
Copy link
Author

yousong:

Just created a pull request to upstream project [1]. Please also consider giving it a try. Thank you.

[1] mkj/dropbear#85

@openwrt-bot
Copy link
Author

mkj:

Out of interest, what is the use case for transferring a file with a pseudo-tty allocated?
One problem I see is that any error messages to stderr will get mixed into stdout.

@openwrt-bot
Copy link
Author

gekmihesg:

It's not about transferring a file but about the amount of data transferred. The issue initially came up with an Ansible role for managing OpenWRT systems [[https://github.com/gekmihesg/ansible-openwrt/issues/4|here]]. If the output of an Ansible module is too big, the whole playbook fails.

@openwrt-bot
Copy link
Author

mkj:

What SSH command is ansible-openwrt using? If it's doing "ssh host " then it shouldn't be allocating any pseudo-tty. If it's opening a single pipe "ssh host" then sending commands with newlines, it would be better to use "ssh -T host" to avoid the pty?

@openwrt-bot
Copy link
Author

gekmihesg:

It's not really related to the project specifically, but just [[https://docs.ansible.com/ansible/latest/plugins/connection/ssh.html#parameter-use_tty|default Ansible behaviour]].

$ ansible -vvvm raw -a 'cat /tmp/bigfile' 192.168.1.1
ansible 2.9.9

...

<192.168.1.1> ESTABLISH SSH CONNECTION FOR USER: root
<192.168.1.1> SSH: EXEC ssh -C -o ControlMaster=auto -o ControlPersist=60s -o StrictHostKeyChecking=no -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o 'User="root"' -o ConnectTimeout=10 -o ControlPath=/home/gekmihesg/.ansible/cp/856552cd8b -tt 192.168.1.1 'cat /tmp/bigfile'

...

I'm not sure whether the "use_tty" parameter was already usable at the time of creating this bug (Ansible 2.5 has already been released but probably not hit relevant distro repos). Anyway, setting this param to "no" actually avoids this problem, because it [[https://github.com/ansible/ansible/blob/stable-2.9/lib/ansible/plugins/connection/ssh.py#L1184|skips the -tt param]].
Since this is only seems required in combination with sudo (which I don't consider relevant on OpenWRT), I [[https://github.com/gekmihesg/ansible-openwrt/commit/4386c9f53e7f0b0a2496948496f6c01713857f44|disabled tty allocation]] by default now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant