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
Comments
gekmihesg: This issue still exists 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
|
yousong: Just created a pull request to upstream project [1]. Please also consider giving it a try. Thank you. [1] mkj/dropbear#85 |
mkj: Out of interest, what is the use case for transferring a file with a pseudo-tty allocated? |
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. |
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? |
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]].
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]]. |
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====
$ ssh my.router wc /tmp/bigfile
1 1 20001 /tmp/bigfile
$ ssh my.router cat /tmp/bigfile | wc
1 1 20001
$ 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.
The text was updated successfully, but these errors were encountered: