SSH Issues

[John E.Ophious]

Hey Folks,

So I'm setting up SSH on a r8400 server running B.11.11 for the first time and I'm running into a minor issue. I have setup ssh before on other operating systems, but not HP so I feel like I'm just missing something silly. I went out and downloaded HPUX-Secure Shell (T1471AA) and installed it without any problems. For now, I would just like to get password authentication to work. I can ssh successfully to other systems, but I can't ssh to the HP system.

ssh -v r8400

debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug1: Connecting to r8400 [x.x.x.x] port 22.
debug1: Connection established.
debug1: identify file /home/userx/.ssh/id_rsa type -1
debug1: identify file /home/userx/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.4p1-hpn12v11
debug1: match: OpenSSH_4.4p1-hpn12v11 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.4p1-hpn12v11
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'r8400' is known and matches the RSA host key.
debug1: Found key in /home/userx/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
********* BANNER **********
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/userx/.ssh/id_rsa
debug1: Trying private key: /home/userx/.ssh/id_dsa
debug1: Next authentication method: keyboard interactive
Password:
debug1: Authentication succeeded (keyboard-interactive).
debug1: Final hpn_buffer_size = 131072
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: channel 0: free: client-session, nchannels 1
Connection to r8400 closed by remote host
Connection to r8400 closed
debug1: Transferred: stdin 0, stdout 0, stderr 79 bytes in 0.0 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 7744.2
debug1: exit status -1


Output of /var/adm/syslog/syslog.log:

r8400[26808]: Accepted keyboard-interactive/pam for userx from x.x.x.x port 57724 ssh2

Also, I commented out /etc/hosts.deny and my /etc/hosts.allow entry is:

sshd:ALL

Thanks for the help!

-John E. Ophious

[Wouter Jagers]

Your ssh authentication seems to work fine, and you're actually starting a session succesfully.

It kind of looks like you don't have a shell or something.. can you check the shell defined for your user in /etc/passwd ?

I can reproduce your log when my shell is set to /bin/false, so I think it's a clue.. if you don't see a problem there, maybe check the profile of your user as well.

Cheers

[John E.Ophious]

Thanks for the response. The user's shell and login scripts look ok, but just to make sure I tried different shells (csh and sh). I also copied the default /etc/skel login scripts to the user's home directory and set the appropriate ownership/permissions. The problem still occurs.

[Steven E. Protter]

Shalom,

The /var/adm/syslog/syslog.log file from the target system would be helpful. Its clear the system is challenging for authentication. The issue may be a system problem or configuration problem on the rp8400 box.

Of course you don't have ssh access but ftp or console access may be needed to diagnose.

SEP

[John E.Ophious]

Hello,

Just tried to ssh to the r8400 from another HP system. The same syslog.log message appears on the r8400, but no messages are created in syslog.log from the target system.

[Denver Osborn]

Do you get a successful login with password auth only?

ssh -vvv -o PasswordAuthentication=yes user@host


-denver

[John E.Ophious]

Nope... same deal. I can see in debug where authentication succeeds after entering my password, but then it just drops.

[Denver Osborn]

Start sshd with debug and post the results if nothing obvious comes from the debug ouput.

from the console...
/sbin/init.d/secsh stop
/opt/ssh/sbin/sshd -ddd

after it's running in debug, connect from the client and see what's logged on the server.

Also, are you using a custom /etc/pam.conf w/ anything other than pam_unix? Anything special about this node... nis client? trusted system? etc...

-denver

[John E.Ophious]

Nope... nothing really special about the server. Its serving as a file server at the moment sharing out data via NFS, but thats about it. No NIS and nothing customized as far as PAM goes.

However, There is a bit of interesting output from running sshd in debug (memory fault). I don't really have a means of copy-pasting, so I'll just type the last few lines. If I should be looking for anything in particular just let me know, but I didn't see anything out of the ordinary except the last section:

Accepted keyboard-interactive/pam for userx from x.x.x.x port 3844 ssh2
.
debug1: monitor_child_preauth: userx has been authenticated by privileged process
debug3: mm_get_keystate: Waiting for new keys
debug3: mm_request_receive_expect entering: type 24
debug3: mm_request_receive entering
debug3: mm_send_keystate: Sending new keys: 40036f68 40034da0
debug3: mm_newkeys_to_blob: converting 40036f68
debug3: mm_newkeys_to_blob: converting 40034da0
debug3: mm_send_keystate: New keys have been sent
debug3: mm_send_keystate: Sending compression state
debug3: mm_request_send entering: type24
debug3: mm_send_keystate: Finished sending state
debug3: mm_newkeys_from_blob: 4003efe0(118)
debug2: mac_init: found hmac-md5
debug3: mm_get_keystate: Waiting for second key
debug3: mm_newkeys_from_blob: 4003efe0(118)
debug2: mac_init: found hmac-md5
debug3: mm_get_keystate: Getting compression state
debug3: mm_get_keystate: Getting Network I/O buffers
debug3: mm_share_sync: Share sync
debug3: mm_share_sync: Share sync end
debug1: audit event euid 0 user userx event 2 (AUTH_SUCCESS)
Memory Fault


There is no coredump though...

