Firstly: this report is against a 4 year old binary version of the package supplied by a third party.  Can you reproduce the problem with a current version built from the sources available from openssh.com?  If not then it is unlikely that we can help you.


(In reply to Moin from comment #0)

> sshd[19250]: [ID 800047 auth.error] error: PAM: System error for axadmin

that very much looks like your PAM stack is misconfigured.

[...] 
> # consult /etc "files" only if ldap is down. 
> hosts: files ldap 

The intent and implementation seem to differ here.

[...]
> #sshd account required pam_unix_account.so.1 
> #RCA: FR: 3BKA32FBR276068 
> sshd account binding pam_unix_account.so.1 server_policy 
> sshd account required pam_ldap.so.1

you don't have any "auth" config for the sshd stack? Presumably it's supposed to use "other" in this case, but does it work for local users?

Hi,

Thanks for the inputs,

===> # consult /etc "files" only if ldap is down. 
> hosts: files ldap 
===

LDAP client is on the same server and it is not down.

===
you don't have any "auth" config for the sshd stack? Presumably it's supposed to use "other" in this case, but does it work for local users?
====

Not really sure about the auth config part but yes it is working with local users

Very strange behaviour is seen while doing ssh from Mobaxterm application, i could ssh with the ldap user but not with putty or super putty.

auth logs:

From putty login 
Jan 22 09:28:49 OMCS sshd[12267]: [ID 800047 auth.error] error: PAM: System error for axadmin from 135.250.193.170
Jan 22 09:28:49 OMCSRV01 sshd[12267]: [ID 800047 auth.error] error: PAM: System error for axadmin from 135.250.193.170
Jan 22 09:28:49 OMCS sshd[12267]: [ID 800047 auth.error] error: PAM: System error for axadmin from 135.250.193.170
Jan 22 09:28:49 OMCS sshd[12267]: [ID 800047 auth.error] error: PAM: System error for axadmin from 135.250.193.170


while logging from Mobaxtern
Jan 22 09:30:10 OMCS sshd[13478]: [ID 800047 auth.info] Accepted password for axadmin from 135.255.138.11 port 51838 ssh2
Jan 22 09:30:13 OMCS sshd[13491]: [ID 800047 auth.info] Accepted password for axadmin from 135.255.138.11 port 51839 ssh2

You did not answer this question:

(In reply to Darren Tucker from comment #1)
> Can you reproduce the problem
> with a current version built from the sources available from
> openssh.com?


Anyway, please try these:

ssh -vvv -o PreferredAuthentications=password yourserver

and

ssh -vvv -o PreferredAuthentications=keyboard-interactive yourserver

and use "Add an attachment" to attatch the output to this bug.

Also, if you can run the server in debug mode at the same time (/path/to/sshd -ddd -p [someport]) and add -p [someport] to the ssh command lines, please add the server debug output too.

Created attachment 2530 [details]
Debug logs

Have included all the logs in the same file

Hi,
==================
> Can you reproduce the problem
> with a current version built from the sources available from
> openssh.com?
==============

I have many server running with same openssh version, so did not plan to reproduce with higher build version of openssh
=============

check debug logs in attachments and please do let me know if any solution for the bug.

Thanks
Moin

Any update on the issue.

I think pam.conf file is misconfigured, but tried alot changing the rules for sshd , still the  cannot fix the issue.

Short answer as a workaround: put "ChallengeResponseAuthentication no" and "KbdInteractiveAuthentication no" into sshd_config and restart sshd.

Longer answer:
There's two different methods of password-type authentication: PasswordAuthentication (the simplest) and keyboard-interactive (which is more complicated but more capable).  Your debug logs show password works but keyboard-interactive doesn't.

> 3.if you can run the server in debug mode at the same time --- was able to login

now this is a bit odd: your keyboard-interactive works when the server is running in debug mode.  Unfortunately this makes it hard to figure out what's going on.  My guess is that something in the PAM stack is trying to use stdin or stdout (which, if true, is a bug in a PAM module).

Please try redirecting the sshd stdin and stdout then try logging in:

/path/to/sshd -p [someport] -De -oLogLevel=debug3 </dev/null >/dev/null >logfile

ssh -vvv -o preferredauthentications=keyboard-interactive -p [someport] yourserver

and attach both logs to this bug.

Created attachment 2534 [details]
sshd terminal logs

Hi,
=====
/path/to/sshd -p [someport] -De -oLogLevel=debug3 </dev/null >/dev/null >logfile

ssh -vvv -o preferredauthentications=keyboard-interactive -p [someport] yourserver
=====

I could login successfully but nothing was written in logfile, but have attached the terminal logs.

oops, missed the "2" to redirect stderr.  That should have read:

/path/to/sshd -p [someport] -De -oLogLevel=debug3 </dev/null >/dev/null 2>logfile

however what you've posted indicates it worked, so I don't think it's going to be helpful either.  The only other difference I can think of is the controlling terminal.  You could test this by running sshd under something like setsid (assuming Solaris has it):

setsid /usr/sbin/sshd -p [someport] -De -oLogLevel=debug3 </dev/null >/dev/null 2>logfile

If that doesn't work, try setting loglevel=debug3 in sshd_config, restarting and then grepping the log messages out of syslog by process ID (but note that there will be at least 3 pids, so you'll need to get them all).

Hi,

Thanks alot for supporting here.

we dont have setsid command in solaris, is there any equivalent of it.

Couldn't find any equivalent command to control to terminal.

Any other solution?

Hi ,

Have noticed one thing while changing authentication method in ldapclient configuration from tls:simple to simple.

i could ssh via ldap user.

Can somebody help here to find the root cause of the issue.

(In reply to Moin from comment #13)
> Hi ,
> 
> Have noticed one thing while changing authentication method in
> ldapclient configuration from tls:simple to simple.

Might be a symbol collision or version incompatibility between the version of OpenSSL sshd is linked against and the version your PAM module is linked against.

is the PAM module linked against libcrypto and if so which version?   ("ldd pam_ldap.so" or whatever, then compare against "ldd sshd").

> i could ssh via ldap user.
> 
> Can somebody help here to find the root cause of the issue.

If those are different and it's the cause of the problem the only workaround I can suggest is rebuilding either the PAM module or sshd so they are using the same version.  It's not possible to fix this in the general case due to PAM's design.

(In reply to Darren Tucker from comment #8)
> Short answer as a workaround: put "ChallengeResponseAuthentication
> no" and "KbdInteractiveAuthentication no" into sshd_config and
> restart sshd.

Did you try this?

(In reply to Moin from comment #6)
> Hi,
> ==================
> > Can you reproduce the problem
> > with a current version built from the sources available from
> > openssh.com?
> ==============
> 
> I have many server running with same openssh version, so did not
> plan to reproduce with higher build version of openssh
> =============


anyway, until you can reproduce this with a current version of the code compiled from the source provided at openssh.com and not some third party's binary packages then we are not able to help you.

Let me just add: this is a bug tracking system and not a support forum. We're here to improve OpenSSH, not to provide unpaid technical support to diagnose your configuration problems.

Hi,
=====
> Short answer as a workaround: put "ChallengeResponseAuthentication
> no" and "KbdInteractiveAuthentication no" into sshd_config and
> restart sshd.

Did you try this?
=====

Yes have tried it and it was working fine.

===

is the PAM module linked against libcrypto and if so which version?   ("ldd pam_ldap.so" or whatever, then compare against "ldd sshd").
====

Pam module is not linked with libcrypto.
======
Let me just add: this is a bug tracking system and not a support forum. We're here to improve OpenSSH, not to provide unpaid technical support to diagnose your configuration problems.
======

Thats correct no one will support for free. But i was querying the bug which i faced with openssh.

I seriously appreciate your support and your precious time in analyzing this bug.

Thanks alot. will plan to upgrade with latest openssh and check the issue.

here the below are the output of ldd

@:/root !ksh ldd /usr/local/sbin/sshd
        libcontract.so.1 =>      /usr/lib/libcontract.so.1
        libpam.so.1 =>   /usr/lib/libpam.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libresolv.so.2 =>        /usr/lib/libresolv.so.2
        libcrypto.so.1.0.0 =>    /usr/local/ssl/lib/libcrypto.so.1.0.0
        librt.so.1 =>    /usr/lib/librt.so.1
        libbsm.so.1 =>   /usr/lib/libbsm.so.1
        libz.so =>       /usr/lib/libz.so
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libgcc_s.so.1 =>         /usr/local/lib/libgcc_s.so.1
        libnvpair.so.1 =>        /usr/lib/libnvpair.so.1
        libcmd.so.1 =>   /usr/lib/libcmd.so.1
        libaio.so.1 =>   /usr/lib/libaio.so.1
        libmd.so.1 =>    /usr/lib/libmd.so.1
        libsecdb.so.1 =>         /usr/lib/libsecdb.so.1
        libtsol.so.2 =>  /usr/lib/libtsol.so.2
        libmp.so.2 =>    /usr/lib/libmp.so.2
        libscf.so.1 =>   /usr/lib/libscf.so.1
        libdoor.so.1 =>  /usr/lib/libdoor.so.1
        libuutil.so.1 =>         /usr/lib/libuutil.so.1
        libgen.so.1 =>   /usr/lib/libgen.so.1
        libm.so.2 =>     /usr/lib/libm.so.2
        /lib/libm/libm_hwcap1.so.2
        /platform/SUNW,SPARC-Enterprise/lib/libc_psr.so.1
@:/root !ksh ldd /usr/lib/security/pam_ldap.so
        libpam.so.1 =>   /usr/lib/libpam.so.1
        libsldap.so.1 =>         /usr/lib/libsldap.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libcmd.so.1 =>   /usr/lib/libcmd.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libldap.so.5 =>  /usr/lib/libldap.so.5
        libscf.so.1 =>   /usr/lib/libscf.so.1
        libdoor.so.1 =>  /usr/lib/libdoor.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        libmd.so.1 =>    /usr/lib/libmd.so.1
        libsasl.so.1 =>  /usr/lib/libsasl.so.1
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libnspr4.so =>   /opt/ODS7/dsee7/lib/private/libnspr4.so
        libplc4.so =>    /opt/ODS7/dsee7/lib/private/libplc4.so
        libnss3.so =>    /opt/ODS7/dsee7/lib/private/libnss3.so
        libssl3.so =>    /opt/ODS7/dsee7/lib/private/libssl3.so
        libuutil.so.1 =>         /usr/lib/libuutil.so.1
        libgen.so.1 =>   /usr/lib/libgen.so.1
        libpthread.so.1 =>       /usr/lib/libpthread.so.1
        librt.so.1 =>    /usr/lib/librt.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libnssutil3.so =>        /opt/ODS7/dsee7/lib/private/libnssutil3.so
        libplds4.so =>   /opt/ODS7/dsee7/lib/private/libplds4.so
        libthread.so.1 =>        /usr/lib/libthread.so.1
        libaio.so.1 =>   /usr/lib/libaio.so.1
        libm.so.2 =>     /usr/lib/libm.so.2
        /lib/libm/libm_hwcap1.so.2
        /platform/SUNW,SPARC-Enterprise/lib/libc_psr.so.1

Close all resolved bugs after 7.3p1 release