Date: Tue, 13 Jul 1999 20:31:08 -0400 (EDT) From: "Crist J. Clark" <cjc@cc942873-a.ewndsr1.nj.home.com> To: Anthony.Wyatt@its.csiro.au (Wyatt, Anthony) Cc: cjclark@home.com, freebsd-questions@freebsd.org Subject: Re: SSH X Forwarding Message-ID: <199907140031.UAA10064@cc942873-a.ewndsr1.nj.home.com> In-Reply-To: <F232EAD3304FD211BD3C00A0C99AFA9F014DB801@hermes.la.csiro.au> from "Wyatt, Anthony" at "Jul 14, 99 09:58:43 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Wyatt, Anthony wrote, > Hi Crist, > Before I begin, a small disclaimer: I'm only a new user to freeBSD, > and I have not yet tried to run up ssh on a freeBSD box. So any or all of > this information may or may not be bollox :-) > > > -----Original Message----- > > From: Crist J. Clark [mailto:cjc@cc942873-a.ewndsr1.nj.home.com] > > > > First, background on the problem: I have a freeBSD machine that > > refuses X connections through ssh. This is reproducible from a variety > > of machines; it is clear to me the problem is on the sshd host and not > > on any of the ssh clients that try to connect. Here is a typical > > manifestation of the problem, > > > > % xterm > > _X11TransSocketINETConnect: Can't connect: errno = 60 > > xterm Xt error: Can't open display: pc222:10.0 > > The TCPDUMP and the fact you can connect to your sshd host and execute > commands would suggest that ssh is working fine. I agree. > I would have at a guess the problem lies in one of the following areas: > > IP packet filtering > -------------------- > If your client runs IP packet filtering then it may be throwing away your X > traffic as it pops out of your ssh tunnel. This would explain the long > delay that you are experiencing. This may also be happening on your sshd > server; the filtering rules may throw away the traffic before it gets > stuffed into your ssh tunnel. Check your IP filtering rules here too! The specific client that I produced the above error on was using NATd, but (1) the above error is produced when machines not running NATd hook into its sshd and (2) the machine that I used as a client above works perfectly well tunneling X through ssh from other machines (both FreeBSD and IRIX). The question I have about the packet issues is that since ssh wraps all of the X interactions (and encypts it to boot), what good does that tcpdump do? Should I be looking at what ssh[d] does with the stuff after it gets it (presumably looking at tcpdumps on the loopback of the machines?)? > /etc/sshd_config (server config file) > ------------------------------------- > You can turn off X11 forwarding in this file (see the man page for sshd for > all the options). If you do, and your client tries to use X11 forwarding > you get the error message: "Warning: Remote host denied X11 forwarding, > ...". As you didn't get this message, I'll assume that the server side is > OK (I'd still check it though). > > This is my sshd_config, please note I only use RSA authentication on my > hosts, no passwords, you may have to modify this file to suit your own > needs: [snip] I am using the default sshd_config that is installed by the ports. I believe it is identical to yours but for the syslog facility (which in my case uses AUTH). I use this default sshd_config on a number of other machines and they work fine. > The pc222:10.0 in the error "... display: pc222:10.0" is the > X11DisplayOffset option given above. This option is supposed to stop ssh > from interfering with X. If it is interfering with X, you'll have to speak > to someone else, I know next to nothing about X :-) *shrug* If someone gives me a place to start, I'll look for this problem. I've delved into the Great Darkness that is the xdm configuration files/scripts. Nothing in X has frightened me since. > and/or > ~/.ssh/config or /etc/ssh_config (client side config file) > ----------------------------------------------------------- > You can do lots here too. The files are read in the order given above. > When an option is found it will be set, and ignored if configured again. > Check BOTH of these files, my configs have all the options commented out. > If you don't then try commenting out all the options and try again. Again, the client machines that have the problem opening X on the sshd-machine do just fine on others. Since there are no entries in the ssh_config's that are specific to this one machine, I have essentially ruled out the problem being anywhere but on the sshd-machine. > If your problem still persists: > On each of your clients and the server, ssh to itself, then try and run an X > app. Check the errors and see if they give you any ideas. And again, the clients are fine. But the idea of sitting at the misbehaving sshd-machine, starting X, and then ssh localhost to run an X app might be worth trying. My guess is, it will fail. > If you still have problems: > Build a brand new box, install ssh again, config sshd_config appropriately, > then try and ssh to this box from itself, and run an X app. If the same > error occurs here, try going back to 1.2.26 and try again. No way I'm nuking the machine's entire system... I'll nuke it's NT slice maybe. ;) And the error _did_ occur under 1.2.26 too. I installed 1.2.27 hoping it would fix, but no luck. > It still really doesn't work: > Panic, the problem is probably not ssh, and where you would start looking > then is beyond me... ;-) Well, I'm pretty sure you are on track when you say it is not sshd. My guess is something deep and dark in the X setup (even though I get the error whether X is actually running or not). But you said you weren't gonna go near X. I do not blame you, but thanks for the response. -- Crist J. Clark cjclark@home.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907140031.UAA10064>