The most basic and common way you interact with other Unix machines from the command line is to log in to them using a command-line interface from your own machine.
Once you log in to another Unix machine using a command-line interface, you can use that machine in the same way as you use your own machine from the command line. Of course, you may not have the same level of permissions that you have on your own machine, and if the remote machine is running a different version of Unix, there will be some differences in availability of commands and variations in how some commands work. Overall, however, you will find yourself in an environment very much like the command-line environment on your own machine.
In this section we describe two ways of getting to a command-line prompt on remote machines. The first (and preferred) method uses SSH to establish an encrypted connection to the remote machine, while the second method uses an older program called Telnet to establish an unencrypted connection. Both SSH and Telnet are useful for more than simply logging in to another machine, but connecting via SSH is not always supported, so sometimes you have to use Telnet.
SSH stands for secure shell and is the name of both a protocol (SSH) and a command ( ssh ).
The SSH protocol sets up an encrypted connection between two machines over a network such as the Internet. The primary tool for using the SSH protocol is the ssh command. This means that if you are communicating with a remote host using SSH and someone is able to tap in to the connection, it is extremely difficult or impossible for that person to read the data flowing between the two machines. For this reason, SSH is the preferred method for logging in to another machine over the Internet.
To log in to other machines over the Internet, you need to have an account on the remote machine. That means having a user name and password. You also need to know the network address of the remote machineeither its IP address or a hostname that your machine can translate into an IP address. As complicated as that sounds, it is actually simple in practice: If you are supposed to be connecting to a remote machine, you will have been given the address to use.
Refer to Figure 10.1 for the following task. The figure shows the process of logging in to a remote machine using the ssh command.
To log in using ssh:
username is your user name on the remote system. hostname is either in the typical domain-name format or an IP address of the remote machine. For example, the following will connect to the machine well.com with the user name puffball:
If your user name is the same on both the local and remote machines, you may omit the username@ portion of the command line:
Sometimes you get an IP address to use instead of a hostname. You can experiment on your own machine using the special IP address 127.0.0.1, which always means "this machine right here," or use the hostname "localhost," which is a Unix standard name for the local machine. (You might have noticed that we use the hostname localhost in the examples of command-line prompts in this book.)
ssh username @127.0.0.1
If this is the first time you have used ssh to connect to a particular hostname or IP address, you see a prompt as shown in Figure 10.1. Despite the apparent security warning, you should answer "yes" to the question. (You must type the full word yes , not just y .) See the sidebar "Authenticity of Hosts and SSH."
The next thing you see is the prompt for your password:
Enter your password.
Your typing is not displayed, to prevent your password from being visible.
You are then logged in to the remote machine. The remote machine may display an informational message about itself, perhaps telling you the last time you logged in or giving you a telephone number for the system support staff. Often you will get only a prompt from that machine. You can now start entering command lines to the remote machine.
When you want to log out of the remote machine, type
You return to a shell prompt on your own machine. ( exit also works, and on some systems will also work.)
It is a good idea to open a new Terminal window for each connection to a remote machine (you can have many open at the same time).
Consider changing the Terminal window title and/or text color for each window in which you are connected to a remote machine. This will help you remember which machine you are "on" in each window. You can make these changes in the Terminal application by pulling down the Terminal menu, choosing Window Settings, and then choosing Shell.
If you are having trouble on the remote machine while connected via ssh , you can terminate the connection (without closing the Terminal window) by using a special sequence of keys:
That's the key, followed by the character, followed by a periodpress them one at a time, not all together. You can get a list of the available "escape" commands with this sequence of keys:
Bear in mind that your shell may not be the same on the remote machine as on your local machine. For example, your account on your own machine might be set to use the bash shell, while on the remote machine your account might use the tchsh shell, so you can expect some slight differences in how the command-line environment behaves. One way to see which shell you are using is
Using SSH to run a command on another machine:
One of the nifty things about SSH is that you can use it to run commands on another machine without actually logging in to the remote machine.
For example, the who command shows a list of users logged in to a machine. If you want to check who is logged in to a remote machine on which you have an account, you can use the ssh command to run the who command on the remote machine and see its output on your machine.
To run a single command line on a remote machine:
localhost:~ vanilla$ ssh email@example.com who firstname.lastname@example.org's password: geffrey pts/1 Jun 25 10:30 (22.214.171.124) mikkee pts/7 Jun 25 10:32 (14-226-92-54.clients.attbit.com) lalla pts/2 Jun 25 09:21 (werks.kinemia.com) jmassoun pts/53 Jun 25 11:10 (huffman.wunterk.com) rpdoctor pts/12 Jun 25 06:59 (126.96.36.199) jperk pts/26 Jun 25 06:14 (fl-boca-cuda1-c2a-132.pbc.adelphia.net) fanson pts/56 Jun 25 10:44 (119-176-36-34-cdsl-rb1:S.0)
More About SSH
SSH is both the name of a protocol and the name of a widely used Unix command ( ssh ).
As with many facets of Unix, there is more than one variety of the SSH software. Mac OS X comes with OpenSSH, an open-source implementation of the SSH protocol that combines the work of several prior implementations . You can read a brief history at OpenSSH Project History and Credits (www.openssh.org/history.html).
The OpenSSH tool set includes several commands that are installed on your Mac OS X machine, including ssh , sshd , scp , and sftp .
localhost:~ vanilla$ ssh email@example.com ls -l /etc firstname.lastname@example.org's password: total 1980 drwxr-xr-x 3 root root 4096 Oct 31 2002 CORBA -rw-r--r-- 1 root root 2434 Oct 29 2004 DIR_COLORS -rw-r--r-- 1 root root 2434 Oct 29 2004 DIR_COLORS.xterm -rw-r--r-- 1 root root 92421 Mar 19 2003 Muttrc drwxr-xr-x 17 root root 4096 Feb 19 09:47 X11 -rw-r--r-- 1 root root 2562 Aug 5 2002 a2ps-site.cfg -rw-r--r-- 1 root root 15228 Aug 5 2002 a2ps.cfg -rw-r--r-- 1 root root 49 Mar 11 13:03 adjtime -rw-r--r-- 1 root roo 1122 Mar 6 17:04 aliases -rw-r--r-- 1 smmsp root 12288 Mar 25 11:31 aliases.db drwxr-xr-x 2 root root 4096 Sep 17 2003 alternatives -rw-r--r-- 1 root roo 317 Aug 28 2002 anacrontab -rw------- 1 root root 1 Jul 24 2002 at.deny -rw-r--r-- 1 root root 212 Aug 26 2002 auto.master -rw-r--r-- 1 root root 575 Aug 26 2002 auto.misc -rw-r--r-- 1 root root 1497 Aug 29 2002 bashrc drwxr-xr-x 2 root root 4096 Oct 31 2002 bonobo-activation -rw-r--r-- 1 root root 756 Jun 23 2003 cdrecord.conf drwxr-xr-x 2 root root 4096 Jul 19 2005 cron.d drwxr-xr-x 2 root root 4096 Mar 25 12:24 cron.daily (Partial Output)
ssh -t email@example.com vi myfile
Before there was the SSH protocol there was the Telnet protocol. The Telnet protocol is at least 25 years old ( geeks in the audience: check out RFC 764 if you doubt this) and is the lowest -common-denominator method of logging in to a remote Unix machine. These days it is deprecated in favor of SSH because all of the data in a Telnet connection (including your user name and password) is sent over the network unencrypted. However, a few systems still don't support SSH, and there are things you can do with Telnet besides logging in to another machine.
Just as we have the ssh command for using the SSH protocol, we have the telnet command for using the Telnet protocol.
When using the telnet command, you need the same things as you do for SSHthat is, the remote machine's address (either a hostname or an IP address) and an account on the remote machine (user name and password).
To log in using Telnet:
As with ssh , hostname can be either a text-based network address, such as well.com, or an IP address, such as 188.8.131.52. If you use a hostname, the telnet program asks the operating system to translate the hostname into an IP address. That's why you see an IP address in this line:
When you use telnet , your machine tells you it is trying to connect to the remote machine. Once it connects, you see text from the remote machine identifying itself, followed by a login: prompt from the remote machine ( Figure 10.4 ).
Figure 10.4. Using Telnet to log in to a remote machine.
Enter your user name.
Once you enter your user name, you should see a password prompt from the remote machine.
Enter your password.
You are now logged in. Some systems will show you a short message about themselves (called "the message of the day"). In any case, you get a prompt from the remote machine, and you can now type commands to it.
If you are having trouble on the remote machine while using telnet , you can quit the Telnet program by typing a special keyboard combination that gets you a prompt from the Telnet program itself.
Notice in Figure 10.4 the line that says
Escape character is '^]'.
This is part of the text that comes from your own computer before you get the login: prompt from the remote machine. The Telnet program is telling you that if you press , you'll get a prompt from the Telnet client on your own machine:
and you can then exit the Telnet program (and kill the connection to the remote machine) by typing
Besides using Telnet to log in to a remote machine, you can also use it to test services running on other machines.
You do this by using telnet to connect to a remote machine but to a different port number than the one normally used for logging in with telnet .
When one machine connects to another over the Internet, it always uses a combination of an IP address and a port number. The combination is called a socket . The IP address identifies the particular machine, while the port number leads to one of the (possibly many) pieces of software that are "listening" for incoming connections. Each Internet service has a standard port number that it listens on; the server software for telnet login, for example, normally listens on port 23. We provide a more extensive discussion of ports in Chapter 12, "Security," and Table 12.1 lists the most commonly used port numbers . You can see the full list your system uses in the file /etc/services .
When you use telnet to log in, you are using the telnet client program to connect to a Telnet server program (called telnetd ) on the remote machine. Server programs like telnetd (and sshd , mentioned earlier in this chapter) are said to "listen" on specific port numbers. The telnet command normally connects to port 23 on the remote machine.
On the Internet there are standard port numbers for all the common Internet services, so the telnetd server listens on port 23, Web servers normally listen on port 80, e-mail servers listen on port 25, the sshd server listens on port 22, and so on. This allows all of those services to be running on the same machine and share the same IP address. It is their port numbers that distinguish them; in other words, each service uses a different socket (again, that's the combination of IP address and port number).
You can use the telnet command to connect to a remote machine on a port other than the standard Telnet port (23). If the connection itself is successful, you at least know that something is listening on that port on the remote machine. If you are familiar with the protocol that the remote service uses, you may be able to try a test interaction with the remote service.
Refer to Figure 10.5 while working through the following task.
localhost:~ vanilla$ telnet www.eigenstate.net 80 Trying 184.108.40.206... Connected to www.eigenstate.net. Escape character is '^]'. HEAD / HTTP/1.1 Host: www.eigenstate.net Connection: close HTTP/1.1 200 OK Date: Sat, 30 Apr 2005 20:33:47 GMT Server: Apache Set-Cookie: eigenstate.net-user=220.127.116.11.1114893229232762; path=/; max-age=31536000; domain=.eigenstate.net Last-Modified: Sat, 30 Apr 2005 15:45:44 GMT ETag: "524171-498-489c5a00" Accept-Ranges: bytes Content-Length: 1176 Connection: close Content-Type: text/html; charset=ISO-8859-1 Connection closed by foreign host. localhost:~ vanilla$
To connect to a remote Web server to test it:
telnet www.eigenstate.net 80
The only new thing about that command line is that you are specifying that telnet connect to port 80 on the remote machine instead of the default (port 23).
If there is anything listening on port 80 on the remote machine, telnet should connect to it.
In Figure 10.5 you see that something is in fact listeningthat's why you get the line
Connected to www.eigenstate.net.
Even though the Web server on the remote machine is waiting for input from you, there will be no prompt.
Now you will type a few lines to request some information from the Web server:
HEAD / HTTP/1.1
Make sure to only press once at the end of that line.
You are asking for the summary information (the "head") about the main page on this Web server ( / ). Use GET instead of HEAD to request the full page instead of only the summary information. You are also telling the server that you are using HTTP version 1.1.
This line specifies which domain name you are requesting information about, in case the server software is configured to respond to requests for more than one domain name.
Here you are telling the Web server that after it sends you the information, you are requesting that it close the connection.
Adding a blank line tells the server that you are finished creating your request. If the Web server and network connection are functioning properly, you will immediately see a response like that in Figure 10.5.
In the response shown in the figure, you see several lines of information, including one that tells you the Web server is running the Apache software and that the Web page we asked about is 1176 bytes long.