Bug 1365

Summary:

sftp exits immediately after connection (fgets EAGAIN)

Product:

Portable OpenSSH

Reporter:

Roberto A. Foglietta <roberto.foglietta>

Component:

sftp

Assignee:

Assigned to nobody <unassigned-bugs>

Status:

CLOSED WORKSFORME

Severity:

normal

CC:

djm

Priority:

Keywords:

patch

Version:

4.7p1

Hardware:

All

OS:

Linux

Attachments:

Description	Flags
patch for 4.6p1 (but should work for 4.7p1 too)	none
strace output of sftp immediately after connection exited	none
strace output collected with redirection of stderr (works)	none

Description Roberto A. Foglietta 2007-09-18 22:27:22 AEST

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>
~ #

Comment 1 Roberto A. Foglietta 2007-09-18 22:29:01 AEST

Created attachment 1353 [details]
strace output of sftp immediately after connection exited

Comment 2 Roberto A. Foglietta 2007-09-18 22:30:05 AEST

Created attachment 1354 [details]
strace output collected with redirection of stderr (works)

Comment 3 Roberto A. Foglietta 2007-09-18 22:36:25 AEST

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.

Comment 4 Damien Miller 2007-09-18 22:42:29 AEST

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.

Comment 5 Roberto A. Foglietta 2007-09-18 23:07:15 AEST

(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.

Comment 6 Damien Miller 2008-01-20 10:26:42 AEDT

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.

Comment 7 Damien Miller 2008-04-04 10:01:01 AEDT

Close resolved bugs after release.