Olaf Kirch - Linux Network Administrator Guide, Second Edition

Example 12.5: Example ssh Client Configuration File

# /etc/ssh/ssh_config

# Default options to use when connecting to a remote host

Host *

# Compress the session data?

Compression yes

# .. using which compression level? (1 - fast/poor, 9 - slow/good)

CompressionLevel 6

# Fall back to rsh if the secure connection fails?

FallBackToRsh no

# Should we send keep-alive messages? Useful if you use IP masquerade

KeepAlive yes

# Try RSA authentication?

RSAAuthentication yes

# Try RSA authentication in combination with .rhosts authentication?

RhostsRSAAuthentication yes

We mentioned in the server configuration section that every host and user has a key. The user's key is stored in his or her ~/.ssh/indentity file. To generate the key, use the same ssh-keygen command as we used to generate the host key, except this time you do not need to specify the name of the file in which you save the key. The ssh-keygen defaults to the correct location, but it prompts you to enter a filename in case you'd like to save it elsewhere. It is sometimes useful to have multiple identity files, so ssh allows this. Just as before, ssh-keygen will prompt you to entry a passphrase. Passphrases add yet another level of security and are a good idea. Your passphrase won't be echoed on the screen when you type it.

WARNING:There is no way to recover a passphrase if you forget it. Make sure it is something you will remember, but as with all passwords, make it something that isn't obvious, like a proper noun or your name. For a passphrase to be truly effective, it should be between 10 and 30 characters long and not be plain English prose. Try to throw in some unusual characters. If you forget your passphrase, you will be forced to generate a new key.

You should ask each of your users to run the ssh-keygen command just once to ensure their key file is created correctly. The ssh-keygen will create their ~/.ssh/ directories for them with appropriate permissions and create their private and public keys in .ssh/identity and .ssh/identity.pub , respectively. A sample session should look like:

$ ssh-keygen

Generating RSA keys:…oooooO…

Key generation complete.

Enter file in which to save the key (/home/maggie/.ssh/identity):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/maggie/.ssh/identity.

Your public key has been saved in /home/maggie/.ssh/identity.pub.

The key fingerprint is:

1024 85:49:53:f4:8a:d6:d9:05:d0:1f:23:c4:d7:2a:11:67 maggie@moria

$

Now ssh is ready to run.

We should now have the ssh command and it's associated programs installed and ready to run. Let's now take a quick look at how to run them.

First, we'll try a remote login to a host. We can use the slogin program in much the same way as we used the rlogin program in our example earlier in the book. The first time you attempt a connection to a host, the ssh client will retrieve the public key of the host and ask you to confirm its identity by prompting you with a shortened version of the public key called a fingerprint.

The administrator at the remote host should have supplied you in advance with its public key fingerprint, which you should add to your .ssh/known_hosts file. If the remote administrator has not supplied you the appropriate key, you can connect to the remote host, but ssh will warn you that it does have a key and prompt you whether you wish to accept the one offered by the remote host. Assuming that you're sure no one is engaging in DNS spoofing and you are in fact talking to the correct host, answer yes to the prompt. The relevant key is then stored automatically in your .ssh/known_hosts and you will not be prompted for it again. If, on a future connection attempt, the public key retrieved from that host does not match the one that is stored, you will be warned, because this represents a potential security breach.

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 maggieretrieve 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