Problem with SSH

[The Brit]

I am having a problem with a single user who cannot retrieve files from my system using SSH.

Example:


$ sftp @

Unauthorized use is prohibited
datacore_ftp@bud's password: xxxxxxxxxx

sftp>
sftp> cd ssh2
DSA10:[.SSH2]
sftp> cd ..
DSA10:[]

So far so good. he can type help and change directories without a problem. so he appear to be logged in OK.

Unfortunately, if he tries to execute a "ls" command, then the process just hangs; e.g.

sftp> verbose
sftp> ls
SshFCRecurse/SSHFC_RECURSE.C:401: File is "raw", and it needs to be parsed.
.

The user owns the toplevel directory and all sub-directories, as well as all files within the directory tree. The user account set up is pretty standard, (see attachment), and just in case it was an ownership/protection issue I tried giving the account full priv, to no avail.

Whatever the problem is, is only seems to affect this user and account, and as one would expect, this is the one account that we would really like this to work on.

If you have any ideas about this I would really appreciate them. The OS is OpenVMS 8.3-1H1 running on BL860c Itanium blades. The tcpip stack (and SSH implimentation) TCPIP Services Version 5.6, ECO 3.

thanks

Dave.

[Richard Whalen]

Any idea as to what the remote side is running?
I have seen some versions of TCP/IP Services SFTP request version 999, when they really only implement version 3 of the protocol. Version 4 of the protocol responds to readdir (ls) with a different format that Version 3 of the protocol.

[The Brit]

Thanks Richard, however I think the problem is more basic than that.

I think is is something that is wrong with the account itself. I can sftp using other unprivileged accounts and I can even sftp into the login directory of the problem user, using a different account, (just redefine the login directory in the UAF record to point to the problem root.)

This works OK.

However if I use the account of the User, then the "ls" command simply locks up. This is what I get

sftp @

Unauthorized use is prohibited
@'s password:
sftp> ls
.

and here it sits.

One observation is that the [.SSH2] directory (of the problem account) is empty. Should this directory contain anything.

Dave.

[Richard Whalen]

Based upon the most recent comment, I would say that you should compare quotas with an username that doesn't have problems. And check login.com files for doing anything funny.

[Hoff]

Yes, the requisite files are needed in the directories, and that's almost certainly the trigger for the (dis)connectivity problem here.

[The Brit]

The problem turned out to be a bug in the sftp code in ECO3 (TCPIP 5.6). The problem occurs in situations where a 12 character Username, e.g. username_123, has a login directory with a 12 character name, e.g.
:[USERNAME_123]

The fix is available from HP if you are experiencing this problem.

Dave.

[The Brit]

See above.