Solaris

when one custmer connect using sftp got the following delivery report

can you plase suggest on the issue.



14:04:36 SFTP Delivery properties:
Host: <ip>
Target Folder: </home>
User: <user>
14:04:36 Keys loaded succeffuly
14:04:36 GEN-E-GENERAL, Error connecting to server : Invalid username or password reported by server.
14:04:36 Disconnecting from ip
14:04:36 GEN-E-GENERAL, Error : SFTP connecting to server

Nothing for certain here. This could be either because:

1. The user's name, password, or shell is no longer valid (I suspect you have checked this)?

2a. A global setting has changed to prevent logins (ie, /etc/nologin, /etc/hosts.allow, etc).

2b. A global setting has changed to prevent lookup information from working properly (ie, /etc/nsswitch, /etc/ldap.conf, /etc/yp.conf, etc).

3a. The sshd configuration has changed: the private/public key pair has been regenerated and the client no longer recognizes the server key as valid.

3b. The sshd configuration has changed: the server configuration no longer supports the SFTP module. Check the configuration file for "sftp".

3c. The sshd configuration has changed: the user/group is no longer allowed to access sftp.

4. Finally, if all that checks out, it's possible there's actually a man-in-the-middle attack being attempted. This is rare, but its worth checking out. Make sure the client sees the same server key for your server.

thanks for reply

item 1 i checked no problem
2a in /etc/passwd file the user was mentioned as

user:x:8009:505::/export/home/user:/bin/false


item 3a,3b,3c we are able to connect from other machine to this machine in other user account using sftp

please suggest....

Right, so it may be that the shell prevents the user from logging in. Do the following:

1. Create a softlink to /bin/false. Name the new link something like "sftponly". So:

Code:

ln -s /bin/false /bin/sftponly

2. Add "/bin/sftponly" to /etc/shells. So:

Code:

echo /bin/sftponly >>/etc/shells

3. Change user's shell from /bin/false to /bin/sftponly

What will happen is that PAM should allow the user to pass the authentication stages because the user now has a 'valid shell'. But for all other purposes, such as logging in through sshd or telnet or X, it will still not work.

Thanks

if we have put nothig in place of /bin/false whether it works

but it says as

/bin/false disallows login with telnet/ssh it does not disallow ftp/sftp as you only run your shell when you direct login

to the best of my knowledge, modern Solaris (2.8, 2.9, 2.10) uses PAM -- Pluggable Authentication Modules. If sshd is set to use PAM (see the sshd.conf file) and the pam_unix module is required for the auth and session parts (see /etc/pam.conf or /etc/pam.d/ssh*) then the shell WILL be checked against /etc/shells.

If you leave the shell field blank, I believe the system will use the default shell (/bin/sh). That might be un-desirable from a security standpoint. But what the hell -- try it and if it doesn't work, then the problem is elsewhere.

thanks Otheus....

now it seems like some pubic key name conflict lets check that from their side ...

once they came back with solution i will get back to you... soon

the server using solaris 9.0