Hello Everyone, Sorry for late summary although there was a pre-summary in the end of July. I downloaded three software packages from sunfreeware. They are openssh-2.9p2-sol8-sparc-local.gz openssl-0.9.6b-sol8-sparc-local.gz zlib-1.1.3-sol8-sparc-local.gz. And I installed them in /usr/local on both server and client machines. I changed two lines in the SSH daemon (sshd) configuration file "/usr/local/etc/sshd_config" as X11Forwarding yes X11DisplayOffset 10. Then I do ssh to remote login rather than using telnet. After that I can remotely display graphic windows on the client machine. My original question on Mon, 2002-07-08 at 04:07 is ------------- begin > Hello all, > I got a display setting problem. The network of my > machines can be diagramed as > ---------------- ---------------- > | | | | > | PC windows98 | | | > | | | Ultra 30 | > | network card 1 <--cable modem | > | | | solaris 8 | > | network card 2 ----> | > | | | IP: | > | IP: | | 192.168.1.101 | > | 24.81.80.88 | | | > ---------------- ---------------- > Now I can telnet to outside other machines without any > problems. I ran xhost + on ultra 30 before I set up > display. After telneted to an outside machine, I ran a > set-up display in the telneted window like (csh) > % setenv DISPLAY 24.81.80.88:0 > . > However, when I tried to open a graphic window on > ultra 30, I got an error message like " Can't display > on server". > Does anyone give me an idea about how to setup display > env in this case ? ------------ end I would like to thank Bryan J. Smith who responded very detailed information about how to get the required packages and how to config. The following is his replies: Bryan J. Smith replied on 08 Jul 2002 05:24:45: ---------- begin Gateway/NAT \ /---\/---\ Win PC ---- Internet ---- UNIX Sys (Ext) || \---/\---/ || LAN ================= || || UNIX Sys Just because you've established a telnet (port 23) connection with an external host, doesn't mean you can establish a X (port 6000+) connection with that same host. I.e., when the Windows 98 system does NAT (network address translation) for your connection on port 23, it only knows to forward back information on port 23 to the internal system. When it sees an incoming X connection on port 6000+ from the external host, it doesn't know what to do with it because your LAN's UNIX Sys box did _not_ request anything of a remote system on port 6000+, so there is no NAT table associated with it. While there are several ways to deal with this, the best (and most secure) way is by using SSH (port 22). SSH (Secure Shell) is an encrypted, multikey replacement RSH/RLOGIN (and has an accompaning SCP to replace RCP, etc...). An SSH client natively tunnels X (port 6000+) when you open a connection to an SSH server system with X. No additional ports are needed because the X ports are "tunneled" over the SSH connection (port 22). The "tunnel" looks like a normal port on the external host, but it "forwards" the connection automatically back over SSH to the original client. By default, SSH uses display :10 (port 6010) for the first SSH X connection, :11 (port 6011), so forth. You would then set your DISPLAY on the external host to: setenv DISPLAY localhost:10 When the system (external host) sends anything to port 6010 (X:10) on locahost, the SSH program on the SSH server "tunnels" it back to the SSH client. In ASCII art, this is how it works: UNIX Sys UNIX Sys (ext.) SSH Client -------- port 22 --------------- SSH Server | | | | 6000 (X:0) | | localhost port 6010(X:10) | Unencapsulate X| | | from SSH packet | Encapsulate in SSH packet \_________/ \_______/ From the standpoint of your Windows 98 PC, it is only doing NAT and fowarding/receiving packets on SSH (port 22). But you can forward all kinds of stuff over SSH's tunneling (even NFS) since it can encapsulate most UDP/IP or TCP/IP connections. You can think of SSH as a "poor man's VPN (virtual private network)" which is actually very secure, because it uses a multi-key authentication system, and only port forwards _select_ ports (VPNs usually are "wide open" and forward all ports). Here's an example session (NOTE: -v on SSH turns debugging on so you can see the messages listed as "debug1" below): mysys% xhost + mysys% ssh -v bjsmith@server.oninternet.com ... debug1: Requesting X11 forwarding with authentication spoofing. debug1: channel request 0: x11-req debug1: channel request 0: shell ... Those are the lines showing that X11 forwarding is being requested from the SSH server. Again, SSH can port forward all kinds of things normally with the "-L" option, but X is one of the things it will do _inheritly_ without _any_ extra work. server% setenv |grep DISPLAY DISPLAY=server.oninternet.com:10.0 Again, it does X _inheritly_, right down to _automatically_ setting up your DISPLAY variable. Note the system where :10.0 is located is localhost (server.oninternet.com) so it is sending X display back to itself on port 6010 (X:10). But that's where SSH comes in -- anything going to that port is caught, encapsulated in a SSH packet, sent back over port 22 to the client, then unencapsulated and displayed on the client's :0 X-Server. server% xterm & debug1: client_input_channel_open: ctype x11 rchan 2 win 4096 max 2048 debug1: client_request_x11: request from xxx.xxx.xxx.xxx 2598 debug1: fd 7 setting O_NONBLOCK debug1: channel 1: new [x11] debug1: confirm x11 And my xterm I launched on remote system "server.oninternet.com" shows up on my local X-Server display. Nothing else needed. You need to make sure that the SSH server is setup to do X11 forwarding. E.g., if you run the OpenSSH version (I think this is now included with Solaris 8+?), typically the SSH daemon (sshd) configuration file is "/etc/ssh/sshd_config". These are the two lines you need: X11Forwarding yes X11DisplayOffset 10 If you don't like :10 to be the default, change it to whatever you like. If you need to get OpenSSH for any system, goto their site: http://www.openssh.org/ They usually have binaries for most platforms if your version of Solaris doesn't include SSH. Compiling from source is easy assuming you have GNU GCC installed and it should only require the OpenSSL encryption library. BTW, it's a good idea to keep OpenSSH _up-to-date_. Exploits for OpenSSH usually can't do much, but since SSH is a popular, encrypted method of access, it's targetted heavily (whereas telnet is easy to exploit on its own -- because you just capture and read the clear text password sent over the Internet ;-). -- Bryan P.S. I like to also use the SSH option "-c blowfish" to use the 448-bit "Blowfish" cipher instead of the standard, 56-bit DES (Defense Encryption Standard) cipher. Blowfish is much faster than DES (and much faster than "-c 3des" 168-bit triple DES, which is also an option), while being more secure in many people's eyes (more equivalent to 3DES). You don't want the encryption of the X session to slow down your performance if you can help it (especially on older systems that don't have as much CPU power to them). The newer 128/192/256-bit AES (Advanced Encryption Standard) cipher is also an option in newer OpenSSL/OpenSSH releases (-c aes128, aes192 or aes256), although AES was designed for low-power smartcards, not industrial strength encryption. -- Bryan J. Smith, E.I. SmithConcepts, Inc. mailto:b.j.smith_at_ieee.org http://SmithConcepts.com (407)489-7013 (Mobile) Engineers and IT Professionals ----------------------------------------------------------------- BS Computer Engineering, NSPE Certified Engineering Intern (E.I.) Sun Certified System Admin (SCSA) Solaris 8 CompTIA A+ (2001), Linux+, Network+ (2002) Certified ----------- end Bryan J. Smith second time replied on 2002-07-08 at 05:07, ----------- begin > You need to make sure that the SSH server is setup to do X11 > forwarding. E.g., if you run the OpenSSH version (I think this is now > included with Solaris 8+?), Nope, not until Solaris 9: http://www.eweek.com/article2/0,3959,13011,00.asp If you want a commercially supported product, there is always SSH, Inc.'s version: http://www.ssh.com/products/ssh/ OpenSSH v2/3 supports SSH, Inc.'s v1/2 protocols, but not their latest v3. BTW, OpenSSH used to be more secure than SSH, Inc., but now that the new SSH v3 protocol is out, this has changed. It could also be due to the fact that OpenSSH is now more popular than SSH, Inc.'s, largely because SSH v2/3 are not free for commercial use anymore. OpenSSH is BSD licensed (came out of the OpenBSD project, a security-focused BSD UNIX release). > If you need to get OpenSSH for any system, goto their site: > http://www.openssh.org/ They don't provide a binary for Solaris. But Sunfreeware.COM does for various Solaris releases: http://www.sunfreeware.com/ Don't forget to download "zlib" and "openssl" as well as "openssh". If you need some help installing it, let me know. -- Bryan -------------- end My thanks also go to whom responding and trying to help me: They are: "Jaime Menendez" <correomitu@hotmail.com> "Johan Hartzenberg" <jhartzen@csc.com> "Steudten Thomas (KTPZ 2)" <thomas.steudten@csfs.com> LHERCAUD@bouyguestelecom.fr "Adam Bisbe" <bblp@bisbe.net> ssandau@bath.tmac.com "Deborah Santomauro" <santode@clcsmail.ksc.nasa.gov> mike.marcell@pni.com "Moore, L. Bryan" <lbmoore@scrippsops.com> "Larye Parkins" <LParkins@niaid.nih.gov> Thanks! Maggie Smith Logan E-mail: maggie_logann@yahoo.com Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Sat Sep 7 11:41:16 2002
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:54 EST