Created attachment 1352 [details] patch for 4.6p1 (but should work for 4.7p1 too) sftp client was cross-compiled for a PPC board while sftp-server is running onto an Ubuntu Linux / x86 arch. After login sftp gets out immediately, however if I specify a batch file it works. The amazing thing is.... 2>/dev/null resolve the issue! Attach sftp.err.1.gz show strace of a sftp failed and sftp.err.2.gz sftp 2>strace.log which successes. Problem is fgets returns EAGAIN but this condition is not propely tested. Patch would fix. This behavior has noticed in version 4.6p1 but sftp.c does not have changed in 4.7p1 ~ # sftp -S /usr/bin/dbclient -s /usr/lib/openssh/sftp-server foglietr@172.16.119.6 Connecting to 172.16.119.6... WARNING: Ignoring unknown argument '-oForwardX11 no' WARNING: Ignoring unknown argument '-oForwardAgent no' WARNING: Ignoring unknown argument '-oPermitLocalCommand no' WARNING: Ignoring unknown argument '-oClearAllForwardings yes' WARNING: Ignoring unknown argument '-oProtocol 2' foglietr@172.16.119.6's password: foglietr@172.16.119.6's password: foglietr@172.16.119.6's password: xset: unable to open display "" xset: unable to open display "" sftp> ~ # ~ # cat pippo ls ls ~ # sftp -b pippo -S /usr/bin/dbclient -s /usr/lib/openssh/sftp-server foglietr@172.16.119.6 WARNING: Ignoring unknown argument '-oForwardX11 no' WARNING: Ignoring unknown argument '-oForwardAgent no' WARNING: Ignoring unknown argument '-oPermitLocalCommand no' WARNING: Ignoring unknown argument '-oClearAllForwardings yes' WARNING: Ignoring unknown argument '-obatchmode yes' WARNING: Ignoring unknown argument '-oProtocol 2' foglietr@172.16.119.6's password: xset: unable to open display "" xset: unable to open display "" sftp> ls [... ls print out ...] sftp> ls [... ls print out ...] sftp> ~ #
Created attachment 1353 [details] strace output of sftp immediately after connection exited
Created attachment 1354 [details] strace output collected with redirection of stderr (works)
I forgot to say this bug has been noticed using sftp in conjunction with dropbear ssh but you should have seen it by the command line itself.
Can you replicate the problem running with OpenSSH ssh, or by bypassing ssh entirely and having sftp talk directly to sftp-server? You can do the latter using a commandline like the following: sftp -P /usr/libexec/sftp-server blah If I had to guess what the problem is, it would be that dropbear is detecting a tty on stderr and putting /dev/tty into non-blocking mode though it isn't clear why this should interfere with sftp, which is a separate process.
(In reply to comment #4) > Can you replicate the problem running with OpenSSH ssh, or by bypassing > ssh entirely and having sftp talk directly to sftp-server? no as far as I can see. > You can do > the latter using a commandline like the following: > > sftp -P /usr/libexec/sftp-server blah ~ # sftp -P /usr/libexec/sftp-server Attaching to /usr/libexec/sftp-server... sftp> ls pippo strace.log sftp> ~ # sftp -S /mnt/tmpfs/ssh.gzexe foglietr@172.16.119.6 Connecting to 172.16.119.6... foglietr@172.16.119.6's password: sftp> quit > > If I had to guess what the problem is, it would be that dropbear is > detecting a tty on stderr and putting /dev/tty into non-blocking mode > though it isn't clear why this should interfere with sftp, which is a > separate process. > anyway do you think this patch could hurt in sane enviroment? I used a usleep(10*1000) in order to not overload the system.
The patch just papers over the problem, which is probably in Dropbear somewhere. I don't think this is a bug in OpenSSH, please reopen if you can find evidence that it is.
Close resolved bugs after release.