Re: sftp Subsystem failure

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