topic Re: ssh problem in Operating System - HP-UX

ssh problem

navin — Wed, 28 Apr 2010 20:35:08 GMT

Hi All,

I have hp servers(rx2660) both are running hpux 11.23 and having ssh version as below

OpenSSH_4.5p1+sftpfilecontrol-v1.1-hpn12v14, OpenSSL 0.9.7l 28 Sep 2006
HP-UX Secure Shell-A.04.50.021, HP-UX Secure Shell version

The issue is for the account X ssh login is working fine from host A to B but not B to A
what happens is that the connection for the account is being accepted and then the connection gets closed by the remote host with the below error -pls advice if you have seen this before.
thanks

debug1: Transferred: stdin 0, stdout 0, stderr 81 bytes in 0.0 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 2582.8
debug1: Exit status -1

Re: ssh problem

Matti_Kurkela — Wed, 28 Apr 2010 20:56:27 GMT

This is not an error message: it's a notification about the quantities of transferred data and transfer rates. Stdin and stdout are at 0 but stderr has 81 bytes transferred: that would indicate the remote end emitted *some* error message, but for some reason it is not visible. Perhaps the error was overwritten on the screen by the debug output?

If connection from B to A fails, look into the system log (/var/adm/syslog/syslog.log) of node A for more clues. Perhaps there is a clearer error message?

MK

Re: ssh problem

Kapil Jha — Thu, 29 Apr 2010 02:50:24 GMT

Is this issue only for the X user aur for all the users.

and are u experiencing this from other server as well.

Have u tried to restart ssh daemon on server A.

BR,
Kapil+

Re: ssh problem

singh sanjeev — Thu, 29 Apr 2010 03:32:31 GMT

is sshd-config file configuration is same on the both server ,or any parameter is set differently.??

Re: ssh problem

Viktor Balogh — Thu, 29 Apr 2010 06:46:47 GMT

As first step I would take a look at the /etc/opt/sshd_config file on server A, maybe the user was denied there.

How user X authenticates himself on the servers? If it is done with ssh keys, check permissions of the keys, .ssh folder, etc...
Also check the authorized_keys file, one can set there many things like the allowed hosts and users, or the allowed command.

A full ssh -vv output would be also helpful to debug your issue...

Re: ssh problem

R.O. — Thu, 29 Apr 2010 09:20:34 GMT

Is your system A experiencing memory/cpu problems? Check your system memory/cpu usage in case you are running out of resources.

Regards,

Re: ssh problem

Viktor Balogh — Thu, 29 Apr 2010 10:54:04 GMT

just another idea: does it work for other users? if another users also cannot log in, maybe you should look at /etc/hosts.allow and /etc/hosts.deny files. For more info on that look here:

http://docs.hp.com/en/5991-4837/index.html

Re: ssh problem

AwadheshPandey — Thu, 29 Apr 2010 11:14:14 GMT

pls paste ssh -v o/p

Re: ssh problem

navin — Thu, 29 Apr 2010 12:55:22 GMT

i'm trying to capture the debug - but i can not make the client to use other ports - any idea

ssh -vvv -p 88888 hostname
OpenSSH_4.5p1+sftpfilecontrol-v1.1-hpn12v14, OpenSSL 0.9.7l 28 Sep 2006
HP-UX Secure Shell-A.04.50.021, HP-UX Secure Shell version
debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug3: RNG is ready, skipping seeding
debug2: ssh_connect: needpriv 0
debug1: Connecting to hostname[address] port 88888.
debug1: connect to address port 88888: Connection refused
ssh: connect to host hostname port 88888: Connection refused

Re: ssh problem

Viktor Balogh — Fri, 30 Apr 2010 04:36:34 GMT

on what port the sshd daemon listens? it seems that at port 88888 listens nothing on the ssh server. do a "netstat -an | grep 88888" on the server to see if there is any listening daemon on that port at all.

Re: ssh problem

Steven Schweda — Fri, 30 Apr 2010 05:00:10 GMT

> OpenSSH_4.5p1+[...]

Not the latest version (but that's probably
not the big problem here).

> debug1: [...]

It might help to see _all_ the debug output,
not only the last few lines. And the actual
command you're using.

> [...] for the account X [...]

> Is this issue only for the X user [or] for
> all the users[?]

Well, is it???

If one user has the problem, and other users
do not, then I'd look for the cause in the
environment of the user who has the problem:
SSH configuration files, shell start-up files
(~/.profile, ...), and so on.