| gabriel rosenkoetter on Thu, 17 Jan 2002 16:19:47 -0500 |
|
On Tue, Jan 15, 2002 at 03:21:01PM -0500, Samantha Samuel wrote:
> Jan 13 04:02:00 kira syslogd 1.4-0: restart.
> Jan 13 04:02:00 kira syslogd 1.4-0: restart.
> Jan 13 04:02:00 kira syslogd 1.4-0: restart.
> Jan 14 19:00:55 kira sshd(pam_unix)[20568]: session opened for user oracle by (uid=0)
> Jan 14 19:01:47 kira sshd(pam_unix)[20568]: session closed for user oracle
> Jan 14 19:08:40 kira sshd(pam_unix)[20630]: session opened for user oracle by (uid=0)
> Jan 14 19:16:49 kira su(pam_unix)[20692]: session opened for user root by oracle(uid=400)
You're right, nothing interesting there.
> debug1: sshd version OpenSSH_2.5.2p2
Aha.
I have had *huge* interoperability problems between OpenSSH 2.5.x's
sshd and any other client (including other OpenSSH versions). I just
updated a machine I had running NetBSD 1.5, which includes OpenSSH
2.5.2pN, for NetBSD 1.5.3_ALPHA, which includes OpenSSH 3.0.2, and
the problems I was having with X, which sound similar to yours,
magically went away.
See if you can get the sshd on the server updated.
> I didn't get my prompt back after this, and while I was doing a cat on the
> log, I noticed that no further changes seemed to be happening, so closed
> it.
Sorry, I didn't make myself clear enough. The point of that is to
start an sshd on a high port with debugging turned on and then ssh
into that sshd instead.
(Oh, and you actually probably do need to run it as root if you're
using password authentication. But you shouldn't be using password
authentication anyway. :^>)
> > Then, on the client end, do:
> >
> > ssh -v -v -v -f {host} {X command} 2> /tmp/ssh.log
Here's the real lack of clarity. That should have been:
ssh -v -v -v -X -f -p 2022 {host} {X command} 2> /tmp/ssh.log
... while you're -p'ed sshd is still running on the remote host.
(The point is to get a full log of the failed handshake for X
communication between the two.)
> SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0.
Eww. You should really update this as well, that version has some
nasty security problems.
> Also, on my router ports 22 is open. Not 6000. On my comp 22 and 6000, and
> on the remote host, I don't know yet.
Hrm. This *may* also be the problem, though ssh should be
complaining about it noisily.
> is that 600 range or 6000?
{ 6000 + n : n <= 9 } is what I meant by 600n.
I actually don't remember if OpenSSH still pipes its stuff through
at a mostly-standard X port number or not. It'd be better to do the
verbose sshd testing above before heckling your roommate about this.
Oh, if 2022 is also blocked at your Windows firewall, then you'll
either need to be root on the remote Linux host (don't remember
whether you are or not), kill the listening sshd (remember, you
can kill the listener and stay connected; that's why sshd forks;
just be careful about which one you're killing... sshd should write
out a pid file somewhere, maybe /var/run/sshd.pid), and start up the
one with -d -d -d in its place (that is, sans -p flag).
You'll want to go back to your regular, non-debug sshd after testing
of course.
> The win box belongs to my roomie. So I have to check with him.
Fwiw, you're going to run into LOTS of problems if you're blocking
unprivileged ports. The only way not blocking them exposes you is if
you actually have insecure services running on those ports (xdm can
be told not to listen for TCP, and it should be). If there are other
Windows machines behind this firewall, of course, your roommate is
probably right to be worried about various worms and virii that open
up high ports behind the user's back. See if he's willing to give
you 6000-6010 for Unix X stuff, though.
--
gabriel rosenkoetter
gr@eclipsed.net
Attachment:
pgpR7B4sqXsw1.pgp
|
|