Bug Report - sshd invoked by inetd (follow-up)
aebenjam at opentext.com
Fri Nov 10 05:01:00 EST 2000
It would seem I didn't test this thoroughly enough before I sent my
email. I can reproduce the problem (same openssh version) on both
Solaris 8 and Solaris 6. (I had thought it was only on Solaris 8.)
I haven't checked to see if it exists on other versions of Solaris,
but the problem does not exist however on RedHat 6.2 running the
same openssh version.
I hope that helps.
Open Text Corporation
---------- Forwarded message ----------
Date: Thu, 9 Nov 2000 12:53:22 -0500 (EST)
From: Adam Benjamin <aebenjam at opentext.com>
To: openssh-unix-dev at mindrot.org
Subject: Bug Report - sshd invoked by inetd on Solaris 8
My apologies if this is a known "feature" and I'm simply reporting
something already known.
The situation is this:
- the sshd in openssh-2.3.0p1 (and also previously in openssh-2.1.1p4)
fail when invoked via inetd on Solaris 8
- the sshd is invoked with:
1) an entry in /etc/services:
sshback 10000/tcp sshdback # SSH Back Door
2) an entry in /etc/inetd.conf
sshback stream tcp nowait root /usr/local/sbin/sshd sshd -i -f \
(line split exists in this email, but not in original file)
- the sshd_config.inetd is pretty standard with nothing special other
than (for example) the port number changed
- when connecting from an ssh client (also openssh-2.3.0p1) with
verbose mode turned on, session appears as follows. Only the last 11
lines are shown (please let me know if you wish to see more) and
the hex values after debug: Wait SSH2_MSG_KEX_DH_GEX_GROUP have been
changed... I wasn't sure if I was exposing my private key data. Is
someone can explain to me what that data is and why it will help your
debugging, I'd be happy to pass it on:
debug: got kexinit:
debug: first kex follow: 0
debug: reserved: 0
debug: kex: server->client blowfish-cbc hmac-sha1 none
debug: kex: client->server blowfish-cbc hmac-sha1 none
debug: Sending SSH2_MSG_KEX_DH_GEX_REQUEST.
debug: Wait SSH2_MSG_KEX_DH_GEX_GROUP.
ff ff ff ff ff ff ff ff <------ please see above notes
Disconnecting: Bad packet length 796226418.
debug: Calling cleanup 0x805d910(0x0)
- note that this same method works properly on other OS's and versions
- I would be happy to answer any questions that assist in your
diagnosis, but I expect you'll be able to reproduce the problem
readily with access to another solaris 8 server.
I hope that helps,
Open Text Corporation
More information about the openssh-unix-dev