Unix systems make it easy for you to log−in from a remote location and do many of the things that you normally do at the console. You can take advantage of this under VMware Workstation: You can log−in from your host system to a Unix guest system. This approach means that you can avoid switching between your host system and VMware window/full−screen mode all the time; all you need to do is switch windows.
Furthermore, if you use Secure Shell (SSH), you can send graphics clients though the connection.
There are several SSH packages. The one we’ll refer to in this book is OpenSSH, an implementation from the OpenBSD people. It supports the SSH version 1 and 2 protocols, and you can get it from
http://www.openssh.com/
10.8.1 Installing and Configuring the SSH Server Software
Binaries for the SSH server software are available for Red Hat Linux systems at the OpenSSH website, but for most other implementations, you’ll need to get the source code and build it from there if it doesn’t already come with your guest system. To compile OpenSSH, you need OpenSSL, an implementation of the Secure Socket Layer (SSL) protocol.
After you have OpenSSH installed, verify the configuration file and host key locations:
1.
Find the etc directory of your OpenSSH installation prefix (the default is /usr/local/etc). You should see two configuration files: ssh_config and sshd_config. (You need to change these files if you want to use X client forwarding; we’ll get to that shortly.)
2.
In this same etc directory, look for the host key files. All key files begin with a ssh_host_ prefix.
There should be three sets. If the key file name contains rsa or dsa, it is for the SSH version 2 protocol. The other key files are for SSH version 1. Anything with a .pub suffix is a public key.
However, anything without a suffix is a private key. Don’t let anyone see those.
3.
If you’re missing these key files, create them manually (be sure to put them in the same directory as the one that contains the sshd_config file). Use the following for the version 1 key pair:
ssh−keygen −t rsa1 −N "" −f ssh_host_key
•
Use this for the version 2 files:
ssh−keygen −t rsa −N "" −f ssh_host_rsa_key ssh−keygen −t dsa −N "" −f ssh_host_dsa_key
•
You should now be able to start the SSH server on the guest operating system.
10.8.2 Starting the SSH Server
To enable remote access with SSH, you need to start sshd on the guest system you want to access. You should be able to find the server in one of the guest system’s sbin directories: either /usr/sbin or /usr/local/sbin.
To make sshd start at boot time, you can add a script to your normal startup script sets. On most Linux distributions, this is the init.d system script; on BSD systems, you use the /etc/rc* scripts. See Chapters 6, 7, and 8 for more information on these boot scripts.
You can also start sshd through the inetd superserver with the −i option. This is normally not a good idea because sshd performs some numeric computations each time it starts, and since inetd invokes a brand−new process for each connection, you can end up waiting a while for every connection to initialize.
10.8.3 SSH, Host−Only Networks, and Hostname Resolution
SSH clients and servers are very strict about hostname resolution. In particular, they perform checks on the forward and reverse records and may bypass any records in /etc/hosts, going directly to a DNS server
regardless of your /etc/nsswitch.conf file. This can be a problem if you’re using a host−only network without any extra configuration, because the DHCP server gives the host machine’s IP address as a DNS server by default. Unless you actually have a nameserver running on the host, when the SSH server on a guest system sends a request to the host, it never gets a response, and any incoming SSH connections hang.
To get around this on a guest system, change the DNS server configuration on the guest system and/or the host’s DHCP configuration file (see section 9.4) to a real nameserver or an IP address on a network that a guest on the host−only network can’t reach. The latter approach works because the guest has no idea where to send its packets and generates a “network unreachable” error message immediately. One other way around the problem is to use IP numbers instead of names, but this can be very inconvenient.
10.8.4 SSH Clients
Now that you have a server running on your guest operating system, you need a way to connect from your host operating system to your guest operating system.
The best way for most applications is also with OpenSSH. Because the client and server packages come together, the installation procedure for a Linux host operating system is the same as for a guest operating system, as described in the previous sections, except that you don’t need to worry about starting the sshd server.
For Windows host operating systems, get OpenSSH for Cygwin. See section 5.5 for more information on how to install Cygwin; even though Chapter 5 focuses on Windows as a guest system, this section is the same for host and guest systems.
To log in from your host operating system to your guest system, run this at a command prompt:
ssh user@guest_system
Here, user is your username on the guest system, and guest_system is the name or IP address of your guest operating system. The ssh program then asks for your password on the guest system.
You can copy files to and from the guest operating system with another OpenSSH program called scp (which
stands for secure copy). For example, to copy file from guest_system to the current directory (.) on the host system, enter the following:
scp user@guest_system:file .
And to do it the other way around, enter
scp file user@guest_system:
OpenSSH also includes a handy utility called sftp, which looks and feels like a Unix FTP client.
Other Windows SSH Clients
Even though OpenSSH for Cygwin is just like the Unix version, you may want a client with a more
Windows−like look and feel. There are several other commercial and open source SSH clients available for Windows systems. We’ll concentrate on the open source clients in this section; you can find some of the commercial SSH clients at http://www.ssh.com/
There is an extension for Teraterm that supports SSH protocol version 1. You can get the extension from http://www.zip.com.au/~roca/ttssh.html (if this link is dead, try typing teraterm ssh at http://google.com/).
You’ll find a link to download a version of Teraterm there as well. The terminal client acts like a regular stand−alone Windows application and has many customizations for appearance. When you connect to the remote server, make sure that you select SSH as a protocol. There are two drawbacks to Teraterm SSH. One is that the installation process has two stages: You first must install Teraterm, and then you must install the extension. There can also be some confusion because there are two clients after the installation: one for the regular version, and one for the SSH extension. The other limitation is that Teraterm doesn’t support SSH protocol version 2, though for OpenSSH on a VMware guest operating system, this isn’t much of an issue.
Another popular SSH client for Windows is PuTTY. Like OpenSSH for Unix, this is a command−line utility, but it doesn’t require Cygwin. It supports SSH protocol versions 1 and 2 and can perform X11 forwarding.
PuTTY is fairly small and comes with handy file transfer utilities such as pscp and psftp. You can get PuTTY from the U.S. mirror at http://putty.bhni.net/ or as with Teraterm SSH, if you can’t find it there, try typing putty ssh at http://google.com/ (If you’re not used to doing this for software packages, you probably soon will be, because noncommercial software packages tend to drift from one site to another until they get their own domains.)
10.8.5 X Client Forwarding with SSH
As mentioned before, you can send X Window System clients from the guest operating system to the host. To do so, you set up a new X11 server display and port on the remote machine, with all traffic going through the encrypted SSH channel and then being forwarded to the X11 server port on the originating machine. The connection authorization happens through xauth; ssh generates a cookie value for the display and sends it to the remote machine.
Though some SSH implementations automatically set up forwarding, OpenSSH does not. Therefore, you need to make some alterations to your ssh_config and sshd_config files. To set up forwarding from a Linux host to a Unix guest system, do the following:
1.
Look in your guest system’s sshd_config file for these two lines:
X11Forwarding no X11DisplayOffset 10
Change the no to yes. The other line should be okay (unless, for some reason, you happen to have more than 10 X displays running on that machine).
2.
Shut down the guest system’s sshd file and start it again, so that it rereads the configuration file.
3.
Edit your host system’s ssh_config file. Look for these lines:
# Host *
# ForwardAgent no
# ForwardX11 yes
Remove the comment characters in front of the Host and ForwardX11 lines. If you want to allow forwarding for your guest systems only, change the * to your host−only network’s subnet.
4.
Test your forwarding installation. Send ssh to your guest system from your host, and when you get a shell, type a command such as xterm. If you get a new window, the installation works.
Occasionally the forwarding mechanism doesn’t work with preexisting installations of SSH due to changes in the library and protocol. In this case, upgrading everything to a fresh version of OpenSSH should fix things.
What About Windows Host Systems?
You can also forward X client connections through SSH from Unix to a Windows system. Teraterm SSH supports this, as does OpenSSH. To forward connections, you need an X server on your Windows host system. One popular option is the Cygwin port of XFree86 (see section 5.5 for more information on Cygwin).
A popular commercial package is Exceed, from Hummingbird Communications (http://www.hummingbird.com/).