Putty error

[Aaron Ooi]

hi Steven,

To upgrade the openssh this is my last resort as there is many server i need to upgrade in order to have a standardize version.

As mention earlier this only happen for a short period of time, and it back to normal after around 2 hours without doing anything.

[Steven Schweda]

> To upgrade the openssh this is my last
> resort [...]

You could run the experiment, or you could
try to find the release notes for all the
releases since 28 Sep 2006, and hope that
it's listed among the fixed bugs. I know
which method I'd find easier.

> [...] this only happen for a short period
> of time, [...]

So, it fails only when it fails. From this I
conclude that there's a problem. My guess is
that it's in either the server or the client,
and the server is the one saying "fatal:",
hence my suspicion leans in that direction.

Have you tried using a different client when
you're having the problem?


If you have a support contract (or are
willing to pay per event), you could complain
to HP. When you tell them that you're using
a product dated "28 Sep 2006", what do you
think that their first suggestion will be?
(I don't know, but have a guess.)

[Aaron Ooi]

Hi Steven,

Yup i did log a call to HP for this issue, they have suggested for me to upgrade the openssh as well. But come back again to upgrade for more than 700 machine is a terrible for me. Somemore this problem just happen recently where there is no changes to the system environment at this time. All the other machine also having the same spec and also same patch level and those is working fine.

Now i'm suspecting some daemon or application is using the ssh port, that why when we ssh to it, it fail.

I did try with another machine to ssh to this box when it having the problem, the result is still the same.

[Steven Schweda]

> [...] they have suggested for me to upgrade
> [...]

That was my guess.

> [...] to upgrade for more than 700 machine
> is a terrible for me. [...]

Worse than the SSH problem?

You shouldn't need to do all 700 systems to
see if the newer SSH version helps. (If it
does, then I'd look at writing a script to
do the upgrade installation.)

> Now i'm suspecting some daemon or
> application is using the ssh port, that why
> when we ssh to it, it fail.

That's not the message I'd expect to see if
some other program were using the SSH port.
(Try running two instances of sshd on the
same port, and see what the second one says.)

> I did try with another machine to ssh to
> this box when it having the problem, the
> result is still the same.

So, as I said, "that looks to me more like a
problem with sshd on the server than any
problem with the SSH client."

[Aaron Ooi]

Thx, will try to run 2 instance of sshd to checked out is the port issue or not.

BTW there is a company policy that all the machine should have the same level of patch or application. So to upgrade will be a problem.

So far there is no impact to my production environment as it still can divert it to use telnet rather than ssh.

[Steven Schweda]

Again, I know nothing, but a message which
starts "mm_memvalid" sounds memory-related
to me. If the system were low on virtual
memory (swap) sometimes, then that might be
a possible cause for such a message.

Well, that combined with bad code. I'd still
vote for trying a less obsolete SSH version.

This stuff is all based on open-source
products like OpenSSH and OpenSSL. If an
upgrade still seems like "worse than death",
then you could look at the source code to
try to see what this message really means.
To me, that sounds like much work, and I
suspect that the easiest fix would be the
same (upgrade).

Now, if the _new_ code has the same problem,
_then_ you'd need to get serious about
finding the cause.

[HEGP]

Hello,

Digging out a very old thread here, but I've just experienced this very exact problem connecting to a SRP container running on a 11.31 BL860 Itanium server.

Error message in syslog is exactly the same.

Workaround found is to stop the SSH server *and* all existing sshd processes belonging to opened session, then restart the SSH server.

Of course the fact that one can get a root shell using "srp_su <name-of-SRP> - " from the hosting server even if the SSH server is down makes this easier.

The SSH server is what the SRP container build procedure "plugs" into the container. Doesn't appear in swlist output from inside the container, but "/usr/sbin/sshd -v" gives 

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

Strangely enough, the 11.11 HP-PA (Superdome) server this SRP container has been built from had a SSH server running flawlessly for several years, so I suspect this is a problem induced by its "SRPization" (and runing under ARIES?)

I have an open software support call @HP.