ssh 3.7.1p2 and trusted system

[Travis Harp]

I'm having an issue with 3.7.1p2 on my trusted systems.

When I upgrade to the new demon I get an error when trying to login...

Permission denied, please try again.

It acts like I'm typing my password in wrong but that's not the case.
At first I thought it was a key issue but I've figured out that if I unconverted the system from trusted mode I can login correctly.

When I reconvert the system the problem returns.

Anyone have an idea what is going on here?

[RAC_1]

Try connecting as follows and post the results.

ssh -vvv "server_to_connect"

[Cheryl Griffin]

HP's implementation of SSH works on a Trusted System
http://www.software.hp.com/portal/swdepot/displayProductInfo.do?productNumber=T1471AA

[Steven E. Protter]

Cheryl makes the point I want to emphasize.

HP's 3.6.1.2 port depots deal with issues that may not be dealt with in the compiled versions. The security flaw that led to 3.7 was corrected by HP in their 3.6 port.

I would use the latest HP depots in any event, but the -v option will give you a clue as to what the issue is. I'd like to see that output, and HP might as well.

SEP

[Sridhar Bhaskarla · Accepted solution]

Travis,

I think 3.7.1p2 is broken for HP's trusted systems. You may have to wait until the next release or use 3.7.1p1.

The message you will see in syslog.log is "Illegal user from xx.xx.xx.xx".


-Sri

[Jeff Schussele]

Hi Travis,

Is it possible that your account was deactivated due to inactivity? We've found that even with the newest SSH vers, it will not pass that msg back to you. If you telnet you *will* see the msg. But, it's getting better as the older SSH vers wouldn't even give you passwd expiration notices & now with PAM properly linked in you get those from SSH.
So bottom line - when you're not getting in via SSH and you still have telnet active - try it to see if you at least get a notification from it.

Rgds,
Jeff

[Marc Roger]

Did you compile the program from source ?
If so, I would guess that the compile options made sshd use getpwent() instead of getprpwent() - I would check in the documentation of sshd if particular compile-time options are needed for HP-UX in trusted mode.

[Sridhar Bhaskarla]

Hi,

HP's works but I am not sure if it is 3.7.1p2. I guess it is only 3.7.1p1 though I haven't tried.

We tried it unsuccessfully to compile. It's quite a bit of mess. Instead of trying to fix it, we decided to wait until a major release. Openssh old versions used to have the problem with PAM and there was a patch given by a gentleman that fixed the problem.
Now it's showing up again.

You can compile 3.7.1p1 successfully without any modifications and it will work just fine without any patches.

There is a patch provided by Darren Tucker at

http://www.zip.com.au/~dtucker/openssh/

Try compiling with pwexp26.patch. I haven't tried it though.

-Sri

[Travis Harp]

This is the output of ssh -vvv
Note that anything in <> was a sanitation of information not the actual output.

Travis
-----------------

/usr/local/bin/ssh -vvv
OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003
debug1: Reading configuration data /usr/local/etc/openssh/ssh_config
debug3: Seeding PRNG from /usr/local/libexec/ssh-rand-helper
debug2: ssh_connect: needpriv 0
debug1: Connecting to [] port 22.
debug1: Connection established.
debug1: identity file /usr//.ssh/identity type -1
debug1: identity file /usr//.ssh/id_rsa type -1
debug1: identity file /usr//.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.7.1p2
debug1: match: OpenSSH_3.7.1p2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.7.1p2
debug3: RNG is ready, skipping seeding
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 125/256
debug2: bits set: 1568/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /usr//.ssh/known_hosts
debug3: check_host_in_hostfile: match line 24
debug1: Host '' is known and matches the RSA host key.
debug1: Found key in /usr//.ssh/known_hosts:24
debug2: bits set: 1614/3191
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /usr//.ssh/identity (00000000)
debug2: key: /usr//.ssh/id_rsa (00000000)
debug2: key: /usr//.ssh/id_dsa (00000000)
debug3: input_userauth_banner


< System Banner >

debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /usr//.ssh/identity
debug3: no such identity: /usr//.ssh/identity
debug1: Trying private key: /usr//.ssh/id_rsa
debug3: no such identity: /usr//.ssh/id_rsa
debug1: Trying private key: /usr//.ssh/id_dsa
debug3: no such identity: /usr//.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: userauth_kbdint: disable: no info_req_seen
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred:
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
@'s password:
debug3: packet_send2: adding 64 (len 58 padlen 6 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
Permission denied, please try again.
@'s password:

[Sridhar Bhaskarla]

Hi,

What is the error you get in your syslog.log file?. Did you try out by making "Privilige seperation no" in sshd.conf file and restart sshd just for testing purpose?.

And also on the server side, invoke sshd using -d option and observe the output.

sshd -d

-Sri

[Travis Harp]

From the syslog.log

Jan 28 12:46:00 sshd[4539]: Accepted password for from port 57009 ssh2
Jan 28 12:46:40 sshd[4802]: User not allowed because account is locked
Jan 28 12:46:40 sshd[4802]: Failed none for illegal user from port 57011 ssh2

It seems to think that the account is locked but it's not.
I can also su into that account just fine.

[Andrew Cowan]

Forgive me if this is a stupid suggestion, but have you looked at the "/etc/ssh/ssd_config"?

Are you logging-in as a user account that is denied? The default is not to allow ssh login as root.

I hope this helps.

[Travis Harp]

After speaking with HP support and searching around I've found that the problem is with open ssh 3.7.1.p2 and trusted mode.

I found a patch to the source code at http://www.derkeiler.com/Mailing-Lists/securityfocus/Secure_Shell/2003-11/0036.html

Does anyone know where I can find a depot that has that patch installed?

[Sridhar Bhaskarla]

Travis,

Well. That goes back to my original post. You will need to apply that patch to the source code and then compile it. I believe 3.7.1p2 is basically junk for HP. We are waiting for the next port.

-Sri