[Denver Osborn]

hmmm.. beats me. :) ut here are a few other things I'd check.

make sure the filesets are configured:

swlist -l fileset -a state Secure_Shell

If it's not in a configured state:

swconfig Secure_Shell\*


You could also try running it with "UsePrivilegeSeparation" set to no

-denver

[Wim Rombauts]

Just a thought ...

In your last entry, the debug stops with "Memory Fault". Could it be that some setting on your system is not fully correct, and that this is not at all an SSH problem ?

Just a thought of course, I don't know how to investigate this.

[Kasper Hedensted]

Hi,

I had a HP-UX system which had similar behavior

I changed this setting in sshd_config, and then SSH worked fine:

UsePrivilegeSeparation no

Just a thought

Regards,
Kasper

[Steve Post]

You DID check the permissions of your:
homedirectory, .ssh subdirectory, and the files in .ssh on your login account right?

[John E.Ophious]

Hey all,

Denver/Kasper:

I verified that the filesets are configured for Secure_Shell. I also set UsePrivilegeSeparation = no, restarted sshd and tried again... same results.

Wim:

At this point I think anything is possible! This system hasn't given me any troubles in the past, but as we all know thats just a matter of time.

Thanks again

[Denver Osborn]

So still the same memory fault w/out priv sep running sshd -ddd?

Just curious, but if you set sshd_config to permit root login... can you login via ssh to root?

-denver

[John E.Ophious]

Steve:

Yes, just double checked. Permissions/ownership look fine. Even out of curiosity did a chmod -R 777 /home/userx... still the same results.

Denver:

Just tried as root... same results BUT a coredump occurred this time.

[Steve Post]

Those directory permissions are wrong.

The user's home directory can't have write permission for group and other. And the .ssh subdirectory needs to be only accessable by the user. (I didn't read this out of any manual. I just found this out via experimentation).

$:/home/slpost/.ssh> ls -ld .
drwx------ 2 slpost users 8192 Jul 20 2006 .
$:/home/slpost/.ssh> cd ..
$:/home/slpost> ls -ld .
drwxr-xr-x 24 slpost users 8192 Feb 1 08:17 .
$:/home/slpost>

I had this problem. Everything looks like it should work. It doesn't. Then you change the permissions. And viola. It's worth the 2 seconds to at least try it.

[John E.Ophious]

I'm pretty sure they were set that way before I experimented with changing the permissions, but I went back and changed them to what you suggested. Now I have:

700 on /home/userx/.ssh
755 on /home/userx

Same memory fault though.

[Steve Post]

sorry about steering you the wrong way. Here's another potential deadend to try.

Look at file /opt/ssh/etc/ssh_prng_cmds

This runs a pile of commands to help make a random pattern. Perhaps one of these commands is bombing out enough to stop the whole process?

This one happened to me when I had a box with DNS setup wrong. It would hang on the "netstat -i" command buried in this file.

[John E.Ophious]

No problem Steve... I don't think there is a wrong way to go from here! I checked out /opt/ssh/etc/ssh_prng_cmds... I was able to run all the commands in there without any problems. Good thought though. I think I'm getting to the point where I need to try another version or try the non-precompiled binary route. I'm not giving up quite yet though.. its a matter of pride now :)

[Denver Osborn]

Can you test sshd with...

/opt/ssh/sbin/sshd -ddd \
-o "UsePAM no" \
-o "UseLogin yes" \
-o "UseDNS no" \
-o "UsePrivilegeSeparation no" \
-o "PermitRootLogin yes" \
-o "StrictModes no"

try both root and non-root user.

-denver

[John E.Ophious]

With those options set I get the banner and request for a password, but permission denied after I enter the password for both accounts

[Denver Osborn]

Ok, that didn't help much.

Anything unusual in your profile which might explain it sshd core dumping?

So it looks as though you can login when running sshd like this...

/opt/ssh/sbin/sshd -ddd \
-o "UsePAM yes" \
-o "UseLogin no" \
-o "UseDNS no" \
-o "UsePrivilegeSeparation no" \
-o "PermitRootLogin yes" \
-o "StrictModes no"

But soon after you authenticate it core dumps. Right?

How about adding "set -x" to your profile to see how far it could be getting after you authenticate.

Attaching full output of server "sshd -ddd" and client "ssh -vvv" process might also help someone.

-denver

[John E.Ophious]

Hey Denver,

Nope, the profile is completely default - nothing out of the ordinary.

Yes, when I set UsePAM to yes and ssh -v to the r8400 box, I get banners, then a password prompt. After entering the password I get successful authentication and then the memory fault occurs. No prompt, just an instant disconnect.

I enabled debug mode in the profile (set -x) and tried again... I get nothing back like its not even getting to that point yet.

Unfortunately I can't attach the full output of the debugging we've been going through.. everthing I've put in these threads has been hand typed :) If there is anything specific I need to look for or that anyone would like me to post from the debug I can try to narrow it down.

Thanks again for everyone's help.

[John E.Ophious]

Also, not sure if I was clear enough, but when UsePAM is set to no I still get banners and prompted for a password, but after entering the password I get a permission denied error and prompted again. Three strikes and I'm out... no memory faults.