[prev in list] [next in list] [prev in thread] [next in thread] 

List:       secure-shell
Subject:    Re: sftp Subsystem failure
From:       Ben Lindstrom <mouring () etoh ! eviladmin ! org>
Date:       2002-11-26 16:52:03
[Download RAW message or body]


The issue is that subsystems use your shell to run the command.  As part
of that it will run the non-interactive aspects of your startup scripts.

[..]
       When an interactive shell that is not  a  login  shell  is
       started,  bash reads and executes commands from ~/.bashrc,
       if that file exists.  This may be inhibited by  using  the
       --norc  option.   The --rcfile file option will force bash
       to  read  and  execute  commands  from  file  instead   of
       ~/.bashrc.

So putting stuff like 'echo' statements in .bashrc is wrong behavior.

[..earily in the manpage..]
       When  bash is invoked as an interactive login shell, or as
       a non-interactive shell with the --login option, it  first
       reads and executes commands from the file /etc/profile, if
       that file exists.  After reading that file, it  looks  for
       ~/.bash_profile,  ~/.bash_login,  and  ~/.profile, in that
       order, and reads and executes commands from the first  one
       that  exists  and is readable.  The --noprofile option may
       be used when the shell is started to inhibit  this  behav
       ior.

Those 3 are better options.

- Ben

On Tue, 26 Nov 2002, Dennis Puk wrote:

> We also noted this problem. We determined that it was due to the user
> having some echo statements in his .bashrc. e.g. echo "test" in your
> ..bashrc will produce that same behavior. But we do not know what is wrong
> actually.
> Using the SSH Comm sftp2 Windows client produces same error as you got.
>
> On the command line (sftp2 client from OpenSSH on Solaris platform):
>
> userA@hostA:~[500]$ sftp userB@hostB
> Connecting to hostB...
> userB@hostB's password:
> Received message too long 1952805748
>
>
>
> Craig A Summerhill said:
> > Hi,
> >
> > Server:   Red Hat Linux 7.3 on i686 dual processor
> > Desktop:  Windows 2000 Professional w/ SSH 3.0.0 (Build 203)
> >
> > We are experiencing an odd problem when trying to open an SFTP
> > Subsystem for one particular user account on a server.  All other  user
> > accounts on the server work fine with sftp, but this one
> > account in particular repeatedly generates an error.  This is the
> > sequence which causes the error:
> >
> >    1) logon to the server using ssh
> >    2) click "New File Transfer Window" button on the
> >       application toolbar, or choose "New File Transfer"
> >       from the "Window" menu.
> >    3) a new window is opened for file transfer, followed
> >       immediately by an alert dialog stating "Connection
> >       was lost."  After clicking "OK" you get a second
> >       dialog window which reads: "File transfer server
> >       could not be started or exited unexpectedly.  Exit
> >       value 0 was returned."
> >
> > I believe the problem may be related to the shell environment for  the
> > account.  Since the account in question is linked to a rather
> > complicated piece of third party software we're license, I am loathe  to
> > make any changes to the shell environment for the account.  I
> > have no way of knowing what problems might result with the
> > software later on.
> >
> >
> > This, I believe, is the crux of the matter:  two accounts are sharing
> > the same $HOME directory.  (I believe the company who licenses this
> > package to us has done this to provide a little bit of "dummy-proofing"
> > between the local sys admins logging into the system and the UID that
> > actually is required to run the daemon process(es) for this package.)
> >
> > In step one above, the user logs into the server using one account  name
> > (let's say "aaa").  However, all files in the $HOME directory  for this
> > user are owned by another account (let's say "bbb").  The  /etc/password
> > lists the same directory as $HOME for both accounts,  but if you login
> > as "aaa" and issue a "whoami" command it returns  "bbb", even after you
> > have logged into a terminal with "aaa."  All  files touched following
> > login by "aaa" are actually owned by "bbb"  and reside in group "bbb" as
> > well.
> >
> > I figure the problem here is a result of the encrypted key not
> > matching correctly because the account string "aaa" is part of
> > the encryption key.  This explains exit status 0.  In fact it is
> > working correctly.  Or perhaps, the problem is related to file
> > permissions in reading configurations?
> >
> > Is there a way to manually configure an sftp Subsystem to understand
> > that the Subsystem should be started up as user "aaa" even though the
> > shell environment is a restricted one for account "bbb"?  I have
> > noticed that a directory named .ssh is created in the $HOME directory
> > of accounts after they connect to the server using SSH.  But the
> > .ssh directory is empty.  Can I create a custom or local sshrc file  or
> > something to store locally that will work around this problem?
> >
> >
> > I am hoping you might provide some guidance in this rather complicated
> > problem.  Thanks in advance for your consideration of this matter. --
> >
> >    Craig A. Summerhill
> >    Applications Development Librarian
> >    University of Nevada, Reno
> >    Getchell Library 174A / Mail Stop 322
> >    1664 North Virginia Street
> >    Reno, NV   89557-0042
> >
> >       (775) 784-6500 x227
> >       <summerhi@unr.edu>
>
>
> --
> Dennis Puk
> School of Computing
> National University of Singapore
>
> <---No God, No Peace. Know God, Know Peace--->
>
>
>
>

[prev in list] [next in list] [prev in thread] [next in thread]