A first-time login to a remote host will look something like:
$ slogin vchianti.vbrew.com
The authenticity of host 'vchianti.vbrew.com' can't be established.
Key fingerprint is 1024 7b:d4:a8:28:c5:19:52:53:3a:fe:8d:95:dd:14:93:f5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'vchianti.vbrew.com,172.16.2.3' to the list of/
known hosts.
maggie@vchianti.vbrew.com's password:
Last login: Tue Feb 1 23:28:58 2000 from vstout.vbrew.com
$
You will be prompted for a password, which you should answer with the password belonging to the remote account, not the local one. This password is not echoed when you type it.
Without any special arguments, slogin will attempt to log in with the same userid used on the local machine. You can override this using the -l argument, supplying an alternate login name on the remote host. This is what we did in our example earlier in the book.
We can copy files to and from the remote host using the scp program. Its syntax is similar to the conventional cp with the exception that you may specify a hostname before a filename, meaning that the file path is on the specified host. The following example illustrates scp syntax by copying a local file called /tmp/fred to the /home/maggie/ of the remote host chianti.vbrew.com:
$ scp /tmp/fred vchianti.vbrew.com:/home/maggie/
maggie@vchianti.vbrew.com's password:
fred 100% |*****************************| 50165 00:01 ETA
Again, you'll be prompted for a password. The scp command displays useful progress messages by default. You can copy a file from a remote host with the same ease; simply specify its hostname and filepath as the source and the local path as the destination. It's even possible to copy a file from a remote host to some other remote host, but it is something you wouldn't normally want to do, because all of the data travels via your host.
You can execute commands on remote hosts using the ssh command. Again, its syntax is very simple. Let's have our user maggie retrieve the root directory of the remote host vchianti.vbrew.com. She'd do this with:
$ ssh vchianti.vbrew.com ls -CF /
maggie@vchianti.vbrew.com's password:
bin/ console@ dos/ home/ lost+found/ pub@ tmp/ vmlinuz@
boot/ dev/ etc/ initrd/ mnt/ root/ usr/ vmlinuz.old@
cdrom/ disk/ floppy/ lib/ proc/ sbin/ var/
You can place ssh in a command pipeline and pipe program input/output to or from it just like any other command, except that the input or output is directed to or from the remote host via the ssh connection. Here is an example of how you might use this capability in combination with the tar command to copy a whole directory with subdirectories and files from a remote host to the local host:
$ ssh vchianti.vbrew.com "tar cf - /etc/" | tar xvf -
maggie@vchianti.vbrew.com's password:
etc/GNUstep
etc/Muttrc
etc/Net
etc/X11
etc/adduser.conf
..
..
Here we surrounded the command we will execute with quotation marks to make it clear what is passed as an argument to ssh and what is used by the local shell. This command executes the tar command on the remote host to archive the /etc/ directory and write the output to standard output. We've piped to an instance of the tar command running on our local host in extract mode reading from standard input.
Again, we were prompted for the password. Now you can see why we encouraged you to configure ssh so that it doesn't prompt you for passwords all the time! Let's now configure our local ssh client so that it won't prompt for a password when connecting to the vchianti.vbrew.com host. We mentioned the .ssh/authorized_keys file earlier; this is where it is used. The .ssh/authorized_keys file contains the public keys on any remote user accounts that we wish to automatically log in to. You can set up automatic logins by copying the contents of the .ssh/identity.pub from the remote account into our local .ssh/authorized_keys file. It is vital that the file permissions of .ssh/authorized_keys allow only that you read and write it; anyone may steal and use the keys to log in to that remote account. To ensure the permissions are correct, change .ssh/authorized_keys, as shown:
$ chmod 600 ~/.ssh/authorized_keys
The public keys are a long single line of plain text. If you use copy and paste to duplicate the key into your local file, be sure to remove any end of line characters that might have been introduced along the way. The .ssh/authorized_keys file may contain many such keys, each on a line of its own.
The ssh suite of tools is very powerful and there are many other useful features and options that you will be interested in exploring. Please refer to the manual pages and other documentation that is supplied with the package for more information.
Chapter 13. The Network Information System
When you're running a local area network, your overall goal is usually to provide an environment for your users that makes the network transparent. An important stepping stone is keeping vital data such as user account information synchronized among all hosts. This provides users with the freedom to move from machine to machine without the inconvenience of having to remember different passwords and copy data from one machine to another. Data that is centrally stored doesn't need to be replicated, so long as there is some convenient means of accessing it from a network-connected host. By storing important administrative information centrally, you can make ensure consistency of that data, increase flexibility for the users by allowing them to move from host to host in a transparent way, and make the system administrator's life much easier by maintaining a single copy of information to maintain when required.
We previously discussed an important example of this concept that is used on the Internet - the Domain Name System (DNS). DNS serves a limited range of information, the most important being the mapping between hostname and IP address. For other types of information, there is no such specialized service. Moreover, if you manage only a small LAN with no Internet connectivity, setting up DNS may not seem to be worth the trouble.
This is why Sun developed the Network Information System (NIS). NIS provides generic database access facilities that can be used to distribute, for example, information contained in the passwd and groups files to all hosts on your network. This makes the network appear as a single system, with the same accounts on all hosts. Similarly, you can use NIS to distribute the hostname information from /etc/hosts to all machines on the network.