Bug 2800 - sftp fails to connect when login shell is t/csh and user's .cshrc generates output
Summary: sftp fails to connect when login shell is t/csh and user's .cshrc generates o...
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sftp-server (show other bugs)
Version: 5.3p1
Hardware: All Linux
: P5 trivial
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks: V_7_7
  Show dependency tree / graph
 
Reported: 2017-11-22 02:09 AEDT by dtkerns
Modified: 2023-01-13 13:19 AEDT (History)
2 users (show)

See Also:

Attachments
Output "(is your shell clean?)" for message too big only on initial request. (1.46 KB, patch)
2017-11-22 13:07 AEDT, Darren Tucker 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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.