Bug 2800

Summary:

sftp fails to connect when login shell is t/csh and user's .cshrc generates output

Product:

Portable OpenSSH

Reporter:

dtkerns <david.t.kerns>

Component:

sftp-server

Assignee:

Assigned to nobody <unassigned-bugs>

Status:

CLOSED FIXED

Severity:

trivial

CC:

djm, dtucker

Priority:

Version:

5.3p1

Hardware:

All

OS:

Linux

Bug Depends on:

Bug Blocks:

2782

Attachments:

Description	Flags
Output "(is your shell clean?)" for message too big only on initial request.	none

Description dtkerns 2017-11-22 02:09:05 AEDT

If the user's login shell is either tcsh or csh and their .cshrc outputs any characters the sftp fails with the message:

Received message too long xxxxxxx

The work-a-round is for the user to wrap any generated output in the following if clause:

if ( `tty` != 'is not a tty' ) then
  echo safe to echo
endif

However, I believe a better solution would be to exec the sftp-server app with the -f argument to the t/csh so that the user's .cshrc file is never sourced.

The following shows the difference between a sftp session with a login shell of bash vs csh:

root         2017     1  0 Nov08 ?        00:00:00 /usr/sbin/sshd
root        21480  2017  0 07:44 ?        00:00:00 sshd: usera [priv] 
usera       21484 21480  0 07:44 ?        00:00:00 sshd: usera@notty  
usera       21485 21484  0 07:44 ?        00:00:00 /usr/libexec/openssh/sftp-server


root      3307     1  0 May15 ?        00:00:00 /usr/sbin/sshd
root     16260  3307  0 14:47 ?        00:00:00 sshd: userb [priv]
userb    16267 16260  0 14:47 ?        00:00:00 sshd: userb@notty
userb    16268 16267  0 14:47 ?        00:00:00 csh -c /usr/libexec/openssh/sftp-server
userb    16288 16268  0 14:47 ?        00:00:00 /usr/libexec/openssh/sftp-server

Comment 1 dtkerns 2017-11-22 02:19:55 AEDT

sorry I typed the "wrapper" script for memory... should be:

if ( `tty` != 'not a tty' ) then
  echo safe to echo
endif

Comment 2 Darren Tucker 2017-11-22 09:24:54 AEDT

having shell startups pollute stdin/stdout is a common problem for many tools, not just sftp.  Adding shell-specific startup flags would require shell (and possibly platform) specific knowledge, and that's a rathole I am not willing to go down.  There is also the possibility that something in the shell startup is actually desired (eg umask setting or something).

It might be possible to give a hint in this case (similar to rsync's "is your shell clean?" message), but as you've discovered the best option right now is "so don't do that, then".

Comment 3 dtkerns 2017-11-22 11:23:40 AEDT

ok, I'll settle for a better (eg is your shell startup output clean?) error message. If nothing else, this bug entry may help save the next guy a few hours of pulling out precious hair. :)

Comment 4 Darren Tucker 2017-11-22 13:07:42 AEDT

Created attachment 3088 [details]
Output "(is your shell clean?)" for message too big only on initial request.

Comment 5 Darren Tucker 2017-11-29 08:14:45 AEDT

A variant of that patch was just committed.

% echo "echo foo" >>.cshrc
% sftp localhost
Received message too long 1718578954
Ensure the remote shell produces no output for non-interactive sessions.

Comment 6 dtkerns 2017-11-29 08:50:34 AEDT

I like it.

Comment 7 Damien Miller 2018-04-06 12:26:31 AEST

Close all resolved bugs after release of OpenSSH 7.7.