Can't sftp but can ssh in ok

[Andrew Weiss]

I have compiled and installed:

zlib 1.1.4
perl 5.8.0
prngd 0.9.27
openssl 0.9.7a
openssh 3.5p1

using --with-pam, disabling privilege separation (because it didn't work with tcb) and gotten ssh to work for both root and normal user accounts...but sftp only works for root. I previously had no /etc/shells file, but I went ahead and added one just in case. ftp worked fine for both types of users. Is there another privilege sep setting that applies to scp/sftp?

[Andrew Weiss]

This is HP-UX 11i btw.

[Steven E. Protter]

Whats the reject error text, if any. It all works through port 22, and the configuration of the ftp server should not to my knowledge be a problem.

Have you exchanged public keys? Doc attached.

SEP

[Colin Topliss]

Not any that I can see - if it works for root, it should work for any other account.

I tested the following:

test:/root=> /opt/openssh2/bin/slogin ctopliss@itopsd0

(worked OK)

If this works OK, then try:

test:/root=> /opt/openssh2/bin/sftp ctopliss@itopsd0

For me it worked fine - I was able to both slogin and sftp.

Is there nothing in the syslog to give you a clue?

[David Lodge]

I noticed with openssh there are issues if you have batch users - ie, ones with /usr/bin/false will immediately fail.

I managed to get around this by installing a program called 'scponly' which works with this.

If there are no limitations on the user; the best I can offer is to use sshd in debugging mode. Kill the daemon, then run 'sshd -d -D'. Be warned; you get a lot of rubbish; but it will hold the pertinent information.

dave

[Andrew Weiss]

The rejection text coming from both the machine to localhost and also remote machines is connection closed. The syslog indicates the password is accepted on port 49XXX, or 52XXX or such using ssh2

No failures are indicated in syslog

I didn't exchange keys because I'm using simple tunneled password for the time being... everything else is way too complex for the moment. I'm simply replacing telnet and ftp. I am using the keys generated via make install.

[David Lodge]

hmmm... It looks like it has accepted authentication, and then fails when spawning the sftp helper application:

>subsystem request for sftp
>debug1: subsystem: exec() /opt/openssh/libexec/sftp-server

Here.

>debug1: PAM establishing creds
>debug1: fd 15 setting O_NONBLOCK
>debug1: fd 14 setting O_NONBLOCK
>debug1: Received SIGCHLD.

This is interesting - a SIGCHLD is used to signify to the parent that its children are having problems!

>debug1: channel 0: read<=0 rfd 15 len 0
>debug1: channel 0: read failed

Looks like the tunnel to the parent died here

[snip]

What the above seems to be saying is that it's spawing the sftp-server service and that seems to be immediately dying, thus causing ssh to kick you out...

What are the permissions like on that file/directory/parent directory? Is sshd being run as root?

dave

[Tim Maletic]

What does a "sftp -v" from the client side of that server debug look like? And what is the complete command you're issuing on the client?